3 ms·
A take from someone who asks these types of questions in interviews on a regular basis: 1) Don't just memorize this list. The fact that this list is publicly a
by robbrit 8y ago
A take from someone who asks these types of questions in interviews on a regular basis:
1) Don't just memorize this list. The fact that this list is publicly available means that we know not to ask these specific questions.
2) This is a very good way to practice the types of problems that are often asked in interviews, so if you can tackle these then you should be good to go.
A lot of people on HN and in real life (I've had people get angry for asking them to write code in an interview) hate these types of interviews. There's a lot of research done on this topic and so far, it's kinda like democracy. A crappy system, except for all the others. For all the complaints about this, I have never seen anybody propose something that satisfies the long list of requirements for interview questions.
Here's the list, pasted from an HN comment I made a few years back on a similar discussion:
Objective - the process avoids human bias (this guy was in my frat, therefore is awesome).
Inclusive - someone doesn't need extensive past knowledge in a particular area of coding to do well in the interview.
Risk Averse - Avoids false positives.
Relevant - it properly tests the abilities needed for a coding job, and not irrelevant ones (like the ability to write an impressive resume).
Scales - this will be used for tens of thousands of interviews.
Easy-to-do - this will need to be done by hundreds/thousands of engineers, who would probably rather be coding.
- siphor 8y agoLeadership ability, communication ability, team-work ability are probably more important factors than algorithmic ability in getting a project done, depending on the team. It seems the big-cos have figured that stuff out enough in order to make the development process as much of a meat-market as possible. However, these interviews would probably not select a maximal team for a startup. The big-cos are also leaving a lot of talent on the table -- which makes it silly when they talk about a "talent-shortage." But, they're also paying enough where people WILL game these interviews in order to get the job... So the best argument I've seen for why these interviews work is that it selects people who work hard at learning this type of problem solving, to get the job... which correlates well with how hard they will work at the job. Having an "objective" process is near impossible... and in fact probably not something one should strive for. Everything we do has humans has intuition behind it, whether good or bad. I think intuition is very important for finding a maximal team, especially a small one. "Inclusivity" is kind of weird here.. most often you'll want someone with domain knowledge to get a project going quickly.. It's definitely less important for big-cos, but you still end up interviewing for a web job, an iOS job, etc.. so domain knoweledge does come into play.. at least at the big companies I've interviewed for (google, fb, lyft, uber, etc..) I doubt this process is risk averse... you'll find people smart enough, but you learn little about their character. Relevancy seems like a joke in your list... unless all you need is people to iterate on a small set of already solved algorithms in slightly different ways. I'd say that applies to zero companies. Except maybe leetcode, which helps people study for these tests. The process scales well, and is easy to do, i think thats its strong suit... it's mostly effective across a ton of people. So in summary, I agree that it seems like the best known process for these big companies. but I doubt it's as risk-averse as you think, and if you truly have a talent shortage, it's an artificial shortage created by your interview process. You might need to take some risks on people if you need to grow faster... That being said, having that big-co process is great for startups! There's a lot of exceptional talent out there that will fail at the big-cos interviews, but will be better than their engineers for your team :) (There's also exceptional talent that will succeed at those interviews too, but would rather work at a startup) It might be a matter of using your intuition to find them... it's definitely a hard game. I think this recent data-driven trend that is spreading across all realms of companies is poisonous in some areas where it does not belong... Human intuition still wins in a lot of areas, if it's good.
- robbrit 8y agoYou're right, a lot of these metrics aren't as useful for startups and small companies as they are for bigcos. > Having an "objective" process is near impossible You're completely right here, however there are plenty of biases that can be avoided by attempting some level of objectivity. > I doubt this process is risk averse The risk-aversion is about avoiding hiring people that can't write code. You're right that it doesn't filter for character, which you will discover very quickly when working at larger companies! However a lot of the processes such as code review and design reviews help mitigate some of the bad character quirks that impact software. These processes are often not present at smaller companies, so the impact of character flaws is much larger there. > Relevancy seems like a joke in your list I'd say it's one of the most important ones on the list, especially for startups. When I was hiring for startups, I would get loads of people who could talk the talk but couldn't write a line of code. "Relevancy" means that your interview confirms that the candidate can actually code rather than just talk about it.
- siphor 8y agoInteresting on the relevancy stand point. As an iOS developer, I had to learn a whole new set of skills for the interviews... I can count on one hand the number of times I needed to use techniques needed for the algorithm questions. I feel like the skills around making large scale apps is more about being able to reason about large scale projects and keeping everything clean and tidy. I haven’t really met anyone yet who could talk the talk but couldn’t write code... I’ve definitely met people who have tried... maybe I have a good BS detector, or maybe I’ve been lucky? All people I’ve hired without doing the BST/linked list/DP problems, Ended up working out great. They probably can’t do those problems still, but they can code a damn good app. Guess it goes back to not caring about false negatives
- jammygit 8y agoWhile those are good traits in general, they don't narrow down on good interview questions very well. For example, I (non seriously) propose chess puzzles for interviews then: Objective - the process avoids human bias Inclusive - anyone can learn chess, and its played internationally. Risk Averse - Avoids false positives since the puzzles are hard Relevant - it properly tests the abilities needed for a coding job, like focus, dedication, intelligence, and preparation. Edit: I have friends in cs classes who have had to implement knight tours and queen puzzles for class as well, so its even cs relevant! Scales - this will be used for tens of thousands of interviews. Easy-to-do - this will need to be done by hundreds/thousands of engineers, who would probably rather be coding. Really, I think 'relevant' is the category most people contest. Note: chess really is a great game