I believe I expressed my main idea in those four words in the title. They really do.
Why?
Come on, it’s not the 90s anymore! When developers’ beards were longer, and we didn’t live our lives online, this kind of interviews were cool, and useful. But today…
Today, we have the Internet (thanks for that by the way). And the Internet is literally full of white-boarding algorithmic questions. Almost every problem that can be solved in 40 minutes on a white-board is there, with tons of solutions. And that’s too bad.
If you ask any company why they do white-boarding interviews, the answer will be “It helps us to see how a person thinks”. No, it doesn’t! Not today. Today, such kind of interviews help to show how good interviewers and applicants are in exploring the Internet and memorizing existing solutions.
Let’s discuss why and be honest with ourselves. One note here. There are always extremities. There are always people who are exceptionally good with algorithms. But in today’s world, they are not average developers. They’re scientists. Here, I’m talking only about average.
So how does an average interviewer look like? Companies don’t hire specially trained people for that, that’s for sure. An average interviewer is a mid-to-senior level developer, who is busy enough with his own code, and last time used algorithms in college. He has a couple of algorithmic problems in mind (or just looked up these problems on the Internet before the interview), and knows solutions for them. The worst part, he expects an applicant to give the same solution! If not, well, “Good luck. See you next time…”.
Yeah, yeah, I know what companies say: “This helps us to see how a person thinks”. It’s not true. Let’s be honest, if you don’t give an expected solution, most probably you failed in the interviewer’s eyes. Unless interviewers teach CS in a college and work with algorithms on a daily basis, they expect a solution they know. Even if an applicant starts thinking about cool but different solutions, the chances are the interviews just won’t recognize this. Just because it’s not the solution they expect. Seriously, you should be way above average in CS to be able to adequately evaluate applicant’s logic and way of thinking.
What about an applicant. Well, if he is lucky enough, he happened to read a solution for the same/similar problem earlier on the Internet. If not, the only hope for him is to quickly think about a solution an interviewer has in mind. And be able to do this loudly on a white-board.
Don’t get me wrong. I love CS. Any developer must know CS basics. And some CS questions must be asked during the interview. How binary trees work, how linked lists work, what is a hash-table, how well-known algorithms work, and so on. Just basics.
Software engineering is mature enough. It’s mature enough to be tightly related to CS, but to be separated at the same time. You wouldn’t ask a structural engineer to create a new kind of concrete, right? Physicists/chemists did this already. A structural engineer should know how to use it.
What To Do?
So, what to do now? If you hire a software engineer (not a scientist), ask questions about software engineering. Ask to design a small feature, ask to write a simple code and check how clean it is. Ask what is happening on a background when the code is executed. Ask what is happening when a thread is created. And so on, and so forth. The sky is the limit.
These questions will help you see what kind of code an applicant is able to produce. They will help you see how experienced an applicant is, how well he knows internals of the technologies he is working with. What are the benefits for you and your company from hiring a person who is perfectly able to memorize solutions from the Internet, but can’t write clean, testable, scalable, efficient code?
Look at the big companies that persistently keep practicing white-boarding interviews. When was the last time they innovated, not acquired a small cool startup, but really innovated?
Next time, when you’re choosing an algorithmic problem to ask during an interview, find a couple of them with no solutions. Go to the white board and try to solve them in 30 minutes thinking loudly. Managed to do that? Ask 2-3 teammates to do the same. After that, are you still sure these problems are the best way to find a right developer for your team?
