I don’t think the FAANG-style coding puzzles have anything new to add to the conversation here. The reason big companies do that is because the questions are prompts are simple to write explain (hence interviewer has to do very very little), the answer space is generally well-defined (so it’s easy to grade, and easy for a Hiring Manager to check if the interviewer screws up), and they almost exclusively select for completion time (which is key in a high-pressure feature house company).
Most of the discussion here seems to be interested in alternatives. Through my experience, I can’t agree enough with the article author who posts:
Not a single person out of several thousand emails and messages came out in defense of the current state of interviewing processes - I’ll let this one stand on its own.
The only people I’ve seen to defend the current process in public are ex-FAANG people who were actively monetizing their experience (e.g. Gayle Laakmann).
These are not "puzzles". That makes it seem like there is some trick or clever concept the candidate needs to grasp that show "lateral thinking".
There isn't.
These are (or supposed to be) fundamental problems of computer science that require good understanding of algorithms, data structures, code performance, and can be solved in <30 mins on a whiteboard.
Yes, these exist, and there are plenty of them. A pretty common and well known one is "HEAD to TAIL" - where you have a dictionary of 4 letter words, and given an input of 2 words find a connecting path between them changing one letter at a time. This isn't a puzzle. It's a problem to solve and approach from different angles and allowing for a large number of solutions of different performance characteristics
> Not a single person out of several thousand emails and messages came out in defense of the current state of interviewing processes - I’ll let this one stand on its own.
Means absolutely nothing. Most of us are not interested in ruining the day of someone who is unhappy with the hiring process by revealing the truth that most likely it just means the person was not good enough. That seems cruel. I'm kind of going further here though because this is the second time this OP is coming up on the front page of hackernews
What's more is problematic is that the construction and evaluation of the puzzles is highly subjective and nearly everywhere lacks rigor. Completion time is a key metric while quality of communication is most commonly either ignored or not assessed at all uniformly among interviews.
(Aside: what's frustrating is that companies make candidates sign NDAs for on-sites; these prevent candidates for disclosing or _selling_ the information they might glean in the process, which very rarely happens. In actuality, it's the former interviewers who violate protections for "confidential info" and copyright when they go and monetize their experience post-job, or even on-the-job e.g. Rooftop Slushie).
> Most of us are not interested in ruining the day of someone who is unhappy with the hiring process
That's only true in so far as you, as an employee, are paid to achieve positive sentiment among candidates, no matter how shallow that sentiment may be. That's indeed cruel, and it's well-established that interviewers are widely unaware of the consequences of the current hiring process. That's why we get articles like those from the OP.
A true interest in improving the hiring process includes: * Making prep materials and courses freely available (helps industry candidates) * Committing time to CSE outreach to better integrate company needs to CSE (helps new grads) * Finding questions that reflect real tasks on the job (helps the evaluation have a chance of being predictive) * Closing the information gap between hiring managers and candidates: disclosure (in aggregate) of hiring rates, salaries, etc.
Playing along and doing hundreds of coding puzzle interviews is a waste of time for all involved.
Nothing could be further from the truth at my company
> A true interest in improving the hiring process includes: * Making prep materials and courses freely available (helps industry candidates)
Recruiters share this with candidates. They ignore it.
> * Committing time to CSE outreach to better integrate company needs to CSE (helps new grads)
Go to any university career fair and you'll see companies with booths clarifying these positions working against the mis information of negative blog posts
> * Finding questions that reflect real tasks on the job (helps the evaluation have a chance of being predictive)
They do. You don't have to agree, but they do. The real task on the job is "disambiguate a complex problem autonomously, and come up with a plan to address it." The interview is a 20 minute constrained version of it.
* Closing the information gap between hiring managers and candidates: disclosure (in aggregate) of hiring rates, salaries, etc.
Semi-agreed. I do wish people and companies were more transparent about salaries. But there is already an entitlement complex from a bunch of engineers on this site and many others complaining why some dude at Netflix in California is making 500k, while he is making 80 in Oklahoma writing code for Bank of America.
A lot of people at my company do, but you never hear about this stuff because nobody blogs about a career fair that came with some friendly helpful insights from senior engineers.
Also nobody blogs about recruiters when they are super helpful and give a ton of relevant interview prep material (which ours do), partially because most candidates frankly ignore the material thinking it's not relevant.
If the devs at your company need to put out fires constantly, then maybe it's a good test of whether they'll be able to do that.
1) The companies that do this interview a TON, so there are bound to be bad experiences, and those are the ones that people blog about
2) The questions are supposed to be hard, but achievable. So you get two scenarios:
A/ candidates who are not good enough and are not aware of it. "How am I supposed to know if the hashmap/dicationary data structure in the language I say I'm best at maintains insertion order? I just google that every time - everyone does!". Sorry, bucko. That's the kind of in-depth understanding of your tools that we DO expect you to give a shit about
B/ Immature interviewers with a bar that's too high that are using overly complex questions and don't get noticed right away by the more experienced interviewers.
So ultimately, YEAH, the questions I ask, for me to want to move forward with a candidate, I expect you to solve the problem. But I'm not expecting you to solve it in the most efficient way or GTFO
At a high level that reflects the work that we do. The project scale may be 20 weeks instead of 20 minutes, but the level of complexity is scaled accordingly.
Of course, we miss out on some candidates that could be great at executing on a large timeline but can't demonstrate it in a short in person interview.
But, (see my edit), this is all we can do to scale our interview process, and we don't want to take risks.
i look more after how people approach problems at a high level, where they show how they build the whole system and how they interact with peers and other departments to tell if they can gather data, organise it in specs, and then fine tune nicely build parts of a system. not code monkeys.
The vast majority at the FAANGs are full stack engineers which includes long term system design.
The comparison to a car assembly factory is so ridiculously out of alignment with reality that I can see why you chose to go with a throwaway account.
Appreciate it. For some background it would be nice if you clarify the perspective of your role as one of HR/coordination or a more technical view on participants of these interviews.
Do you feel like current FAANG hiring practices for lower level roles incubate a generation of programmers that trains specifically for the interview process moreso than they do for the actual role you want to fill (and if so, do you feel like that is benefitial to your employer / simply a necessity at their scale / worth changing)?
edit: That makes sense, thanks!
No, I don't think so. We would not hire a person who clearly only memorized a bunch of algorithms and data structures to solve toy problems, but cannot describe their thought process coherently, does not show a fluent ability to translate their ideas into code, or can't refactor the code or adapt their process when introduced with new requirements, scaling bottlenecks, or system failure scenarios.
That's kind of reductionist. I upvote answers that at least attempt to propose alternatives to the current status quo. The employer side isn't the only relevant one, which is likely a stronger reason why a lot of current hiring practices aren't popular. Some only work at FAANG scale with a large enough pool of applicants, some seem optimized to hire people that waste time on code puzzles (that doesn't make them an "algorithm wiz") and others generally put applicants in a position resembling begging for a job, especially for junior roles.
Just because something works well on some quantitative metric does neither imply that it is the only, nor the optimal solution, especially in two player games like hiring.
Not sure where you read "less pay" into my comment but fine, let's go with that and just ignore that quite a few companies immitate FAANG style hiring these days.
> Instead you should try to find the good candidates they miss. However there is really no reason for top companies to change their interviews.
Yeah, I feel like we're arguing two completely different things here, there's plenty of reasons for companies to change processes even if they work on some metric. When a large number of experienced participants in the fields you are hiring for are offering critique on your process it should be at least reason enough to talk about it, which is the whole point of discussions like these.
My point was that they shouldn't unless their offer can compete with FAANG offers.
> When a large number of experienced participants in the fields you are hiring for are offering critique on your process it should be at least reason enough to talk about it
FAANG are spending billions a year to keep this process running, there are huge amounts of work put into trying to change or improve it. And some things do change, but the signals from doing algorithms is just too salient to throw away.
The longer answer is we can only study the people that joined the company and failed to perform rather than those that COULD have been outstanding but our interview process selected them out. So there are flaws, of course.
I'm not sure how you could do the latter unless the biggest companies shared their data and compared scenarios of "Candidate X failed an Company Y interview, but then later got a job at Company Z, and thrived".
Also you'd be working against the bias of "Well, that just means that the Company Z is easier to work at".
There are just too many variables, team to team.
Part of the problem is even within these massive companies there is a huge diversity of types of jobs, and an engineer who thrives on working on Google AdWords might fail on the SpannerDB team (to pick two random examples from not my company)
See my edit, but most interview candidates I see onsite (that's after resume/phone screens) are not good enough to join the company.
Our onsite pass rate is between 15-25%
I'm an interviewer at a FAANG company with >500 interviews in the last 5 years, I teach multiple internal courses on interviewing, and I think the system makes a lot of sense for companies at our scale.
Ask Me Anything :)
I currently have a toddler on my lap, but I'll edit this post later today to address some common criticisms and misunderstandings, but also point out which concerns I think are valid and where we should do better.
edit:
Okay, let's go through the most important points
1) I'm a Software Developer. I interview other SDEs. I ask them problem solving coding questions, algorithmic coding questions, data structure questions, and whiteboard architectural design (not at the same time, but it could be any of these)
2) Our process is REQUIRED for a company of my size. You would not believe the amount of candidates we get. We have a high bar for hiring, but fundamentally we have to be efficient with our time. That completely removes as an option superior interviewing techniques like "spend a day with the dev team working on a small real task" or "do this take home test over the weekend and then the interviewing team will review it with you". Both of these are better at uncovering good candidates than a whiteboard coding interview, but don't scale, and are themselves controversial in the industry from candidates who are unhappy of the time they require.
3) A common criticism of "algorithmic" questions (leetcode) is that they don't reflect the reality of day to day work. If a lot of people even at FAANG are working on typical 3-tier front-end-back-end-database systems, utilizing the tools and systems other employees built before, why bother evaluating if the candidates could build the next generation of such systems if asked.
Because once these people are inside the company, we'd like to think that everyone passed a similar tech bar. That means that if a new database or distributed system does need to be purpose built for a high scale system, and someone applies internally, you can be flexible with the kind of interviewing process you put an internal transfer through - you already know they passed a high technical bar, and are likely qualified to work on the hard stuff.
4) another common misconception is people underestimate the complexity of "typical" systems inside the FAANGs of the world - compared to their prior job experiences. A payment processing integration at Amazon scale is not a payment processing integration at your company's scale. An internal CRM build at Google scale is not an internal CRM build at your company's scale.
The 10,000 foot view is similar, but the expectation would be that the system would be 1/ built out faster, 2/ built out better, and 3/ scale better than a comparable project on a less technically strong company.
5) Coming back to the interview process. What that means, is that when we ask a candidate to solve a hard algorithmic problem on a whiteboard in 20 minutes, or deep dive into the inner workings of a complex data structure, or show how they could combine multiple data structures to solve one problem, we are not validating "Can this candidate write an algorithm in 20 minutes on the job at their desk"
What we're checking is "Can this candidate do something really hard, ambiguous, and time-sensitive in the Computer Science domain, when prompted to." The real life challenges will be different, but if they CAN do the first one, they'll likely be able to do the second one.
Of course we miss out on candidates who are terrible at these skills, or can't code on a whiteboard, or are overwhemled by the interview stress and can't perform. But we are willing to do that because of Point (2) above. We'd rather say no to a "maybe" candidate than hire someone who can't perform.
Despite what people state that ability with algorithmic performance on a whiteboard does not translate to on the job success, that is not my experience. Remember - I'm not looking to see if a person can spit out A* search algo on a whiteboard from memory.
I'm looking to see how they approach a problem they haven't seen before, how they break it down, what kind of assumptions they make, what ways they simplify it, how they consider ideas and tradeoffs, and finally how their ideas translate to code (fluently or not)
6) The majority of people I see cannot execute that last paragraph well enough to join a team at my company and be productive. Sorry, hackernews readers, but that's just the case. This isn't a "can't solve fizzbuzz" level of incompetence - these are good engineers who are likely stars at their smaller companies, and who can be relied upon to get the job done. But they would not thrive at a FAANG-level company because they lack some ability - either clarity/coherence of thought, or ability to understand their techncial domain in depth enough, or because they just aren't fluent at translating ideas into code.
edit2:
7) All this to say...if you're not FAANG++(Dropbox, Salesforce, etc I don't know)....stop copying us. You don't need this process.
Your company has fewer candidates, and you both can't afford to be as picky as us, and you don't NEED to.
Each of my previous companies (in the 200-500 person range) had a process of a simple coding question onsite, followed by a take home test that a decent candidate (and I don't mean decent for FAANG, I mean decent across the SDE community) could complete a reasonable solution in ~2-3 hours. We set expectations as "you could do it in a weekend" because certainly some people took closer to 8 and got hired.