Update and White Boarding
Hello All, just a quick update on the site unfortunately I have been quite busy with work and unable to update the site quite as frequently as I would have wanted. I hope to change that soon and will start adding articles in a semi-regular basis. The Electron and Kestrel series is going to be reworked because basically everything has changed in the world of dot net core in relation to build tools so alot of what I posted is already obsolete. As such I will begin writing a few smaller articles before getting back into a new series about electron and kestrel.
Next I would like to talk about something I have been reading about more and more recently on development forums. That topic is whiteboarding in interviews. Basically, its the argument that developers should not be asked to live code on whiteboards during an interview. Just a quick google search for “Whiteboard Interview” will net you many results talking about how to tackle whiteboard questions or articles about how hiring is broken because of whiteboard questions. Many people want to kill off whiteboard questions because they are unfair or do not accurately represent people’s skills. I whole heartedly disagree!
As a manager for my company I tend to do alot of interviews with perspective hires asking them questions trying to gauge how competent they are at software development. The number one question I always ask an engineer though is a whiteboard question. Before I talk about my question I want to caveat that I understand that not all whiteboard questions are equal I certain that some companies ask awful whiteboard questions that really are unfair, that is not though a good reason to get rid of all white board questions. Nothing is black and white, and I think we need to target bad interview questions and not the process by which they are asked.
My typical whiteboard question is “Code a function that takes an array of numbers and returns the array sorted?”. I add a few caveats with that question as well:
- Performance/Speed is not a factor
- Use any langauge or pseudo code you wish but it should be functionally followable
- They can ask any questions of me
- Please talk out loud your thought process
With those caveats and question in tow the interviewee goes to the whiteboard. What I am looking for in this question is a couple of things:
- Can they think logically about a problem suddenly thrown at them
- Can they plan what they need to do
- Do they consider edge cases that could cause problems
- Are they able to run through the function in their mind to test it out
After they complete the question I usually follow it up with some other questions
- If given a blank array what would happen to your function
- If given an array with duplicate numbers what would happen
- if given a null array what would happen
- What would be the performance of this array in big O notation (doesn’t matter if its slow just that you understand the performance implications)
- Given more time what would you do with this function
Usually I give about 30 minutes for the interviewee to go through this before I pull the plug and move on. In my time of interviewing people, I can count out of 60 or so people I have interviewed only about 10% of them could do this question. Only 10% could make a function that even semi worked some people thought they had a function that worked but when asked to run through it with a standard 1,2,3,4 array they could not do it. To me thats just unacceptable, if you can’t even write a sort function under those conditions then how can I trust you to write much more complex operations.
Most people bombed out right away trying to just talk their way out of the problem without writing much of anything on the board. Sometimes I can chalk this up to nervousness where the interviewee simply is worried about making a mistake or doing something wrong. I try to calm them down even try to help them get started and some can do it but others just sit down and reason it out with words. Unfortunately, words always work it’s when the code hits the page (or whiteboard) that issues arise.
Those that do create good functions have almost always been good engineers that I have at least tried to hire. When I consider the sheer amount of interviews I have done where engineers could not answer this simple question I wonder exactly the quality of engineer that exist today. I have a term I use for some engineers I see today the “Stack Overflow Engineer”, now this is nothing against Stack Overflow they are an amazing resource for information on programming and I visit them daily to understand a variety of topics. That said all too many engineers are losing their ability to think critically and develop code from scratch that works. Many engineers I believe simple copy and past code they find and insert it without fully understanding what the code does. When they come up against a problem with no ready answer they complete break down and become unable to make a progress. Engineers that are problem solvers, able to think critically and understand the functionally how methods are operating by looking at them are extremely hard to find. Those though are the best kind of engineer.
To me finding these engineers are the most important thing and using a whiteboard question is critical to differentiating between the two.