Hiring Myths Common in Hacker News Discussions
somehowmanage.com
somehowmanage.com
Lots of people don't nag about whiteboard interviews at FAANG, I think a lot of people who are commenting here don't even send their CV to any of those companies. People nag about other companies using whiteboard interviews as some kind of "silver bullet" of hiring. Most of the time I see negative comments about it, it is that some small startup which is trying to get people to work below market price is grilling people on interview like Facebook or Google. (as a side note there is whole list of bad stuff that medium/small companies do just because "goog/fb does that", but they should never do)
Other negative that I see in discussions is, technical interviewers are assholes that want to show you how smart they are. Which FAANG interviewing style is helping to spread. Asking random algo question, that you know answer to and the person you are interviewing does not, makes it easy to feel superior.
Being thoughtful about hiring... Yes if hiring manager has resources to do that then he might build amazing hiring engine. Again most of the companies have scarce resources, and entrepreneurs probably spend more time on sales than on hiring, because you should hire only if you really have to. Probably hiring is also not their core business.
Indeed. There is a great post about this mistake causing companies to do wrong technical choices titled "you are not Google". Worth a read if you're not familiar with it already (already been on hn twice as well).
https://blog.bradfieldcs.com/you-are-not-google-84912cf44afb
I also would have been quite willing to work for a fraction of what people that don't have my chops would want.
The worst was working with recruiters. They are downright insulting. Quite jarring.
Whiteboard/LeetCode tests are a flat-out insult to me. I won't do well at them, and I'm quite aware that people spend huge amounts of time, practicing for them, so I don't have a chance.
I do have a few hundred thousand lines of code, dozens of blog articles, dozens of repos, and a decade or more of checkin history. I've been told that I "faked" it, which would be hilarious, if it weren't so insulting.
In the end, I just decided to stop looking for work, and I'm working in a small startup team, writing some fairly powerful software, for free; because I enjoy doing this stuff.
It's pretty odd that the current scene is actively hostile towards folks like me. I feel that it's fairly self-destructive.
If you don't mind my brusqueness, how are you feeding yourself?
The rest of the country has high variance. It will also depend on the company you're targeting. A lot of target companies have a leetcode interview style (I presume every other interview style has too high of a pass rate).
Here's how I spent today:
I woke up at 5AM, like I always do, and did my two-mile walk. During the walk, I sorted through today's job. I'm working on a social media app, and I'm setting up the baseline (admin) stuff. I needed to add the capability to convert "standard" users to "manager" users (and vice-versa), and I'll also need to add UI in the app (native Swift iOS/iPadOS/Catalyst app) to manage permissions.
I figured out how I would do it. It was a combination of work on the backend (I needed to add some functionality to the admin user layer), the SDK (I needed to add a couple of methods to funnel the UI requests to the REST API), and the app, itself (I needed to add a button to the user edit screen). The tricky part would be the backend work. I needed to do this in a manner that would not invite any security compromises, and would catch errors. I also wanted to leverage the current structure, as opposed to introducing new structure.
Also, I was a dumbass, and used Git submodules in the backend (it's a "layer cake" model). That makes modification a pain.
I don't write stuff down, if I can help it. After my half-hour walk, I knew what I needed to do, and, by 7AM, I had the basic framework in place on the backend. I couldn't test it until I also had the work done on the SDK, so I started that (it wasn't much code).
Since I wrote the backend a couple of years ago, I also spent time, groping around, re-learning it, and getting my head out of "Swift Mode." The biggest mistake I make, is forgetting to end lines with semicolons.
This is where my extremely disciplined coding standards pay off. 99% of the time, I'm the poor schlub that needs to relearn the code, so I make sure that I structure and document very well.
By 9AM, I had the whole stack in place, and there were a number of bugs. I like to test, so I was able to figure out where they happened. Most were in the backend, so I spent a lot of time with Charles Proxy, examining the exchange. Some of the bugs required a fairly substantial architectural change. That's pretty common, so I write in a layered, modular fashion with lots of hooks. Makes that kind of refactoring go smoothly.
By 5PM, I had it all working, but I need to make the app UI better. It needs a confirmation alert. Otherwise, it's pretty much done.
Tomorrow, I'll add the confirmation, and do a lot more testing. This is fairly critical stuff. I can't afford any security lapses here, and I need to make the UX as smooth as possible. Because of the nature of the work, I need to figure out the best way to provide instantaneous user feedback, while waiting for the server to do its work. I'll hammer that out in tomorrow morning's walk. I still need to do the permissions UI, but I won't get started on that, until I'm satisfied that the privilege swap works 100% (I don't move on, until I'm satisfied that my work is at "beta" level, or better).
And I spent absolutely no time at all, practicing LeetCode.
if you're struggling to find even a non-FAANG job but no one wants to work with you - perhaps you aren't as good as you think you are at the things you've mentioned.
not trying to be hostile at all here, just giving you my honest take.
I like coding. I want to enjoy what I do. That's the single most important thing in my life. I spent thirty years, dancing to the organ grinder. I spent most of that as a manager, which wasn't fun.
As for how good? Feel free to look for yourself. I am an open book.
Feel free to write me off. You probably wouldn't like working with me.
I am trying to go through every possible interpretation I can think of in which saying something like this to anyone isn't hostile, and I'm coming up empty.
Could you elaborate how it isn't?
If a person is consistently upset about not getting what they want, but also not willing to change what they are doing, that person needs a breakthrough. "Maybe you're not achieving your goals because you're not as good as you think you are" can be really useful feedback for someone who is stuck like that. I've both received and given that feedback in an athletic context, for example. It's rarely welcome in the moment, but that doesn't mean it is intended to cause harm; quite the opposite, usually.
I've found people who want to work with me, working towards laudable goals, and I do work that I love. I won't starve to death, and there's the very real possibility that what I'm doing will end well. I'm pretty good at what I do, and what I do, is make stuff that works.
It gives me the luxury of saying "Guv! Why's that chap in the crown starkers?".
Whenever there's a back-and-forth about LeetCode tests, it eventually gets down to "Well, I was hazed, so you get hazed, too."
That sounds like a sensible baseline for selecting engineering staff.
What you can keep in mind is that there are very large amounts of money at stake for software engineering jobs. So it is magnet for every kind of faker you can imagine. So don't take it personally, just be thankful that you are qualified for a job that many people wish they could do.
And yes the whole thing is a game. The people who are good at the game are most likely to win. So just learn to be good at the game.
This is exclusive of any level of seniority, which I like to be flexible on where I can.
While I wouldn’t say this is fraud per se, the candidates were obviously using a shotgun approach to apply to any job in the industry.
I'm a native Swift developer, with over 30 years' experience programming Apple devices, but I have also written a lot of PHP (backend) stuff, and Web sites.
A few years ago, I spent a few months, learning Android, and decided I didn't like it, but I do have Java and Android Studio in the mix.
I often get recruiters, trying to match me with Web design or C# (nowhere in my stack) jobs.
I'll still get pinged by recruiters for a senior network engineering job in Idaho or some such.
I never gave one single test, and I could usually weed out the spammers from a quick glance at their résumé. I often hired folks that didn't "hit all the sweet spots" on their CV, because I found them to be eager, energetic and curious.
Had a couple of bad decisions, but very few.
Much less extreme, but I've also seen many people who looked very similar in their resumes but were worlds apart in how the coding interview went. Some of them could quickly flush out specifications, asking good questions, talk about why they want to solve the problem the way they did, and fluently write code, while many others struggled in different areas or sometimes all of the areas. This is also really important for figuring out which of them we want to hire, and how badly we want to hire them.
How the interview is run matters a lot, and also what sorts of problems you choose. I think it's really important to choose problems that aren't essentially spending 45 minutes on one narrow knowledge test (especially of the "have you already seen this before" variety), but instead test as many aspects of the person's skills as possible. I want to see how they handle incomplete requirements, simple design, thinking about how to create an output format that is maximally useful to a consumer on another team, naming things, thinking about the runtime of different approaches, thinking about big-O space usage, thinking about back of the envelope space usage in bytes, coding, thinking about edge cases, etc. If I had more time I would want to check code reading, testing, and debugging as well, since these are so important to being an effective programmer, but they're unfortunately much slower to evaluate.
[1] I've interviewed people like that as well, and within the confines of the interview I've been asked to run the best I can do is note that I don't think we're able to evaluate them well this way.
I'm spoiled. In my open-source work, I've done some fairly significant (but still below-the-radar) stuff, and got used to basic, simple, respect; without people trying to wrestle me into some kind of subservient role. That's not to say that we didn't have disagreements. Quite the opposite, in fact. I've done Service for some of the most disagreeable people that you can imagine, and left them happy and enthused.
So I actually looked at a few startups. I have a fairly unique conflux of skills and experience that could make an enormous difference in small teams. What I found, is that they imagine themselves to be "mini-FAANGs," and treat their prospects pretty badly. I know that startups tend to have rather chaotic, personality-laced workplaces (see "working with difficult people," above), but if they can't keep that crap out of their triage interview, then the place, itself, must be a nightmare.
I'm working for free, for a friend. I stepped in, because I watched him being set up by contract houses that were obviously going to do very bad work, for lots of money (they barely hid it; I guess because he's non-technical, and doesn't know better). Since he's doing an NPO, and looking at grants for funding, he can't afford that kind of object lesson.
Instead, he's getting a platform that would make a lot of "big houses" green with envy. For free. This is something that I have a lot of prior art in. It's already pretty awesome, and I've only been working on it for a month.
There's a lot to be said (and gained) by simply treating people with basic respect, and motivating them. The workplace is not the military. If we treat our employees and co-workers badly, they won't stick around. If we treat them well, they could do some pretty amazing stuff.
I'm honestly curious. I have never had to really do either of those things in order to get great jobs that pay quite well. Granted, I don't work for a FAANG, haven't even interviewed for one, but I don't feel any less successful even so.
I'm tempted to think you come off as difficult to get along with, but this is entirely based on your writing style here and may be entirely unwarranted :). I've always found that being agreeable helps an awful lot.
Things have changed. https://www.youtube.com/watch?v=L9EKqQWPjyo
I made the mistake of working for a company for 27 years, and the culture changed drastically, during that time.
I am a very good person to work with. My LI profile is filled with testimonials as to what kind of person I am. I just believe that humans are very important, and that seems to be an "outlier" philosophy, in today's tech scene.
I am mediocre at them. Most represent stuff I haven't done. A lot of it is common sense, but I'm solving them for the first time, so my approach is usually sub-optimal (I tend to start with naive approaches, then refine, if necessary). The testers are usually looking for a formulaic approach. A lot of my approaches are orthogonal to the "classics." I started as an EE, so I'm pretty good with things like drivers, SDKs and APIs, but they aren't really something that you can do in a 50-line test.
What's really insulting, is that when I'm asked, I usually send links to relevant gists or repos; often focused on the exact method that addresses the question asked.
It's ignored (so far, 100% of the time -the "faker" comment was made by someone that was explaining why they ignored it).
What about neurodiversity and hiring neuroatypicals? "Culture fit" is often a euphemism for discrimination against them and others with poor social skills.
Also, call me cynical, but I've come to view blogposts like this as little more than marketing for the author and whatever company they started/work for. They're always vague, self-congratulatory, studiously avoid saying anything genuinely controversial, and to the extent that they're critical, it's often just as a way of contrasting themselves with the competition.
To those downvoting: if Linus Torvalds was 30 years younger and just as competent, yet completely unknown, do you really think he wouldn't have a lot of trouble getting hired at a FANG company because of his poor social skills?
While of course there are limits, why turn away a good engineer when all it costs you is a bit of patience and accommodation? It's not like talented people are easy to find.
A process good at testing applicants should 1) identify the good ones and 2) identify the bad ones. The standard whiteboard interview makes no attempt at (1) and works by throwing almost everyone in bucket (2) regardless of potential.
This is plainly, in general, a process that sucks. It just happens that the way it sucks is not a problem if you're FAANG.
You better have quality work to do and equivalent perks as Google to put candidates through their style of interviews.
Otherwise those companies are delusional and I have the world's smallest violin for their recruiting woes.
So notoriously low that the CEO had to approve a company wide raise of 10 percent one year?
(I've entered my comp there)
This is the most annoying thing. I've got a code test on Friday. This life changing pivotal moment comes down to little more than whether or not I've seen the problem before. If I have, great I nail it and get the job. If not, well, I don't. So arbitrary.
Other things being equal, I would rather more stress in a handful of days of interviewing than more stress about whether I keep a job I "have".
If the interview is explicitly run as a simulation, where the hiring team looks for good behaviors (both in attitude and in problem-solving) and not necessarily good outcomes, whiteboard interviews work well, because: a) they scale and, b) they can actually be good simulations of a high-stress environment. The downsides are that they become subjective, unless the hiring team is experienced/has been trained well.
The only work environment it simulates is one where every feature is developed in a 15 minute sprint that's literally overseen (like over your shoulder) by a boss who's put you on a PIP; there's no collaboration and no google; nothing is expected or allowed from you except a working output; and you're fired if there's any issue raised in code review.
It's more like an exam, but it's not even that: exams are meant to see what you know. The whiteboard interview just offers you as many ways to fail as possible and sees if you make it.
I wouldn't really say it's either one. I hesitate to call it hazing, but... as a trial to prove your dedication to the group by doing arbitrary and unpleasant things, for some it feels similar.
It's so misleading to cite BigCos as examples of excellent hiring, because the founders of the companies and the initial employees are never hired in the same way that their engineers are currently hired. They're usually just people who happened to know each other in a dorm. It's only after the company gets a bunch of funding that they need to fill seats with a bunch of warm bodies. But the success wasn't because of the assembly-line style hiring, it's the product idea and the personal qualities of the founders that drove the success of the company. Engineers throw themselves at those companies because of the compensation and prestige. It's not because they have a magical snowflake hiring process.
Google started with talented and motivated people.
They also hired talented and motivated people, but that in itself is not proof of anything. Did they hire talented and motivated people because of their hiring process, or for other reasons, such as that Google is a place where a lot of talented and motivated people really wanted to work?
There are different spins you could put on the hiring process: (1) it's extremely difficult in order to pick out "the best" engineers or (2) it's extremely difficult in order to pick out the engineers will do anything to work there.
I might be misremembering but I seem to recall that Google's hiring bar in the early '00s, before they grew into a behemoth, was even higher than it is now. If you weren't from an elite CS program with near perfect grades, they wouldn't even look at you.
My point was that why would any candidate put up with Google's hiring crap if they weren't already extremely motivated to work at Google? Especially if you had other choices.
No-Name-Company could have an equally high bar to hiring, but they wouldn't be able to fill any positions, because candidates would just tell them to get lost.
That's one. And if you admit Google was a "hot" choice at the time, that already makes my point.
> Google's candidates weren't "highly motivated"
No?
> Contrary to your assertion
I'm not sure what you take my assertion to be, but let me clarify. My assertion is that if a workplace is "hot" for whatever reason -- rapid growth, high compensation, world-changing product, number of users, prestige, etc. -- then a large number of good candidates will apply there, and almost any hiring method will probably work out for them.
When you talk about Google hiring only from elite CS programs, it's crucial to note that Larry and Sergey came from Stanford specifically, so of course they're going to hire people from Stanford. That's always how it goes, as I mentioned earlier with founders and early employees. Let's not pretend that's a "hiring process". It's a personal network. A number of other people from Stanford were also early Google employees. Scott Hassan, et al. They got seed money from the co-founder of Sun Microsystems. The next year, they got $25 million in VC. When I was in college in Wisconsin, there was nobody around to fund anything! Almost all of the big tech companies were built from informal personal networks, and they only institute a rigid hiring process after they're already somewhat successful. Again, any no-name company can have an ultra-high bar for hiring, but that doesn't magically attract candidates willing to apply and put themselves through hell to get hired.
You can train a lot of engineers in how to conduct these interviews fairly quickly and you tell them what information to focus on and how to document it. You can then pass this information to a hiring committee that has a lot of experience in evaluating candidates. Having sat in on some hiring committee meetings I can see how little weight is given the algorithm if the candidate has a good reference or highly relevant experience.
The issue with the interview alternatives that most people suggest is that they would require your most senior engineers to spend a really really large portion of their day on hiring which can burn people out quickly.
For example, I've had several machine learning engineer interviews in which I was asked to write some variation of NMS (non-max suppression) or gradient descent on the whiteboard. What machine learning engineer writes that kind of code anymore?
I can write it, yes I can fumble (a lot) and figure out how to optimize it, but in reality these are the type of algorithms that you almost always use some library that someone has already written for you for that kind of stuff. They spend the entire hour nitpicking at your implementation of NMS, base their entire impression of you on that implementation of NMS, and never in your entire interview ask you anything about, say, what the state-of-the-art object detectors are, what their breakthroughs are, how their networks are roughly structured, what you might think about doing to improve on them, what you could do if you only had limited annotation data, and other real machine learning questions.
It has been 3 years since I interviewed somebody for a ML position. Mostly I focused on knowledge of model execution. Most ML libraries were horrible for use in production at the time and I was more worried that a candidate wouldn't be able to productionize a good model than I was worried they wouldn't be able to build that model.
I've sat in on a fair number of hiring committee meetings over the years and have only seen the opposite; poor performance on the testing is a disqualifier no matter how good their references or credentials are. Even the FAANGs make hiring mistakes so credentials don't mean much.
I realized this when I got a lot better at whiteboard interviews after a FAANG job for a couple years. A coding challenge that I took the full hour on and bombed out of college was now done in twenty. I just picked up the problem solving intuition by writing a ton of code.
Ex: Code this mini app, code this mini api, figure out why this code is buggy, design this app / backend service that does this, why did you choose that, etc.
Additionally, the time to spin up at a mature company with it's on tooling and enormous amounts of existing code can be really long. I don't think you can generally tell in two days whether a person is going to do well.
Remote contracts are a thing as well.
I'm not sure international hires are relevant to the discussion, they are at best a sliver of the whole.
Trades might be more applicable, and in trades you likewise have certain kinds of certification or even a guild-like system to keep skills and performance visible and consistent. There's not really any equivalent in programming (though there is in IT more broadly). Even a university degree is not really any particular proof of an ability to code, a lot of programs can be taken without having to write much code solo.
Programming is usually done collaboratively, either implicitly (through the use of base libraries) or explicitly (coworkers, group projects) and there are definitely people who freeride on those collaborations to a great extent.
Also another good example is cooks, who get hired based on working a shift unpaid to see how they fit with the team.
Asking for a hands on demo is pretty common.
Engineering-wise I can focus on any one thing they bring up and ask them to explain in more depth, this then becomes a dialogue, which is vital I think, because they're interviewing me and my company as much as I am interviewing them. I intentionally don't try to catch them out, in fact the opposite, a candidate at ease is the one that opens up more and will give you more insight into who they are and what they are about than any whiteboard exercise.
I'll then talk about the requirements for the role they're applying for and try to see if their knowledge covers what we need. Again, just a dialogue.
If that first interview goes well, then I will ask for examples of code they have written, or set them a test to do in their own time if they have nothing of their own to show. Granted that takes some of their time, but it only happens if they're being seriously considered, and importantly (I think) allows them to use their own tools, in their own time, in their own way, this gives them a chance to shine.
This might not work at FAANG scale, I dunno, I find the idea of working at any organisation like that a pretty miserable one. But talking to someone in a respectful way, rather than putting them in an uncomfortable situation that bears no resemblance to what their day-to-day would be, shouldn't be hard to scale.
Although, I suspect much of these issues come about because of the inadequacies of the interviewers rather than the candidates, they're hiding behind tricks, gotchas, and memory tests, because possibly they don't have the range themselves to extract something meaningful from the candidate in order to rank them.
Were you perchance interviewing others while at FAANG or doing anything related to interviewing (speaking with coworkers about it, etc.)? I've seen plenty of people come out of FAANG worse at interviewing than they went in.
The problems I've heard most of my peers solve at FAANG are not really that relevant to interviewing. At least, none of them are like, "Yeah, man, totally kick ass at leetcode now that I've been at Facebook for a year!"
Most problems decompose into using a graph or a hash table (or an array), not implementing one. And the hard bit is usually things like translating the business requirements, architecting code to keep it maintainable over time, and dealing with buggy / opaque 3rd party systems.
Classic whiteboard interviews don't test these things at all.
You're going to learn the first part on the job. It's rare - especially in Google's hiring - that you want to hire someone for their deep familiarity with the tech stack or problem domain. So you select for the second part.
But your test for the second part still involves specialising in some process. Take home tests or pair programming exercises aren't "culture-blind" any more than whiteboard tests. So a large important part of the industry standardised on a "development process" of writing code on a whiteboard, a "business domain" of advanced-undergrad-level data structures, and a "tech stack" of "pick any language you want, or a reasonably rigorous pseudocode". If everyone learns that to the same degree, the remaining differences between the candidates are mostly in part 2.
There are some downsides that get trotted out on HN every time: you may reject someone who's really good but didn't take the time to focus on undergrad data structures, you may reject someone who is particularly bad at whiteboard stuff (typically due to nerves), your process is easier to train for recent CS grads from good universities. But every system has downsides. This one is reasonable for Google and not-terrible for you, but you may be able to do much better by focusing on one of the sets of people Google's process underrates.
The more common instance I've had to do is plug-and-play existing algorithmic design on existing data structures that are well-represented in libraries. Need a hashtable or an auto-growing array? That's in virtually every standard library. Balanced search trees are also pretty common, although (in my experience) actually quite rare in practice. Graphs are usually not in standard libraries, but graph libraries are pretty standard in languages: there's petgraph in Rust, Boost has graphs in C++, and Python has networkx. Just pop those libraries in, and you don't need to bother implementing anything basic like traversals.
The only things exotic enough that I've had to personally implement them myself are Johnson's algorithm for elementary circuits and the union-find datastructure. Both times, I've had the algorithm in pseudocode right in front of me when writing the code, so I've never had to actually memorize how these things work.
My interviews were far and away the least thoughtful hiring experience I’ve ever had. It was clear each person was filling out a form while I was talking, and followed up with pre-written questions. There was nothing non-traditional, and the 6 hour loop definitely did not respect my time. ~50 hours of prep, 10 total hours of interviews ( 2 hours of screening, 6 hour loop, 2 additional interviews for other roles).
I had really great interactions... after the forms we’re filled out. Interviews went well - I was put into the “recycle” status but never found a role there that really fit my experience.
Nontechnical but still tech consulting, not aws.
Anyone here have good hiring stories?
This candidate said "Well my partner is considering a job in Texas."
I asked candidate if he preferred Texas to NYC.
"Not really, they have scorpions."
Having done both, I'd much rather be on the hiring end than the candidate end. But as the hiring manager, I mostly just felt weariness at the process.
The most interesting thing I’ve heard I guess has been the guy who replied ‘Well, they’re all idiots there’ when asked why he wanted to move.
Like someone else said, hiring is mostly just tiresome.
Q: "One of CompanyCo's core values is Openness. How have you demonstrated openness in your career?"
A: "I am open about my contempt for bullshit questions like this one."
Final round with a candidate who’s “near the bubble”. Me: “Do you have any questions?” Him: “Yeah; have you guys ever thought about selling business cards online?” Me: “Uh, we’ve uh, given it some thought.” To this day, I’m not sure what he thought we did.
* Candidates reneging after accepting an offer (current company made a bunch of concessions to keep them)
* Candidate reneging after accepting offer and my company getting an H1B approved for them (turns out they had interviewed with and accepted offers at multiple companies, to get multiple H1B petitions filed and maximize probability of at least one getting accepted... of course they didn't disclose this)
* Candidate accepting offer then simply vanishing
I moved internationally in 2012 and, knowing no-one in my new city, promptly volunteered to organise the local chapter of a popular developer meetup. I met dozens of friends and future colleagues at those monthly meets. Almost immediately I got a job with the outgoing organiser, and a couple of years later I recruited the core of a greenfield team from the regular attendees. One of them wasn't even working professionally with the language, but it was clear from talking to them and seeing their code they had potential. Moreover they were a really decent yet introverted person who just needed a break. I loved working with them and was proud to watch them grow into a truly accomplished yet extremely humble engineer. I'd hire them again in a heartbeat.
Another: my department was made redundant in March (great timing), but I immediately picked up contract work with a friend I first worked alongside many years ago. I've hired him into multiple roles in the interim with great success... and now I get to help build his business. We trust each other to be candid and know each others strengths and weaknesses (technically and personally) and he pays me on time. It's great.
Another: we needed a QA for my last team and one of our senior devs recommended someone from an old workplace. Feels bad saying it now, but with no experience of our toolset or domain we'd never have given their resume a second look. But good QAs are hard to find and we were desperate, so after a promising interview we hired them on a trial. Couldn’t have gone better - obliging, a quick study, and a knack for surfacing esoteric bugs. They went on to lead QA for our company.
Referrals and “the network” can work to your advantage.
Yet... when growing my last team I’d exhausted that network, so we advertised on StackOverflow. Amongst many applications were from two "developer famous" people I knew by reputation (twitter, conference talks, blog posts, book authorship etc). Our whiteboard-free process was a friendly interview followed by a small take-home code challenge. One came was arrogant and dismissive and said had neither the time nor inclination for take-home projects. While the other was gregarious, gracious and completed the task without fuss. Guess who we hired? They were technical mentor to virtually everyone on the team (myself included) and were instrumental in laying a solid architectural foundation of our product.
While I’ve plenty of “war stories”, it really is nice to remember how many gracious, friendly and deeply competent people I’ve worked with over the years.
Going back, he asked the candidate a simple Fizz Buzz question, something like finding the largest element in an array. All hell broke loose suddenly. He was outraged and started telling them that, back in his country he was a university professor and that this was beneath him. The interview ended with the candidate arguing for 10 minutes that he shouldn't have to do this test. If I recall, at this point the senior engineer just left the room and didn't bother with the remaining 15 minutes of the interview.
Needless to say they didn't hire him. HR was shocked as he seemed to be a great hire.
Fast forward a few years later, I'm the one interviewing and I systematically get great resumes who can't implement a simple version of word count in 30 minutes.
Maybe they should ask themselves why they ended-up losing?
Extracting a cardinal evaluation goes a long way towards solving the "Optimal Stopping Problem" more tractable and efficient.
Granted some of the test fashion is useful for computer scientists and the fraction implementing algorithms. But the other 80% are being selected for the wrong thing. These other folks that are curious could be trained on the job (the growth mindset) in a few weeks, if that were still a thing.
Or maybe the candidate is willing to do that type of work during work hours, but lacks the time and motivation to do it at home after work.
When people say "work smarter not harder", practicing algorithm interviews on your free time instead of trying to get a raise at shit companies is exactly the smarter thing to do. By choosing not to do this you make your life way harder.
Please elaborate.
A. Boring big corporation paying $80k.
B. Boring big corporation paying $160k, but you need to spend a few weeks practicing to pass their tests before joining.
Many people say they choose A since they don't want to waste their free time coding, like the guy I responded to. That is just plain stupid. Money is ultimately free time, you don't have to work as long as you have money, and many of these well paying companies lets you go down in time.
One way to find at least one promising line of thought in that direction is to consider that every choice has a cost and not just a benefit.
IMO, this is what's lacking in most interview processes I have participated in, and most of these issues can be fixed by following a structured interview process. As a side benefit, you may end up with better candidates, as well. At the very least, you can actually tell if the candidates you choose to hire are as good or better than other people who have gone through your interview process, and that's worth something.
https://www.holloway.com/g/technical-recruiting-hiring/about
Facebook has largely stagnated aside from acquisitions. Most of their scaling issues were resolved a decade ago. If you consider the repeated, practically universally hated redesigns, how is their hiring process working for them exactly?
Amazon has numerous, obvious, long standing problems with their web store and cloud services. Maybe they are engineering toward higher profits instead of satisfied customers. Fire stick and amazon video UI is a trash fire. Regardless, I don't see any amazing engineering coming from amazon. Maybe its all in fulfillment? From what I can tell, Amazon just finds okay engineers that are willing to be exploited until they run away when they realize how awful it is to work there. When you consider the fulfillment employees things don't get rosier.
Apple basically forces a curated design aesthetic down their users throats. Some like it, some hate it. I use a mac and android. As a user, iOS and macOS literally sicken me; I have to go into the accessibility and turn off all the animations and transparency. Apple's software has notoriously gone down hill for many years in terms of bugs and performance. I'm sure there's a lot of great engineering work that goes into a lot of what apple does, but it's almost all throw away. They focus on trendy features that no one wants. It sells a new year of iPhone upgrades, then it's abandoned because no one used those features. I still feel bad for all the companies that have been swindled into adding touchbar support and all the users that were swindled into paying $200 for the touchbar they won't use.
Netflix hasn't changed in a decade. Maybe their backend systems have improved? I still regularly encounter buffering issues and the UI has been terrible since the first iteration. I still get DVDs in the mail and they visually downgraded the UI for that a few years ago but otherwise the feature set has never changed. The quality and selection of the petrol-disks transported using petrol is still superior to the largely-free-to-them transmission of the digital versions. I presume their hiring is largely focused on content creation at this point. Maybe their backend systems are more reliable now through engineering?
Google is so infamous for product failures theres a metaphorical graveyard. How many times have they tried on the messaging front? I think we are at iteration 6? That's 5 failures in a row. The things they've succeeded at like search, mail, and maps were all done over a decade ago. Since then it's just been repeated downgrade after downgrade. Maybe all their engineering work is going into search rankings and anti-spam which are decent but not obviously better than its been in the past. Point of diminishing returns probably.
I'm sure there are brilliant engineers working at all those companies, but it largely isn't demonstrated in overall output from the sector. Now considering the quantity multiplied by the quality of engineers, it's truly shocking I can't reliably send a text based message to an arbitrary person in the same city.
I think FAANG's success is more easily attributed to non-engineering related choices that have hurt users and the industry to a much larger degree than it has benefited them.
All things considered, the efficacy of their hiring practices can't be too far ahead of the industry average so I don't think it's fair to hold them up on a pedestal and claim 'Regardless of how bad you think they are at hiring, FAANG's hiring practices are effective'.
It's idiotic that someone has to prepare for a month to do a 5-7 hour whiteboard interview loop that has no relation whatsoever to the job duties. You don't quiz a barbecue chef on Michelin star molecular cuisine, yet this is considered totally normal in our profession.
At a minimum, ask questions that one could figure out without knowing the answer beforehand, and at a minimum let them use their text editor. Better yet, don't do this shit at all, and ask people to solve a _practical_ problem similar to ones they're likely to encounter if they take the job. It still provides a good filter, arguably better even.
As things are now, interviews test for academic credentials, memory, and lack of flight response from candidate's amygdala, not practical technical skill per se.
Those sound like they might correlate well with the traits desired.
I would pass this buck way, way earlier. Many diverse future candidates (non-white) are educated at awful public schools. When you begin your education at a miserable daycare-school then you are far less likely to make it all the way through the life-pipeline and get in front of a high tech recruiter. I have hired diverse candidates and they are great just like all candidates I hire. There simply aren't that many that apply, and the pool of diverse candidates is sucked up by way better-funded FAANGs and similar.
I would argue we need to completely reinvent our primary education system from the ground up to offer more choice and make them way less depressing for lower-income students. You can't expect a tech recruiter to fix 2 decades of mistakes through their hiring system.
The medium- and higher-income districts are all still close to a 1:1 gender ratio but tech companies are really, really far from that.
It's only relatively recently that female graduates even reached parity with (and now outnumber) male graduates. It will take even longer for the male:female divide to be closed in STEM.
My schooling was in eastern-ish europe growing up in a low middle class environment. My girlfriend grew up in SFBA and went to high school in Palo Alto.
The difference in perspective is astounding. Even simple things like what you consider normal.
Like, I grew up knowing that The Boss is someone you hate and despise who makes your life miserable. Becoming the boss is villified. Rich people are bad. Everyone is out to screw you. That includes rich people, poor people, the government, the police. Everyone. It’s you against the world. The forgotten class everyone exploits and nobody helps. High taxes, no help.
Oh and teachers are all dumb. Otherwise they wouldn’t be teachers.
By comparison the normal for my girlfriend is “You invent google street view or cofound the next ebay, obviously. That’s just basics”. At the least you do well in school, get great grades, and climb a corporate hiwrarchy to near top. That’s the failure mode if nothing else works.
Learning the US corporate/business culture has been imo my biggest challenge moving here.
Similar to how 50 years ago it was pretendint sexism isn’t a problem.
Imo it’s important to talk about all types of systemic issues, not just the popular ones. And to quote one of my well meaning friends: ”Oh pfft your issues don’t count because you can pass (look white and male)”
However, estimating malnutrition by measuring the heights of adults is not a great way to get a read on current food supplies.
FB's diversity report. https://diversity.fb.com/read-report/ White Americans make up 37% in tech, 63% in leadership positions in Facebook.
GitHub is 70% White and 15% Asian. https://github.com/about/diversity/report
Apple is 50% White and 23% Asian. https://www.apple.com/diversity/
If the ethnic clusters have bad english, you then start getting language and cultural comfort effects and people not of the ethnic group have a much harder time getting hired.
This is the "pipeline problem" debate. You're right, it does start much earlier than tech companies, but also, it's too easy for hiring managers at tech companies to just throw up their hands and say "we can't do much, it's just the pipeline that isn't giving us enough diversity." There is plenty of evidence that it's not just a pipeline problem.
One of my co-authors wrote a really solid piece on this: https://www.holloway.com/g/technical-recruiting-hiring/secti...
It's a simple signal to noise ratio issue.
Sure you might be leaving out "diamonds in the rough" candidates, but how many mediocre interview will it take to find one?[0]
[0] https://blog.codinghorror.com/why-cant-programmers-program/
Telling someone to get 3 values of a list that create the high product isn't going to solve your production issue on a saturday night.