All about the process of building good software.
Interview Whiteboarding
After an awful interview yesterday (for multiple reasons). I'm curious how frequently those here use or encounter algorithm white boarding during the interview process these days. I've only run into it for the local (on site) positions I've interviewed for, all the remote interviews have been actual code in one form or another.
Due to personal reasons (dyslexia) the white board approach is nearly hopeless for me. I'm curious if others find it valuable over real code situations, or if this is a function of the local jobs being at old school Java shops.




I'm not a fan of algorithm whiteboarding at all. I think its difficult for some personality types to really shine when someone is lording over you writing on a whiteboard. I personally prefer giving an easy homework assignment to give someone some time to reason about a problem then bring the result. Not anything drastically hard, just something to give myself and the team a sense for how you code, style, approach, and how well you take to doing a potentially skull numbing task.
If an engineer has a github repository, that does go a long way in helping understand how an engineer reasons about problems and approaches solutions. We tend to be far more disciplined about code we're passionate about so our deeply rooted convictions will come out in personal code. Like abstractions, you'll use them for your personal TODO or Finance app, if you hack at things with little to no defensive programming, that'll show too. Exceptions, those will be apparent as will your commitment to documentation be it self documenting code or blocks of pseudocode before you actually write it. And if you have no repository, maybe this is a 9-5 thing for you, thats good to know as well, maybe thats what we need.
I think the interview is all about personality and team fit. I've worked on teams where those two pillars took over before skill and it's made for better team cohesion. Skills can be developed, taught, and improved upon, but fixing a conflicting personality is the hardest problem I've personally had to do as an engineering lead or manager. Toxic relationships will sink any project no matter how much of a rockstar you or your team mates are.
That reflects my feeling for sure. And thank you for reminding me, even if indirectly, that I wasn't the only one interviewing. The atmosphere and the lack of any real interest in me at all during the interview are huge red flags for me as far as joining the team goes.
Oh yeah, as the interviewee, you are trying to find out if thats a team you want to be a part of. Sorry to hear the job didn't work out, but you may have dodged a bullet there.
Not often, maybe less than 10% of the interviews I go to involve a white board (not sure if something I do is screening out white boarding places or if it's just not popular).
I don't usually mind white boarding per se so much as I have the view the hiring is mostly broken. If the expectation is "We have 10 minutes together, I will give you a problem that someone in this position will be expected to understand and you will write something like code that probably mostly works (although you have no IDE, google, or tests while coding)" then I don't mind. They asked a question, I slowly pick it apart. I miss a few parens or an edge case, but if we got every edge case every time we wouldn't have to write tests or have a QA group :)
What I mind is when the expectation is "Impress me". They ask something about finding object patterns in 3 dimensional space when I'm interviewing for a position that has nothing to do with that. Or when I come up with a solution that's like n^2 and they wanted an n*log(n) solution. "Impress me" is a pretty arbitrary criteria that filters out a lot of great candidates for no real reason (your ETL process doesn't need the next John Carmack as a new hire... he'd be bored working on ETL anyhow).
I couldn't agree more with this comment.
Hey, at least you are getting invited onsite. I'm interviewing in the SF Bay Area and have yet to secure that coveted invitation.
I've only had one node tree algorithm, but it was a take home. Most of the technical stuff has been multiple-choice or playing around with real world code.
I would say about 80% of the interviews that I have been on had some sort of coding exercises. I assume that it is more common if you are coming in fresh and have nobody to vouch for you.
As far as the usefulness factor - I really think it depends on what the interviewer expects to get out of it. I have always looks for the understanding of concepts and how people problem solve. I want to understand that you know what types of structures you need to search an array for the lowest value, how many variables, etc. I suppose that this would be similar to asking a contractor what type of materials they should use when framing a wall. I would probably question their ability if they started mentioning shingles and left out 2x4s.
Of course, there is going to be some people that are looking for perfect code - and that is unnecessary and won't really add much value.