Tech interviews are an evergreen source of delight /s. I have been the interviewer and interviewee plenty. A few reflections.
- I try hard, and I believe with a certain success, to follow a sound approach to interviewing. I read the resume, I see where their contribution to the team I am hiring for can come from. Then, false positives and negatives never go to zero, and such is life (although some people are much better than others at observing and judging). I mean, people get married and divorced in 6 months, and it follows that there are inevitably bad assessments also in tech. But I try to ask questions that can allow me to gauge the skills of the person in front of me for the job that they are hired for. A conversation, more than a test. Things that can get googled are of no interest to me, for example. Or theoretical and never-to-be-used-IRL knowledge.
Can you imagine do a try-out for a hoops team, you are a guard, and they try you out as a play? Or you do a try out for the Patriots as a quarterback and they test you on punting? Which is what happens in tech more times than expected by chance.
- Among the most nightmarish experiences I had as an interviewee, I remember: a hiring manager yawning for the whole interview; another time, I successfully (brilliantly?) completed a coding test in a few minutes and the interviewers said it was all great, I have no other questions. But then the recruiter told me that no, the interviewer felt that coding was so and so (what?). Another time I was dismissed after the first of five planned onsite interviews. No idea why.
- What about homework, you may ask? I took a few (2 or 3) homework for some of the most popular companies in SV. Well, one time I made this model and I don't know, maybe I will die an Achilles death for my hubris, but I believe I can fit a tree-based classification model after 20 years of work. The recruiter said that both graders like my model, but I did not do hyperparameter optimisation. I told them that the optimisation was both in the documentation of the homework and the associated Scala code. They said they were asking the graders again (it was just one, the other copied what the other wrote) and that they would have been back with an answer in a week. After a gentle nudge, they said that no, the graders did not like it anyway (they never took a second look and I wasted my time: for what, exactly?). I am not gonna take any other homework from any company, if not for reasons of desperation or destitution and I hope it won’t ever happen.
- Most companies rarely if ever do any business or technical analyses of their interviews. Google pollinated the tech world with their interview strategy and the other companies said: if Google interviews this way, why should we do any different? I work for a big company now, there is no post-mortem, and neither pre- nor middle-. We hired more than 100 people this way for a new team, it could have been better, worse, who cares? Nobody checks anyway. Because, and this is the main insight I’d like to present, especially for big companies (for start-ups it is different, an exceptional IC can “make” the company), it does not matter. There is a big area of 20+-D skill-space that is “flat” with respect to the employer’s contribution to the company. You don’t hire that uber-incompetent and you are doing fine because the market, overall economy, luck, people skill of the C-suite are much more important than ICs, managers, or directors’ skills (beyond a certain threshold, of course).
Google prefers to hire talented people and then it does not allow them to work on anything crucial because the most important thing is not letting them work for other companies? It does not matter.
And if the question is: but if the interview process is inefficient, are we not wasting thousands and thousands of employee-hours? I have got the same answer for you: it does not matter, because there is often no need (in big companies) for more than 20% of the time of the employee, people get hired for all sort of reasons, but rarely for (true) technical or business reasons.