I recently came across this tweet from DHH (creator of RoR):
Basically, he hates tests that ask for algorithms, riddles and problem solving through whiteboards. Do you agree with him?
I am afraid that programmers might take this as inspiration and start hating whiteboard tests.
Oh man, I have so much to say here. But, programmers already hate white board tests. Hell, I think algorithmic tests are totally dumb.
When I'm building out a team of developers, I probably need 10-20% of people who are "algorithm ninjas". That is, their focus is on highly complex, single-node logic. Everyone else needs to think about systems, ticketing, bugfixes, writing up good documentation, talking to marketing, investigate that issue that maybe might be happening, etc.
Most of the job requires a smart, communicative person, who may or may not nail an algorithm question.
In fact, a good friend of mine is a super senior engineer at Google who keeps moving up their ranks running more and more systems there. However, he failed the Google interview 4 times. In fact, if he had failed his last time, he would have had a lifetime ban on interviewing there. He passed the last test because he bought some books and took a weeks vacation to read up on his old CS stuff.
He says he's never used any of those skills in his job.
I find that having a conversation about software engineering tells me boat loads about someone's level, passions, focus, and experience. Just ask "Have you ever used memcache before?" .... and even if the answer is no, describe it a little. Then let them discuss what they think about it and see if they understand and can share their pasts with different, maybe similar, systems.
Or hell, depending on whatever you want out of someone, find out if they are great at the thing you need.
Okay, I have to stop myself from ranting too much.
For people who hate such process:
I see these kind of interviews as a complete failure. I know my stuff but I have an analytical approach and I'm not a salesperson in any way. Since I believe that this is the way to tackle complex problems I find it as an anti-goal to put people of for these tests except of you are to hire a person that you want to give a lot of speeches. I have tried all these kinds of interviews in the past, most failed me because my lack of presentation skills and maybe talkativeness.
In other words this makes you target someone who is very good at taking a lot but not necessarily as good delivering quality work, in my experience these things not so often come together.
Better give an upfront task to solve and base the interview on this task.
I tried one that was very good and force you to prove a range of skills while still being a small task: https://blog.emilmoe.com/bowling-score-simulation/
I have a different view on this than probably a lot of people.
In my book, the simple act of asking you to draw something out on a whiteboard is not bad. What I feel is kinda funny is when a company goes down the textbook list of basic programming questions and judges a candidate off of that. The reason being, this is not an effective measure of skills and/or passion for any field. IMO, a more effective approach is one highlighted by Casey Muratori of Molly Rocket games in this video.
The video is quite long but it's definitely worth a watch if you are curious and/or are preparing for any type of programming interview. For those who don't know, Casey created Granny 3D when he worked at RAD game tools, a developer's tool used in over 3,700 big game titles, including Age of Empires, The Sims 3, Halo, and many others.
That all said, a couple more things:
I mostly agree with this.
I do believe that basic generic algorithms are absolutely necessary for programming roles as they their uses keep showing up; Things like algorithmic complexity analysis are quite essential for most non-trivial programming jobs.
However assessing interviewees by unrelated questions totally irrelevant to the problem domain of the role is a prevalent anti-pattern that plagues the industry.
Riddles/adhoc-puzzles may have their uses but for a large number of programming roles there is absolutely no correlation with that skill set with the every day work that candidates would end up doing as a part of their job.
Last time I got asked computational geometry algorithms for a Rails developer position, I politely thanked the interviewer and declined subsequent interviews. In another bizarre scenario the interviewer, in a surprised tone, asked me why I was not using an "efficient" language like C/C++ for solving the problems; their own codebase mostly used node.js.
Most of the good interviews I have been through used a live programming environment. The best interviews I have been through used TDD. TDD may not be ideal for all development, but it works pretty well for programming related interviews.
In all interviews I have myself conducted I have encouraged candidates to freely use REPL (I mostly work with dynamic languages) or other tools they would normally use while programming. I do, however, take note if the editor of choice is nano.
as Siddarthan Sp said. Saying "write me a bubblesort in variation a" is not really your daily business unless you're hired for algorithmic. But if you use a whiteboard for basic questions like "lets write a simple game in pseudo code together" to me that's a fair thing because the process of problem solving is integrated in an interactive matter ... on the other hand ... I have better things to do than whiteboarding and I take growth, ambition, styles and other things into account. Which can only be done by having an internship or something similar ... I like to see how people work and how they behave superficial things are for HR :) ....
I'm not a fan of whiteboard interviews and I wouldn't recommend them as a valid hiring process. I would rather have the candidates come in and have a chat with the interviewers and solve a design problem.
That being said, thinking using a white board and writing pseudo-code to a problem does actually show that you can design algorithms, which kind of matters.
Sorry for the typos, it's my stupid phones fault ;-)
Joe Clark
Full-stack developer specializing in healthcare IT
I'm not a fan. I don't program on a whiteboard. Ever. Why would I use that in an interview. Yeah, yeah, I realize that's so everyone can see. Ever hear of a projector?
Whiteboard aside, algorithm-centric interviews aren't that great either. I was once asked to solve the Fibonacci equation to the nth level or something like that. I didn't even know what the Fibonacci equation was. After struggling through the interview, and realizing I was failing miserably, just before I left, I asked the people in the room, "So... do you use the Fibonacci equation in your software often?" Of course the answer was "no". "Then why did you have me do something you yourself don't do and you clearly knew I didn't know?" I was pretty ticked off. I swore then that if I ever face a whiteboard or algorithm-centric interview, I would stop the interview right then and there and politely decline. That's not a company I want to work for. It's a lazy and amateurish way of vetting a software developer.