I was an engineering hiring manager for several small startups. I never asked for coding on a whiteboard. I asked some work style questions and then concentrated on a collaborative exercise where I laid out a problem and important applicable technology. Then I'd answer any Google-ish questions in realtime. This technique found good collaborators and also which people were good problem solvers. Never made a bad hire from this method. I only wish I had discouraged others from "code on the whiteboard" type bs.<p>Great article.
The other day I got a PDF with prep materials for Facebook interview. It's a few pages of pure insanity, e.g. "In your tech screen, you’ll be asked to solve one or two problems in under 35 minutes. Practice coding solutions to medium and hard problems in less than 15 minutes each to help you be ready for the constraints during the
interview.", "If your tech screen is in person, you'll use a whiteboard"<p>Who can solve a "medium to hard" problem in 15 minutes, on a whiteboard, under stress, twice in a row? Who are they looking for? Leetcode psychos?
A lot of leetcode type interviews also skew towards people who can keep talking out loud while writing code. I can’t remember the last time I was programming and constantly talking out loud. I like to be quiet, focus and then write code. Preparing for interviews felt like I was a code monkey preparing for a special dance.
I ramped up to do a bunch of interviews last year after some covid layoffs and, I'd rather the format stayed in its current form. It isn't great, but I can study one style of interviews and apply that across the board to all the companies I interview for. The system interviews are easy, it's just talking about side projects or work I do for a living anyway. After ramping up and successfully landed a role last year I do a couple of leetcode questions every few days to keep my skills sharp.<p>I have been burnt doing so many take home exercises, getting ghosted, zero feedback declines that I am drawing a line under the sand and not doing them anymore.<p>The alternative is prepping for many different interview types, sometimes full of people blindly happy for candidates to burn a weekend in homes of getting a callback, other-times full of unprepared, unmotivated interviewers who pull crappy nonsensical tests out their ass. No thanks. While the leetcode style isn't perfect at least it's reasonably standardized and consistent. I'll stick with that thanks.
All I know is, FAANGs can get away with anything, because the supply of engineers is just that much.<p>There's no shortage of engineers who are preparing months and months on end, solving hundreds or thousands of leetcode problems.<p>There are coaching institutes, and an entire industry devoted to cracking these interviews.<p>The financial reward is worth it for most people.
Sometimes I think that FAANGs real power comes from their nontechnical hires. They pay top dollar for their CxOs, market strategists, domain experts, etc. With this kind of firepower, they can get along with any engineers. They just need to fill seats. The high salaries for software engineers are just to shackle their engineers with golden handcuffs so they'll stick around long-term, and not spread any secondhand strategic vision to competitors.
As a hiring manager, I find talking in detail about work (school or industry) a candidate has done is a lot more illuminating than a coding problem. The trick is that it takes more preparation and focus from the <i>interviewer</i> because they need to know how to ask the right questions, they must know how to guide the conversation in real time, they must understand details about entire project in a few minutes, etc.
Interviewing is one of the unsolved problems in computer science. I think take-home assignments have their own tradeoffs such as time investment by the engineer or the (I'm assuming) increased chance of cheating. You also still run into the question of what a standard take-home assignment should look like, and how to prevent take-homes from becoming a game in the exact same way leetcode has become a game.
We ask candidates to prepare a 20min presentation about one or two interesting projects they worked on. The whole dev team (8 people) is present and we all discuss it in a friendly, genuinely interested manner on eye-level, trying to understand what the candidate has build by asking design choices or more details on certain aspects, how error paths were handled, which trade off considered, how was the collaboration in his old team etc. Typically goes for 45min. The candidate is encouraged to ask the team any questions about how we work, what our tools and processes are etc.<p>We get to know candidate and the candidate us.<p>60-75 min is all it takes.<p>Afterwards we sit together as a team and share our impression, could we see working with them, did anybody see red flags, etc. Maybe 15-30min conversation. Then we reach a go-nogo decision right there and now. No coding questions, no brainteasers or similar.
Haven't seen a candidate yet that could bullshit their way through the presentation and crowd consensus decision.
I finished my onsites with a FAANG company. Recruiter comes back to me and says every interviewer gave you the green light but the hiring committee wants another interview with these specific questions asked.<p>By this point I had already spent 8 hours with them. Told them to beat it and stop wasting my time.<p>It's ridiculous how disrespectful these companies are to our time.
What I find utterly sad when I read this is that the rest of the world, no let me rephrase it: the actual world, both intuitively knows this process is wrong and operates recruitment differently.<p>Engineers of the world don't work at FAANG companies, just a very small subset of them. Engineers who want to work there are like teenagers who were told they must study at an ivy league if they want to something with their life. It's a small club, it is not selective at all, it is just not a club that a lot of people would care to join.<p>What I find more interesting to observe in this post is the recruiter himself. How he was led to believe an awful community was "better" until he realized he had to escape from it, and now he is teaching something that almost every engineer in the world already knows.<p>So, yes, I'll upvote this one but probably not for the reason I'm expected to :)
So your solution is take home coding. How is doing an assignment for every company I apply for better than practising coding questions that can be used in interviews at any company?
how many of the questions asked in the interview actually apply to their jobs? if you know of an example where it's really helpful to write a sorting algorithm correctly in 15 minutes, could you share it? :D