Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> When I ask people at trendy big tech companies why algorithms quizzes are mandatory, the most common answer I get is something like "we have so much scale, we can't afford to have someone accidentally write an O(n^2) algorithm and bring the site down".

I think people who say this just don't get what's really going on here. If you look at these types of interviews, a big part of what they select for is: 1) Some sort of problem-solving skill that's a mix of raw intelligence and/or ability to solve problems by pattern-matching to things you've seen before. 2) Ability/commitment to work on something that may not be that intrinsically motivating, in the context of getting/maintaining a certain type of job.

These interviews select exactly for that. To pass, you usually have some mix of: - raw intelligence. - ability to pattern match to similar problems you've seen before. - ability and motivation to spend time preparing for these types of interviews, even if they're not really what you care about doing.

That's really what they're trying to capture. It's not a perfect filter (you will still have some false positives and plenty, plenty of false negatives), but it works "well enough".

You really only need one Dan Luu per like 10 or 100 engineers at a FAANG. Most people aren't going to be optimizing at the level he is, they're going to be doing work that's mostly a mix of problem-solving by pattern matching, and ideally, they're motivated enough to have that job for as long as possible.



I think most interviews are designed to find people similar to the interviewers, whether they realise it or not. If you think it works "well enough", I think you're just fooling yourself.

I say that as someone who has gotten a job offer from every interview I've been interviewed, and done maybe 100 on the interviewer side of the table. I put far more weight onto pair programming and anything that resembles a work sample than anything else. And even then you don't really find out what people are like until like the tenth pull request or so.


Getting an offer from every interview is impressive, good for you (you don't cite how many but I'm assuming you've done a good number in different contexts). Even the smartest people I've known have had mixed luck with interviews, due to some combination of randomness, poor interview design, or just poor fit for that company. As for administrating 100 interviews, you'd prob rack those up in a 2 year stint at a FAANG (usually they'd start you around 6 months in or earlier and you'd do 1-2 per week thereafter).

Anyway, yes, interviews are prone to bias. So are work samples (in different ways). Pair programming can be better but logistically harder (i don't know any companies that have been able to do them at FAANG scale), but even then, like you said, you'd need a lot of it to really judge.

At the end of the day, the entire hiring process needs to work "well enough" and with reasonable cost to both company and candidates. For many FAANGs, these interviews (plus hiring committees, bar raisers, or something else) meet that criteria... Though honestly, they often fall short on diversity but that's a whole other topic.


I'm 40 (ouch!) and I've done about 6 serious interviews - other conversations over lunch and whatnot, that I didn't pursue - I'm not a serial interviewer, granted. Three job offers I declined.

Where I work today, I'm in the last round of interviews, to try and reduce the time consumption.

My real point is that a work sample is really hard to get in an interview, and it's really not fair to fire someone in their evaluation period because they're only average, and not extraordinary, with what they come up with in day to day work.


Friendly reminder that 40 is not old


Pair programming is a horribly inefficient way of programming, what companies actually use it?


> Ability/commitment to work on something that may not be that intrinsically motivating, in the context of getting/maintaining a certain type of job.

I remember a blog post which was ranting about the current culture at trendy big tech companies (has since been deleted [0], probably the author still wanted a career at such a company) in which a quote resonated with me a lot: 'we're not problem solvers, we're problem endurers'.

Someone solving hundreds of leetcode problems to prepare for an interview just signaled that they are willing do do basically any tedious piece of work you throw at them.

EDIT: [0] Found it: https://web.archive.org/web/20160308032127/https://medium.co...


This exactly. But I also think that what happens is once people get inside Google or FB, there's a second level of filtering to actually get put on good projects. Most of the engineers they have just need to do what theyre told. A few get picked to help write the next generation computing platform, distributed deep learning, etc.


While I don't disagree at all with your assertion that a mixture of intelligence and commitment is highly desirable - and that these are indeed exactly what these interviews are designed to select for - I'd argue that is part of the flaw with these interviews. The problem being that even if you as a hiring manager have successfully selected for people who are able to work gruelling hours on nonsense algorithm puzzles for the benefit of advancing their pay or career, it does not necessarily imply that they have what it takes to be a good employee.

As a manager, I want people who are hardworking, sure, but how I can I know that they're working on their assigned tasks instead of studying up for interviews and trying to jump ship? Also, I want to work with people who are creative, empathetic and collaborative (the latter is a hugely important trait perhaps even more important than raw algorithmic interviewing ability in a highly teamwork driven discipline like Software Engineering) - none of which these kinds of interviews help with. Or maybe I want a mixture of people with different strengths and weaknesses, like a team with an algorithms expert paired with a creative problem solver that can figure out new approaches to business problems. Applying a uniform standard involving mostly rote memorization and practice of the same set of interview puzzles to everyone is in my view antithetical to building a strong engineering organization. But you're right that it works "well enough" and no one has found alternative solutions that work better so it is unlikely to change in the near future.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: