I don’t bother with “whiteboard interviews”.
It is not very hard to conclude what my stance is on whiteboard interviews from the title of this post. However, I think my position deserves an explanation because it’s not nearly as simple as a personal dislike. There is a right and a wrong way to conduct any interview. Whether it involves a whiteboard or does not. To me the issue is two-pronged: lack of human connection in the process and initially a failure of the education system to properly prepare us for the real world.
At the basis of the problem we have an inability to communicate. Traditional job description aside, an accurate representation of the day-to-day responsibilities is paramount. As a hiring manager you must know what is required, how to explain that to the candidate and what you are willing to offer to satisfy those requirements. Many hiring managers pride themselves on being “great communicators”. If I may offer a word of caution here, truly great communicators know how to listen, understand and empathize. Excellent communication does not equate with exciting story telling. We are concerned with HR, not PR.
As I will mention throughout the article, an interview is a first step to a long-term (hopefully) relationship. Therefore recognizing that you are actually establishing a human connection is significantly more important than flipping a binary tree.
During the last two decades of my career I have seen plenty of interviews, likewise I hired people and built a number of teams for startups that went on to become major brands or at least raise a few million in funding. Couple of projects, where I got lucky enough to be a senior developer (tech lead), are used by millions of people today. Since I’ve been on the both sides of the table, the views offered here apply to hiring managers as well as engineers looking for a new position.
The topic of the whiteboard interviews goes back to the early days of web development and a turning point for software engineering in general. The technique, unsurprisingly, was born at Microsoft. In no small part due to Bill Gates’ fascination with puzzles. Originally the interview questions were rather different from what you might experience today. Many were hardware oriented, many referenced circuit board diagrams. During the early nineties we didn’t have LinkedIn or Github, the internet was hardly accessible via a slow, dial-up modem, therefore providing some measurement of technical competency was much more difficult. Besides Microsoft and IBM there were only a handful of tech companies (never mind web development). One thing is certain, we didn’t have hundreds of tech startups. The landscape of web development was reinvented at least twice in the last twenty years. With mobile and blockchain engineering still remaining the next big thing as of today. Despite the many paradigm shifting advancements, the problem of whiteboard interviews as well as canned coding interviews remains to this day. We have evolved by leaps the bounds, yet the process had stagnated.
One of my favorite articles on this topic appeared on Hacker News back in 2012/2013. It is a humorous and accurate analogy of how most of the whiteboard interviews are conducted. Of course it might be exaggerated at times, but more often than not, the story relates an accurate sense of the traditional whiteboard interview process.
Asking someone to write a maze algorithm on a whiteboard is nothing short of dumb. Asking a front-end developer to find a longest substring without repeating characters in C# or Python or Java (or even JavaScript) is just lacking common sense. Whiteboard interviews are impersonal, unoriginal and usually show that the hiring manager is too lazy or not confident enough in their own ability to conduct an interview. If your idea of a good interview process is to google some problems (for which you personally don’t know the answers) I sincerely feel sorry for anyone who has to work with you.
— “But I don’t care about the code! I want to know how someone thinks and performs under pressure”.
— Did you have fun on your power trip?
I don’t know what your exact title is, but I am nearly certain that you are not conducting military operations nor hiring bareknuckle fighters for your next quest. You are hiring people who have feelings, emotions and character. One would hope that these people will help you create amazing things and be a part of your life for the next couple of years. How many times did you use a whiteboard when starting any relationship? Sure, it would be great to know how your significant other performs under pressure and deals with adversity. Would you really stoop down to asking them to write their approach to conflict resolution as an algorithm on a whiteboard? Or unit test a scenario where you got caught staring at some person’s butt? Seems absurd and borderline crazy. Then why is it acceptable to behave in such a way during the interview process?
It’s a real shame to get into a relationship based on some predefined algorithms and canned Q&A rather than actual merit.
Sometimes people get nervous during interviews, sometimes I get nervous conducting interviews. Watching a candidate squirm while trying to live-code some random solution does little to bring out the good qualities of that person. Never chose on the basis of fear. If you weren’t satisfied with someone’s performance when you tried to bully them, do not chock it up to the candidate’s weakness. It is your failure. Rather, try to bring out the person’s strengths, help them get passionate about your project and their role. Help them shine; do not cast doubt and shadow.
Empty complaints are just that, so let me offer you some food for thought from my experience.
How do I conduct an interview?
First and foremost, I get to know the person. I mean beyond “what’s your name?” and “where are you from?”. I like to ask about past challenges and successes, memorable moments at previous jobs or cool things that happened on recent projects. I will happily share challenges that we are faced with to establish an actual connection and have a real, honest conversation. I am genuinely interested in learning more about the candidate. I do not wait for the next opportunity to interrupt and boast about my accomplishments. A decent “get to know each other” process easily takes 30 to 45 minutes.
During this interview (just call it conversation), for another 60 minutes or so, we’ll talk about technical topics. If you are a front-end developer I will likely ask you something related to modern frameworks, your thoughts on Virtual DOM and why do you prefer Vue over React or perhaps you are an Angular fan? I’m genuinely interested to know. What do you like about arrow functions? Do you use semicolons (why/why not)? Tell me a little about composition and if you have some examples of how you’d use a lens in JavaScript.
If you are more of backend engineer, we’ll talk about patterns and queues. I’ll ask you about microservices and your thoughts about GoLang. I’ll ask you about your trouble with package managers and how you’d improve some existing architecture. It wouldn’t be unusual to chat about specifics of Lambda on AWS (if the jobs requires it) or review some issues with Laravel’s Eloquent ORM. For a DevOps engineer the conversation would touch on a set of different topics.
Who knows, we may even talk about Scrum and what it means to be agile for you and what your hobbies are. Bottom line, I would never ask something that I don’t know or don’t understand myself. If I can’t comprehend the answer without looking at my notes, I am probably asking the wrong question. After one and a half to two hours of such conversations it is pretty clear whether there is a cultural fit and whether the person has enough technical expertise. If I am speaking to a college wrestler, I know everything I need about their ability to handle pressure.
Let’s not think that I suggest to be completely ignorant of any “proof” of technical knowledge. I will ask for some code to review. Surely someone with a couple of years of experience in my field would have a few lines of code on Github or could put something up for review? … Quite often a homework assignment may be appropriate. I do not suggest that you tell someone to code you a “missing” feature for your project. This is simply disingenuous. The assignment should be a simple task that you or your team had solved in the past. For a web developer I might ask to write an integration with my favorite service using a queue and representing this simple flow: form -> database -> queue (?) -> external service.
What intrigues me is the way this solution is going to be coded. Languages and frameworks should be specified, and relevant to the position. Then I can look for things that are inherent to the framework, like Routing setup. Or usage of the provided data validation and pitfalls of SQL injection. Is the state managed correctly? Are migrations prepared for building up the initial database. Likewise I am looking for patterns. Code readability and consistency. Docblocks, tests and namespaces are all important. Minimizing dependencies is important. Not having too many if/else blocks or gigantic Controllers or incorrect usage of MVC or broken DRY and SOLID principles.
After all that, if I made the wrong choice, I will have to live with that or be shunned away.
Team players
The thing is, if a person is the right fit I can tell that without necessarily having to subject them to coding stacks and sorting bubbles. You never use that in web development. Sure, there is exception to every rule, but take 90% of the web engineering jobs out there. If someone needs the knowledge of Big-O notation to conclude that nested loops with a database call in the middle just aren’t a good idea, then I’m not sure if this abstract concept is going to be helpful to solve real-world problems. Common sense often supersedes knowledge of data structures.
I have come across multiple brilliant engineers who were eventually let go, because they couldn’t fit and work with the team. It’s an unfortunate side-effect, but if there is a certain level of unfriendly competition, when one has to prove that they are better than the rest, that creates an immediate lack of trust. A breakdown in communication. The entire team is slowed down.
Once we interviewed a developer, an extremely knowledgeable one, who came from a company that hires only the small “top percentage” of all engineers world-wide. Their selection process is rigorous. Multiple interviews, live coding, homework assignments, video chats and a small project to build. The only problem is that it’s 90% technical and 10% personality. For the record, I failed the interview process on the 3rd step when I didn’t score high enough on data structures. I did notice a surprising lack of interpersonal communication during the interview process. Well, back to the story…
Once this developer passed all the filters it was time for us to have a chat. Surely I didn’t doubt his technical skills, and went on to describe our stack which consisted of MySQL…
— Why not Postgres?
— Umm… just doesn’t matter so much. We’d like to get a beta client…
— But Postgres is better for financial applications.
— It probably is, but for the time being let’s focus…
— You should really start with the right foundation. Let’s first rebuild the database layer.
Pretty much how the conversation went. While he might have been right, he couldn’t spend two minutes listening. Not a team player. Make a note, listen to what the other side is telling you. Then discuss, if you wish, with some degree of eloquence. Five minutes later I would have mentioned that we will be using Oracle in production and since ORM is DB-agnostic neither MySQL nor Postgres database would be applicable to the conversation.
Ability to work with others is necessary, not everyone is going to be equally smart or as quick or as well versed in a particular subject. Do not assume the role of a gladiator, rather be a mentor. When all said and done, given a similar set of qualifications I would hire an ex Navy SEAL any day over someone who can figure out how to find second largest item in BST.
Education failure spills into the interview failures
The second part of the problem is an old debate that stems from the poorly structured education system. The concept of testing in order to make everyone fit the same mold is rather outdated. In his excellent book Free to Learn, Peter Gray succinctly says that we took away kids freedom to play and therefore their instinct to learn. Memorize and pass the test cycle isn’t the best method for continued education. It is definitely not the best way to teach. This topic is hotly debated with many opposing views coming from both sides of the camp. Still, it seems unreasonable to continue on such a controversial approach, when it comes to hiring someone. We are done with theoretical approaches, it’s time to solve real-world problems.
Yet, the amount of times I’ve read about people studying for an interview seems rather off-putting. “Oh boy the interview is tomorrow, I better cram some more knowledge into my head, so I can pass the stupid test. Then I can chill out”. This is wrong on many different levels. When a boxer is getting ready for a big fight on Saturday, they do not spar on Friday. They take it very easy because years of training and months leading up to the fight they boxed day in and day out. They spent a long time getting in the best cardio shape, cutting weight and working out a strategy. Nobody wants to be become a boxer in twenty one days. That’s dangerous and stupid. Learning python in twenty four hours isn’t going to yield better results.
I wouldn’t want this to be misconstrued as though I am advising against learning. Quite the opposite, you should always learn and expand your horizons. The key point here is to do it for the right reasons. If your dream job involves knowledge of algorithms and data structures, then by all means study them in depth and spend a decent amount of time working with relevant projects. Open Source projects are always looking for new contributors. Getting hands-on experience with your favorite technology isn’t very hard (even if you don’t have a job). Memorizing a few things for the sake of passing an interview is lame, understanding the concepts and gaining actual experience is the way to go.
I do not spend time preparing for an interview because what I do day to day, hour to hour is what gets me ready. If I don’t know what to say, how to answer a question or how to demonstrate my knowledge of a particular subject, then I am applying for the wrong job. If you are just starting out and have no job experience or completely switching careers, that might present a slightly different set of circumstances. However these situations should be an exception and not the norm.
In the end, it’s up to you
Although tech giants of today (Google, Facebook, Amazon, etc.) have adopted coding interviews as part of their hiring process, one should really wonder why does a ten person startup would use the same procedures as used by a multi billion dollar behemoth? To some degree I can understand why large tech companies might employ such techniques. They have entirely too many people wishing to join the ranks, they need multiple filtering systems to find the best of the best. However during this “filtration” process you also lose personality. There is nothing exciting about a cookie-cutter interview. And really there is the regime of coding and HR processes on one side and a really laid back atmosphere of a small startup on the other. You don’t have to attach to either extreme. My choice is to be somewhere in the middle, preferably with a comfort and excitement of a startup. This is the place to learn to grow to fully appreciate your input on the company and customers. At a big company you are likely to be a pawn, while in a startup environment you can truly get the unique experience and perspective into the culture and rub shoulders with interesting people. And it’s not necessarily the size of the company, often it is the atmosphere of a specific project. Still there is a certain feel when you are not twenty layers removed from the CEO and everyone works together towards a greater and visible goal.
There are two paths: one filled with wonder, adventure and pitfalls and the other one full of hopeless souls. Make the right choice for yourself.
I cannot tell you to avoid such interviews if this is what you desire. However, if you are of the same mindset as many who see such interviews as degradation, then I ask you to challenge the status quo. Your career and reputation is at stake. If you aren’t offering a solution, in this case you are definitely contributing to the problem. Do not succumb to unnecessary pressure from someone who tells you how to conduct yourself. Stand by your guns and I assure you that there is a time and place to utilize your talents to the full potential. Whiteboards need not apply.
But we have the best team and use whiteboard interviews, and everyone is happy!
Cheers.
Originally published at zen of coding.
