I am not a recruiter for large companies, but I have a lot of experience with small companies and a little common sense.
Back in 2013, I ran a very successful hiring campaign on AboutEcho.com which resulted in the hiring of nine senior engineers. My Russian-speaking readers could read about it here .
All of this gives me the confidence to criticize the methods the Internet giants use to hire engineers to this day.
Don't aim for the best solution
When you arrive for an interview, the interviewer poses a problem to you and expects a solution in 0–2 minutes. If you take more time, they will really get excited and ask them to say something.
This is understandable - after all, they only have 45 minutes and they want to discuss a lot of things with you.
I cannot understand how you are judged by the quality of the solution you came up with within two minutes. Because that's not how human creativity works. It's easy to come up with a lot of ideas, but it's weird to expect the best to always come first. Even geniuses cannot predictably generate the world's best ideas in a short amount of time.
Creativity is the ability to evaluate and filter the flow of ideas that you come up with. If you are really interested in this, why not ask the other person to compare and evaluate several ideas? Check if a person can evaluate the properties of the proposed solution? If he clearly sees the pros and cons?
And if you ask to come up with the best solution in two minutes, then you are testing your luck, nothing more. Are you in the business of hiring successful employees? Or capable?
Don't ask puzzles
How can I check if a linked list has a loop? Does one N-dimensional box fit into another N-dimensional box? Can you swap two variables without the third? How to find the shortest distance between two moving ships? Find all permutations of N elements by performing only N-1 permutations?
These puzzles are fun to talk about, and their solutions can be very helpful. As a child, I loved to have many of them read Math Fun and Essays . Don't get me wrong, they are hilarious.
However funny they may be, these are just anecdotes. The property of a puzzle is that you either know the answer to it or you don't. This doesn't tell you anything else. It has nothing to do with future performance, skill, ability, or anything else. Knowing a specific answer does not mean that you have an apparatus for solving real problems in a general and predictable way. The only thing it tells you is that the person was in this situation and someone shared a solution with him. No more, no less. Just stop already.
How to be saved before the candle burns the rope?
Be open to alternatives
This is somewhat to be expected, but big companies still seem to fall for it. If the interviewee offers an alternative solution, you, as the interviewer, have a chance to learn something. This is also a good chance for a deeper discussion if the proposed solution turns out to be impossible or bad.
However, I was fired for once proposing an alternative solution of the same complexity (and burdened with a lecture on "the only true approach to this problem"), and on another occasion I strictly led to a specific solution. In the latter case, the interviewer really wanted to ignore all my concerns and wanted to discuss only what he saw as a solution to the problem, and later left a "not impressive" review about me.
Nobody knows everything. Be open. Listen. Meditate. Yes, even if you are interviewing someone.
Be tolerant of flaws
Single errors are widely recognized as one of the most difficult problems in CS for a reason - everyone makes them. Errors are part of a programmer's life, not something to get rid of. A good programmer just knows what to do about it. The quality of a programmer is NOT determined by how few mistakes they make.
Now, if you only select people who didn't make mistakes during the interview, you magically don't get a team of programmers who always write flawless code. You just don't know how they will behave when they inevitably make mistakes.
So mistakes are actually good, because you will learn how this person corrects them. Do not judge errors, evaluate how the interlocutor handles them:
- simple code,
- divide and rule,
- self-tests,
- invariants,
- statement,
- compiling and running,
- testing.
Oh, sorry about the last two. I forgot that you don't let them run their programs. Well, what did you expect then?
Let me check!
Seriously, what is writing a program on a whiteboard?
I mean, I'm happy to discuss algorithms - since discussing abstract things is more efficient.
But writing programs for real programmers in a notebook? Without even running them? What's the point? Getting the first draft of code is only one-tenth of the whole process, followed by compilation, validation, tuning, testing, validation, and so on. Who are we kidding? These are essential parts of any programmer's workflow. It is useful to look at the code only when it has already gone through all this, and not before.
It's like asking the artist to draw a horse and then stopping him halfway through the very first sketch, when you see the four vertical lines of the legs and judge it. How much do you learn about her?
Explore deeper
Five short interviews? Or two long ones?
With five, you get five independent opinions, which is better than two. But how deep can you dive in 45 minutes? Practice shows that it is enough to write 20-30 lines of code and ask a couple of really simple questions (what is the difficulty? How to test?).
The next interviewer simply repeats the same process until the previous one. That won't last long. Not for long.
Why not make them two and make them really solid? For example, one before lunch and one after? Three hours is also not much, but at least you have a chance to see how a person tests the code, how he changes it, how it works with requirements - everything within the already established context, without resetting and starting from scratch every 45 minutes ...
With so much time, you can even ask him to write the code as if it were part of a system, not just an abstract algorithmic problem in a vacuum, and learn a thing or two more about its actual characteristics.
And if you want more opinions? Have a few interviewers in the room so they argue later.
Explore the background
I have fourteen years of experience (at the time of writing, 2019). I would be happy to talk about functional programming, distributed systems, consensus, replication, co-authoring, CRDT, parallel architectures, user interface frameworks, team processes, product design, user experience. I have practical and research experience in all of these areas. All of them are of direct interest to more or less any Internet giants that I have interviewed.
Have I ever been asked about this? No.
I get: "Imagine you have a function that takes a list ..." five times in a row. The five school-level tasks should give you an adequate idea of what? How closely have I read Cormen et al.? To be honest, they are rarely asked about them either.
Instead, customize your interview based on the candidate's experience. Talk about what he's good at. You will have the opportunity to ask deep questions and learn more about the level of experience and the benefits it will bring to your company.
Make the process smooth
Wrong direction? Delayed tickets? Application form requiring original Adobe Reader to be installed specifically? A cheap ultrabook with an unfamiliar keyboard layout and a bad web editor without any shortcuts that slows down even on a local machine? Sorry, I'm in the office of the most capable IT company in the world, right?
In my case, one recruiter was doing five interviews a day. Five people every day. Multiplied by the number of recruiters in this company. Imagine all of these candidates are slightly frustrated with the process. Everyday. Year after year.
You might think it doesn't matter. Depends. There was an episode of the TV show "Louis" where the name of the comic was written on its door. Therefore, he argued: yes, this mistake is easy to make, but it is also easy to fix. It doesn't matter, it's just for one day, if you are even a little worried, please do it right.
Yes, I believe that anyone can do better.
Finally
If you hire software engineers, then the practitioners of large companies are not your friends. Common sense, fairness, tolerance, real interest and open-mindedness are friends.
Good hiring!