This || this: Whiteboard interviews
Ed note: This is a part of satirical series where an author plays both sides of an issue, one of which is obviously terrible. Can you guess which is which?
Whiteboard Coding is a Terrible Way to Evaluate Candidates
Our industry needs to own up to something we’ve all known for a long time: whiteboard coding interviews suck. At best, they’re ineffective at measuring a candidate’s capacity and aptitude for the real day-to-day work of a developer, and at worst they’re an inhumane ritual that amounts to little more than fraternity hazing.
I have never, in over 20 years as a professional developer, had a single project that required me to stand at a whiteboard and implement an algorithm in front of someone in order to do my job. It’s not a realistic representation of how someone works. Imagine a lawyer in a job interview being asked to write a landmark Supreme Court dissenting opinion from memory on a whiteboard. Or forcing a barista to stand in front of you and implement an eco-conscious coffee supply-chain strategy. Or asking a comedian to write a third funny thing with a dry erase marker that barely had enough dry erase juice to write two things.
It’s just not realistic. The problem at hand will either be too trivial to be useful or too hard, basic, or esoteric to be representative. Not only will your candidate never have a reason to implement their own sort algorithm, but if they did, you’d get mad at them, because whatever language you use has its own already-optimized implementation. And sure, I guess asking someone to reverse a string in place tells you whether they have an encyclopedic knowledge of the language API for those all-too-common occasions when they’ll be working on a feature in an alternate timeline where the internet doesn’t exist, but then when you have them determine if a string is a palindrome, you’re doing so ignorant of the cultural differences that might prevent you and the candidate from having a shared understanding of what a palindrome even is.
Whiteboard coding interviews create and reinforce monocultures. They eliminate candidates who have different strengths and communication styles than you. They eliminate people who don’t have the means to buy books, take classes, or spend all their time studying for whiteboard interviews (the fact that there’s a whole cottage industry around whiteboard interview prep is prima facie evidence that whiteboard coding is not the same as on-the-job coding). They eliminate people who may have a condition that prevents them from being able to perform as well in a whiteboard interview but who would otherwise make excellent teammates.
Whiteboard coding doesn’t help you observe how a candidate thinks or approaches a development task any more than watching a lion get fed in the zoo gives you insight into how she takes down a gazelle on the savannah. A candidate in a whiteboard exercise is in fight-or-flight mode, and the problem you are watching them solve is the problem of how to survive this insidious exercise and get the job.
If you want to see how someone thinks about doing real work, give them something that approximates real work. Have them do some one-on-one pairing with people they’d be working with. Give them a small open-ended take-home project that shows you how they really approach application development. Even better, pay them a fair price to do a small freelance project and see if they’re a fit in an actual real-world scenario. It’s a small investment in actually finding the right people for your team.
The bottom line is we don’t need whiteboard interviews. The only people that like them are sadistic voyeurs that get off on the suffering of others, and even if that’s you, there is so much reality TV you could be watching to get your fix. Find better ways to evaluate candidates. While there may have been some value in limited situations to whiteboard interviews in the past, both technology and psychology have advanced to a point where there are clear better ways. Just like we created penicillin to cure bacterial infections and created jQuery to cure Internet Explorer, we can cure bad interviews and build healthy teams as a result.
|| 10X Developers are Forged in Fire
I’m sorry, was Ra’s al Ghul being a sadistic voyeur when he was honing Bruce Wayne into a world-class assassin? Was Yoda creating a monoculture when he didn’t coddle Luke on Dagobah? Did Miranda Priestly not mold Andy into someone who could take on the worlds of fashion and journalism with confidence and style? Great leaders know that superstar employees must be hardened by trials.
When I am thinking of bringing someone new into my well-oiled strike team of ninjas and rockstars I have to know that they can hang. If someone doesn’t know off the top of their head how to implement their own inline versions of push and pop on an array to eke out perf gains, how will they ever optimize the code that serves the all-important banner ads to our users so we can make an extra .001 CPM?
What is this constant need to make things easier for people? I didn’t get where I am because I had it easy. I had to whiteboard code, and that gave me the strength to become an engineering manager at a media company. If I hadn’t had to persevere through implementing a linked list in the language of my choice at that interview, I shudder to think where I’d be now. Probably some job that’s a complete strain on society, like Project Manager. And not for nothing, but antibiotics have made the bacteria stronger and now they’re poised to dominate their market. It’s called natural selection—ever heard of it?
You’re living in some naive dream world if you think whiteboard coding doesn’t mirror the demands of the job. Are you not walking around randomly popping into cubicles and demanding that your employees stand and reduce an algorithm from O(log n) to O(n) off the dome? I am. It’s called leadership. Every morning during stand up I make the whole team do 100 push-ups, and on every third one they shout out “Fizz!” because I care about mentoring people.
Since when is a monoculture bad? You know who gets things done? Bees. Ants. Boy bands. Not a single individual thinker among them and they build empires. If you’re not cultivating a hive mind on your team, you’re letting the shareholders down, and I’m pretty sure the SEC can prosecute you for that.
The bottom line is hazing works. It separates the wheat from the chaff and in this metaphor, if you’re gluten-intolerant, that’s too bad, too.
65 Comments
Comparing being asked to sort an array or solve FizzBuzz to having to write a Supreme Court opinion by hand from memory is not an apt comparison in any sense whatsoever. White board questions allow interviewers to understand how someone goes through the problem solving process, it is obviously not meant as a recreation of what it will be like on the job day to day. That being said, my team works out issues, does flow charts, and writes psuedocode on our whiteboards pretty regularly. Maybe that is uncommon in your work, but I don’t think it is unreasonable at all to expect someone to be able to communicate their thought process to others as they are encountered with a problem, especially given that most whiteboard interviews are intentionally simplistic.
“White board questions allow interviewers to understand how someone goes through the problem solving process”
I’d argue that it allows interviewers to understand how someone goes through a whiteboarding interview, specifically. Personally, nothing about an interview whiteboarding session would represent my day-to-day problem solving process.
The idea is that they want to understand your problem solving ability without needing to watch you work for a week in order to understand your day-to-day process. Interviews must necessarily make do with approximations. The question is whether the approximation is good enough to be an effective indicator.
Understood, however why not sit them down at a laptop, give them a problem, and come back in 20 minutes to review their code and ask questions?
I’m not disagreeing with the idea of vetting a candidates problem-solving ability, merely disagreeing that watching them reason out loud on a whiteboard is the best we can do.
A number of years ago I read a blog post much like this one that included an example of a real “whiteboard programming puzzle” and broke down why it was bad. The task was to write a function that determines if a singly linked list contains a loop (that is, if the “last” element in the chain is pointing at any earlier element.
Upon completion the goal posts are moved, “Now do it with O(1) memory.”
This challenge (writing a zero-additional-memory loop-finder) was a problem that took PhD computer scientists *TWENTY YEARS* to solve the first time. The solution?
Two pointers. Each iteration one moves forward 1 item and the other moves forward 2. If the pointers are ever pointing to the same element, there’s a loop.
Either someone already knows the solution and they can demonstrate it in 5 minutes, or they don’t and you watch them flail around for 5 minutes.
What does either result say about the candidate’s ability to write code?
Nothing. Absolutely nothing.
That’s a great example of a poor question.
IME the best whiteboard questions are the extremely difficult ones with lots of solutions and possible extensions. There’s a lot of overlap there though with architecture type interviews.
Regular whiteboards aren’t good for anything but maybe new grad hiring.
One of the best I’ve run across was “you’re writing a bot that scrapes web pages…”
I don’t remember exact details, but one of the first issues was making sure the bot doesn’t visit pages its already visited (“store the URLs in a dictionary or database”). I vaguely remember touching on things like checking robots.txt because we’re building a Nice Robot.
Yeah, Joel talks about these as “Aha!” questions, which are very poor questions: https://www.joelonsoftware.com/2006/10/25/the-guerrilla-guide-to-interviewing-version-30/
I have 8 years of programming experience and solved complex problems and delivered many features, products out to productions and been used by millions of users. Yet failed to solve problem of DFS which I’ve never used in my entire life. The company asked to do DFS – missed a candidate like me. The problems been asked is good for collage students where they learned very same text book problems, but how come that decide experienced engineer’s technical skill? Ask experienced engineer to design the story you’re workin on today, challenge him to put the package you have into cloud, ask engineer to design a way to fix your today’s biggest challenge, you will feel the difference, also if the candidate failed to solve these kind of question would encourage him to put more effort learning stuff, but failing DFS made me to memorize algorithms.
“collage students”
Seems an harsh but realistic appreciation of what student learn in college.
/jk
It’s an honest appreciation in a good note from personal experience 🙂 I remember learning DFS algorithms when I was in collage. Atleast 2 to 3 problems in DFS.
They were making a joke about the difference between the words “collage” and “college” 🙂
What’s the point of this format when one side is given such a dishonest treatment?
One side is meant to be treated satirically and absolutely not fairly, like the Onion’s Point/Counterpoint series: https://www.theonion.com/c/pointcounterpoint
The Onion treats both sides satirically, and they often form a paraprosdokian or related type of joke. If this article is satirizing anything, it’s the plague of false equivalence in journalism. But it reads more like SO using their platform to childishly mock viewpoints they disagree with. And I say that as someone who agrees that whiteboard interviews are pointless at best.
Cool.
When are you running a write up on “We don’t *do* whiteboard interviews, I can only let you work at my startup if you spend 10 hours on some project for free” vs. “I have 15 years of professional experience and a life, if you can’t evaluate me in a reasonable amount of time I’m going to go interview somewhere else?”
Also, would be good to see:
“My resume just has ‘knows how to use Google and StackOverflow’ because I’m a modern programmer who looks stuff up” vs. “I’m a senior individual contributor engineer, being able to explain the jist of an idea to people off the top of my head in front of a whiteboard is really important to my job.”
(Obviously, these would also lack balance. But I don’t get why you would present one side as reasonable and the other side as farce. You don’t really propose an alternative, and as much as I dislike whiteboard question interviews most alternatives come with their own sets of problems.)
“If you can’t evaluate me in a reasonable amount of time I’m going to go interview somewhere else” Indeed. This is why things like “the Joel test” where candidates are expected to write code and take homework with them from the interview isn’t some miracle cure. You can do that when hiring fresh students, sure.
And then you’re gonna want some sort of practical test to weed out the quacks, be it on a whiteboard or elsewhere. Not to see if they understand advanced algorithm theory, but rather if they are capable of doing utterly fundamental stuff in the programming language they claim to know.
But veterans and specialist won’t spend hours of their free time to convince you. Because interviews are like dating – both parties has to be convinced it’s a good match. Established devs, particularly those who already have a job, aren’t gonna sign up for some “3 week paid freelance project”. They’ll look at full-time employment or nothing.
Bottom line is – interviews are no hard science.
O(log n) is better than O(n) — you got it the other way around.
Uh… `l`, `o`, `g`? That’s, like, three extra letters. And I’m not even counting the whitespace! Come on, get your head on straight: O(n) is clearly better.
Google, Microsoft, Facebook, Netflix will not hire candidates that don’t know basic algorithmic skills. i.e. using triple for loops for something that can be done in one. These companies work with data files in the 1000 terabytes. They work on problems on massive scale and need developers to figure out problems where solutions don’t exist. That’s what whiteboard interviews are for, evaluating problem solving ability, knowing basic algorithms and data structures.
The average software developers is trained to use framework implementations given to them, they don’t know how to solve problems when solutions do not exist. They typically work on smaller scale and inefficiency does not matter to them, since given solutions out there work reasonably well. If your this type of developer, algorithms & data structures are not relevant for your job.
I’m sure that was by design 🙂
There are, of course, a lot of points between “Too Hard” and “Too Trivial” (“The problem at hand will either be too trivial to be useful or too hard, basic, or esoteric to be representative. “).
Given the fact that anyone can call his or herself a software developer, while whiteboard interviews are far from perfect they are one of the few ways I know of to see if someone actually knows how to code or not. I don’t need to ask him or her to code a sort algorithm from scratch. Sadly it’s often enough to ask them to show me how they’d declare an integer variable. Literally something that simple will flush out 90% of the posers.
How do you know which is which?
Lets say you have a problem that takes 30 minutes to solve from first principles (but can be demonstrated to be solved in 1 minute once its written down). A candidate walks up to the board and writes down a solution in 1 minute and then explains the solution in 1 minute.
What does that say about the candidate’s problem solving skills?
Nothing. They’ve seen that problem before (probably last week at their last interview, where they took 30 minutes solving it from first principles, but wasn’t hired because the hiring developer thought it was easy! After all, he could do it in 2…).
How do you know which is which?
You give them a problem that is not based on special insights, but just shows basic coding skills. Something like can you parse an incoming text file and process the resultant records (assuming valid input to simplify the problem). The 5th time writing that solution shouldn’t be that much faster than the 1st.
After getting the basic solution down, you talk to the candidate about how he would validate the input and handle exceptions. This should show you if he can reason through the use case at hand, communicate with others, and work towards a good solution.
I could not believe that post was reviewed, published and featured on Stackoverflow, which will give it visibility to millions of people.
I went to check it again after sending it to a colleague and saw the note at the top.
I’m afraid many others might miss it!
I believe “…reduce an algorithm from O(log n) to O(n) off the dome?” may have been meant to say something like “…from O(n log n) to O(n)…”
I believe that was sarcasm
Do you have any realistic alternatives?
> Have them do some one-on-one pairing with people they’d be working with.
This is work, you have to pay them for their work output. Not realistic.
> Give them a small open-ended take-home project that shows you how they really approach application development.
How do you know they didn’t outsource the work to a colleague or service?
> Even better, pay them a fair price to do a small freelance project and see if they’re a fit in an actual real-world scenario. It’s a small investment in actually finding the right people for your team.
Imagine if everyone did this. Each job application would take weeks. No one would submit to the kinds of prolonged stress that would come from a practice like this.
Whiteboard interviews are definitely problematic, but I’ll continue doing them until something realistic and better comes along.
If your real concern about a take-home is outsourcing, then why not give them a simple assignment on their interview day, sit them at a laptop, and come back in a half hour (or hour) to review and discuss?
Unsupervised interviewing tends to get candidates stuck in my experience. It’s much easier if someone is there to answer questions, to lead them in the right direction and to make sure they understand the work that’s expected of them.
With “fire and forget” assignment-style interviews, a lot of the time candidates focus on the wrong things, or solve the wrong problem. Much better to be there to help them not waste time.
That said, some candidates don’t need as much help, and sitting them at a laptop for 30 minutes is equivalent to sitting them at a whiteboard for 30 minutes. I’m happy with either and consider them roughly equivalent. In my experience candidates are about as productive using either tool.
“Pay a programmer to do work for a week. This costs (say) $2000. Decide if you want to keep paying them based on how well they got along with the team and the quality of work completed.”
vs.
“Spend a week conducting interviews where you bring in 8 candidates a day, paying the hiring manager, two interviewers, and the team lead (during which they produce no work). This costs $8000 and gets you a candidate that you know virtually nothing about because whiteboard programming doesn’t work.”
(Completely bullshit numbers, but a cursory google search shows that the interview process costs about $4000, https://hiring.workopolis.com/article/how-to-calculate-cost-to-hire-and-why-its-important/ and not that far off from what I estimated)
Some of the major flaws with this approach are accessibility and inclusivity. Not everyone is able to take a week out of their current job to do an interview. Again, imagine if this were normal: to apply to several positions, you would either need to take weeks off of your current job, or work what amounts to overtime for several weeks to get through the interview process. Very few people are privileged enough to be able to do this. It is not a realistic option. While it may be more expensive to the company doing the interviews, it’s offset by how a few hours is much easier for most people to deal with.
Of course, not everyone can take a few hours out of their workday for interviews, either. After-hours phone interviews work well here.
If we’re targeting inclusivity, accessibility, legality, cost and good-enough accuracy, the whiteboard (or laptop) interview has stood the test of time. It’s not perfect, but it’s the best balance of competing priorities that I’ve heard of.
Whereas requiring working professionals to grind Leetcode et similia for months to be on par with the competition made of new grads fresh from college with plenty of free time is both accessible and inclusive.
It’s not the few hours of the interview time the cost for the developer. The cost lies in the fact that the coding interview is so out of the ordinary job that seasoned engineers need time to grind out questions on specialized sites. This is the real waste of candidate’s time.
Preparing for the whiteboard coding interview is ironically the perfect definition of “overtime for several weeks to get through the interview process” that the process wants to avoid.
In a recent interview I was asked to do a homework during the weekend. The job was quite advanced and gave me the chance to show off what I am able to do. It took just 24 hours of my time, which as a candidate I am more willing to spend since I want the job.
Next I was asked to defend my code during the interview and it felt like a conversation with peers and collegues as opposed to an examination.
I would take this any day compared to weeks of pointless Leetcode grinding.
It was the first time I felt valued for what I know during a technical interview.
The first idea work only if the first doing work for a week is a right fit. So the number of 2000$+on-boarding time is practically unbounded. And you also have to vet those candidates a little, which go back to the start…
He doesn’t, but whiteboards are evil and terrifying and amount to aggressive hazing rituals.
Apparently using a whiteboard to see if someone can communicate their thinking as they solve a coding problem (a small part of an overall good interview process) is a ridiculous proposition.
Heck, let’s take it a step further, why not ditch interview tests and hire them on a
one year contract and then decide if they can really code? Oh yeah, that’s right, because the point of an interview is to rule out poorly suited candidates early on and a whiteboard is just a tool. The results depend on how you use it.
Imagine that, lol. I would interview all the time for the extra cash.
I don’t like conducting interviews in rooms where there is no whiteboard (I also detest doing “remote interviews”, unless it’s a simple phone screen). I don’t put a candidate in front of the whiteboard and say “ok, write me a sort algorithm”. Instead, we both pick up some markers and go to town. Typically, I put a couple of labeled boxes on opposite corners of the board, and the interview consists of interactively filling in the space in-between. What goes in between are more boxes, code snippets, pseudo-code or whatever. What’s important it seeing how the candidate thinks, whether he knows what he says he knows and how he/she reacts to comments and criticism (I’ve had candidates tell me I’m wrong (on something I know I’m right) – hint: not a great thing to do in an interview).
Though this was funny, the fundamental premise of the argument is flawed in several ways. Here’s just one: sure, maybe *you* haven’t implemented algorithms on whiteboards in front of coworkers in 20 years, and maybe that is the case with most developers, and that’s a reasonable point. But look at it from my perspective.
I just now left a meeting in which someone explained a complex algorithm on a whiteboard to me, and I have had such meetings several times a week for the last 20 years; in a significant number of them, I was doing the explaining. My team designs programming languages to improve productivity of data scientists; we are *constantly* describing algorithms for solving problems in language analysis, statistics and machine learning to each other.
The fundamental flaw in your argument is that you presume that the interview is designed to test for signal that the developer can develop code, but the skill that I am looking for signal on is *ability to explain your code to others*. Only the most junior developers in an organization succeed by producing bug-free code. Senior developers must be able to *explain the decisions made to others* so that everyone learns what the product really does.
> My team designs programming languages to improve productivity of data scientists; we are *constantly* describing algorithms for solving problems in language analysis, statistics and machine learning to each other.
If you’re hiring for a job like that, go for it. But 95% of developer jobs do not require you to write, whiteboard, or describe any algorithm. We look them up. Or use some library that someone wrote already.
> the skill that I am looking for signal on is *ability to explain your code to others*
And that is a VERY good skill to look for. But guess what, most interviewers do NOT look for that. Instead their engineering manager writes up a rubric with checkboxes that reads “Candidate found the most optimal solution”, “Candidate was able to complete the exercise within the time limit”, “Candidate wrote a bug free solution”.
The idea that white-boarding a brand new problem without any prep in front of a judging audience is the best way to detect communication skill of both technical and social in nature, is false. You can do better than that.
> If you’re hiring for a job like that, go for it. But 95% of developer jobs do not require you to write, whiteboard, or describe any algorithm.
Every job I’ve ever had has required that.
> The idea that white-boarding a brand new problem without any prep
This is actually quite close to what real world development is like. You are pulled into a conference room and told ‘we need feature X’, and you need to be able to flesh out what that involves; you need to ask the right questions to properly scope the feature, set expectations as to what implementing that feature requires, and come to a meeting of the minds as to what the development staff can deliver and ensure that it meets the needs of the business user.
If, as anything other than a junior dev, you can’t do that, you are going to end up with failed projects because of a disconnect between requirements and deliverables.
> You can do better than that.
And can you do better than that? I don’t see you proposing a better solution.
> But 95% of developer jobs do not require you to […] describe any algorithm
In any developer job you might have to explain what’s the code is doing, ie explaining an algorithm. And being able to do it is important, for example when you have to explain to a stakeholder why a particular issue appear in a particular set of circumstances.
Katie is right! Explaining a solution is different from devising a solution. If you really are judging someone’s ability to explain a solution, then give them an algorithm and ask them to explain what it does?
The point here is that whiteboard interviews are hostile and stress the candidate, causing them to perform poorly. Cops, for instance, know that they can’t pull someone over without a reason. Many resort to a common and very effective technique, follow the driver around. Many drivers will become nervous and do something stupid, giving the cop a reason to pull them over. It is highly effective and almost guaranteed to work.
I have to agree with you here. I happen to have not erased my whiteboard for about a week. I have on it:
– Two proposed directory structures for two different projects.
– An architecture block diagram.
– A data structure.
– A proposed jinja template for scale test messages.
– Code for a basic event loop for scheduling those messages asynchronously.
All my colleagues have similarly filled whiteboards. While certainly “gotcha” problems are inappropriate for interviews, I find the idea strange that having technical discussions at a whiteboard is only an interview technique.
That said, there are obviously genuine problems with the way interviews are conducted at software companies, but I lay the blame for that on shallow, disorganized, derivative, unreflective, and frankly cargo-cultish approach that many interviewers take.
The interviewer has less than an hour to gather data to make a decision with consequences that could mean millions of dollars of gained or lost revenue, in a potentially adversarial situation — not all interview candidates actually want the job! This is a hard task, for which many developers are undertrained and end up woefully unprepared for.
The problem isn’t that interviewers ask candidates to do ridiculous reverse-a-linked-list tasks under time pressure on whiteboards. The problem is that many interviewers do not have a precise list of characteristics they need to get signal on, they do not have calibrated questions where every part of the question has been carefully designed to elicit a clear signal, and they don’t have training on how to interpret the signals they’re getting, or what to do when things go pear shaped. The problem is that most interviewers are bad at interviewing.
Large companies have budgets to invest the time and effort it takes to train up interviewers, review their questions, observe their technique, and help them calibrate their response to signals. Smaller companies without budgets find it too easy to say “Microsoft in the 1980s asked candidates why manhole covers are round so let’s do that without understanding why.”
I totally agree – IMHO the problem is that most interviewer don’t actually have the tools to get the input they need to determine the qualities they want to know about the candidates – mostly because they don’t have a well defined list of characteristics they need to get signal on.
There’s no one-size-fits-all in job interviews – each job requires it’s own set of skills, and therefor each job interview needs to be tailor-made for the specific job that needs to be occupied. Small and even medium size companies don’t have the resources needed to tailor interviews like that.
Indeed, being skilled to code does not automatically grant a skill to estimate the ability of other’s to code; however it seems from a general assumption from the management’s POV that it is often just the case.
Yeah, look at the wonderful quality of code Microsoft produced using whiteboarding interviews. Most of their top programmers, Culter, Anders, Ozzie and others were either poached or gained from corporate acquisitions. I bet none of them were subjected to whiteboarding. If they were, the results didn’t matter;
Let’s assume you could magically select the best and the brightest developers. Does it guarantee they will perform well? What about other factors such as social maturity, work ethic, enthusiasm, organization skills and mental health? I would say all of these traits are as important or more important than being a rockstar programmer, but thankfully we have laws preventing candidates from having these qualities measured.
Frankly, if you can’t judge a candidate’s fitness for a job using a regular interview and a resume, then you suck! Whiteboard interviews have become popular because there’s a glut of developers thanks to H1B Visa Program.
>> `I just now left a meeting in which someone explained a complex algorithm on a whiteboard to me.`
Your colleague probably has thought about the algorithm and worked on designing it for a while before pitching it to you and that is totally different from asking someone you just met to solve a problem with code on the whiteboard 🙂
There is nothing wrong with white boarding in general. But what do companies actually test you when they whiteboard? They test the precision of code. That is, “Did this candidate find the most optimal way to solve this particular problem?”
This is not what you want out of an engineer. At least not the most important thing that you should fail people on. Because let’s be honest, do all of your in-house engineers never write any inefficient code? Of course not. Your engineers will 100% write non-performant code even when they are sitting at home, on the couch, with no spectators. I’ll take “What is a Pull Request?” for 500.
There are definitely better things you can do with a candidate. One, either you and candidate both pick a random leetcode problem you’ve never worked on and solve it together. Or two, you both find some problem to debug with an actual code base.
Why do you do this? Well, can this candidate communicate his thought process? Will this candidate be frustrated when I am stuck and need him to explain it again? Can this candidate actually do something that he’s never seen before? Fact is, nobody likes to be in a spot where they’re working on code where they do not know the answer to. Interviewers will never work on a problem where they did not already look up the answers to. Because it is hard. Because it sucks. And because nobody likes doing it.
So why are you making others do it? Every company that does this white boarding algorithm style grilling fails on a very basic human principle. One that spans across continents, cultures, and time. And that is the golden rule of “Treating others as you want to be treated”.
Though I take your point, “did the candidate find the optimal solution” is literally the least thing that I am looking for when I do a whiteboard problem. I mean, sure, if they cannot, no hire, but the problem should be sufficiently straightforward that an optimal solution can be discovered and coded correctly in a few minutes. It’s what I look for *around* the optimal solution that is interesting. Did the candidate explain the code clearly? Did they consider the sample input that I provided as the first test case? Can they tell me the asymptotic order? Can they identify the root cause of poor asymptotic performance? If a part of the problem is underspecified, can they clarify it? If I add a restriction to the problem, can they adapt the optimal solution to the restriction without de-optimizing the code? Can they make trade-offs between different performance aspects, like size and speed? Can they take the point of view of the end user in the performance discussion? What tools do they have in their toolbox?
I also note that choosing a *random problem you’ve never seen before* is adding variability and uncertainty to a process that already suffers from poor calibration. Interviewing is notoriously difficult to make fair and unbiased; adding a source of randomness so that no two candidates get the same interview works against my goal of eliciting clear signals with good calibration.
>We have problem in the currently programming industry where a lot of applicants lack basic computer skills and can’t even program simple functions
Man, if only we could ask applicants to write down a solution to an relatively easy programming task to demonstrate their skill. But we also wanna see how they do, so a computer screen is probably too small. A big piece of white paper? But if they make a mistake it would be hard to fix. I wonder if anything exists that lets people write stuff that will be easy for multiple people to see that can be easily erased…
The first article has to be satire.
“Whiteboard coding doesn’t help you observe how a candidate thinks or approaches a development task”
White boarding does exactly that. There is literally no other way to know how someone thinks and codes then by watching them pseudo-code. In the Bill and Melinda Gates Hall for Computing and Information Science, ALL the walls inside are glass whiteboards. It isn’t because programmers aren’t white boarding.
“I have never, in over 20 years as a professional developer, had a single project that required me to stand at a whiteboard and implement an algorithm in front of someone in order to do my job.”
A thought like this would be why one would remain a developer for 20 years and never advanced into management. Managing software development is a whole different skill set, which, in addition to being a software expert, involves management concepts, which must be learned from reading management books and experience with a management coach over the years, in the school of hard-knocks.
Interviewing is a management concept, not a software concept. So this is an article about Software Management, not Software Interviewing.
“A candidate in a whiteboard exercise is in fight-or-flight mode, and the problem you are watching them solve is the problem of how to survive this insidious exercise and get the job”
Do I want my surgeon to be in fight-or-flight mode when he opens me up? Or do I want a surgeon who has passed through the fire? If one knows his stuff, he’ll welcome a pseudo-code whiteboard session. Champions loves challenge.
Everybody knows people pad their thirteen page resumes with every buzzword under the sun, because the HR girls don’t know an array from a huzzah!, so managers need to whiteboard in an interview. Now… if the managers can’t do the whiteboard problems… sell your stock fast.
“The bottom line is hazing works.”
A manager who understands proper management concepts will conduct his interview to assess the candidate’s knowledge and capability in a comfortable setting, by starting easy, then getting more difficult, then assisting, backing off, and saving face, all when necessary. So it doesn’t have to be hazing. Again… all management concepts, not software concepts. Brian Tracy has great management books.
If someone makes you feel uncomfortable in an interview, then remember you are assessing the company as much as they are assessing you!
From Thinking Recursively, by Roberts, if I remember correctly.
You have sixteen coins. Fifteen weigh the same, one is heavier.
Using an apothecary scale, find the heavier coin in four weighings.
Now, find the heavier coin in only three weighings.
This is an example of a problem that programmers love, but do not demonstrate whether a candidate will be effective as a professional developer.
I couldn’t agree more with the first part of your post.
The second one is obviously the fake, though I did have the unpleasure of working for like-minded “bosses” before.
However, IMHO, the problem with interview coding challenges does not end at the ridicules white-board challenge – it takes on other forms such as paper-and-pen debugging, well-known algorithm implementations (yes, I did miss the “Buzz!” at every fifth push-up) and other stuff that don’t provide any real insight on the candidate actual capabilities and more importantly, on the candidate’s chances of fitting into the existing development team.
I’ve blogged about this myself on What the # do I know? – summing up what I think is wrong with coding challenges today and why I think they should look like.
https://zoharpeled.wordpress.com/2019/09/26/what-if-your-interview-coding-challenge-would-look-like-this/
Either don’t be so obvious about which side you think is dumb or remove the comment at the beginning. Either change would make this a fun concept, but as it is currently, it is kind of boring and borderline insulting
I’ll just leave this here:
https://miro.medium.com/max/1024/1*7n5exSqr7qmHJjvZSTI9zQ.jpeg
– Anonymous
> Even better, pay them a fair price to do a small freelance project and see if they’re a fit in an actual real-world scenario.
Even if you were to cut this down to something that could be done in a weekend, so currently employed candidates wouldn’t have to take time off to do it, (essentially an oversized takehome test) you’d still run into problems in that many employers require their staff to report any side jobs (eg to avoid potential conflict of interest problems). So you’d still be doing something that would effectively limit your employee search to only people who’re out of work; drastically shrinking the pool of potential candidates.
He who pays the piper calls the tune.
Joel Spolsky (former CEO, Stack Overflow) has recommended whiteboard interviews: https://www.joelonsoftware.com/2006/10/25/the-guerrilla-guide-to-interviewing-version-30/
This article makes no attempt to “play both sides of the issue.” The second half is just dumb.
If you *actually* attempt to play both sides of an issue, you’ll wind up with a much more interesting perspective on it than if you just argue the side you agree with, and caricature or “ape” the side you disagree with.
I’m a full stack guy. I started coding on a Commodore 64. But, I never learned Big O until I was given the interview prep packet from Google just this year – because they thought they wanted moi, and that was exhilarating, and disappointing all at the same time.
Monsanto’s process had a pair programming experience, and that was great and fun. Unfortunately, they should have shot me with Nerf darts and had a bunch of Project Managers and Agile coaches talking about non-work in volumes that exude they’re just there to collect a paycheck and don’t give a hoot if you can focus on your work the “open-floor” plan.
While I found coding (and other inventing) fun when I was young, I didn’t really learn until I was living in a tent for two years behind my college in California. Both doing coding assignments, and grading mid-terms by candlelight, using pencil and paper, gave me a neat ability to “napkin” an idea.
So, whiteboards are good for me, but I can see how it would intimidate somebody and you might miss out on some really skilled people. Like, people who know Big O w/o prepping for Google (which, conversely, intimidated this guy to pass).
Have you guys changed your interview process? In 2015 I interviewed with you, and you had me answer a question like “Given a string such as ‘AAAABBCAAA”, produce run-length-encoded string ‘4A2B1C3A’.” (I passed the technical interviews, but ultimately didn’t get an offer.)
I liked the question enough that I later tried using it when I was an interviewer, but ultimately had to stop because too few people could actually do it. One of the ones I do use a lot is basically “Given an array of single-character strings, return a copy of the array with no duplicates. For example, removeDuplicates([‘A’, ‘B’, ‘A’, ‘C’]) returns [‘A’, ‘B’, ‘C’].” Even that people have a hard time with.
I try my best to let people know that I don’t care if their syntax is correct or if they got the names of library functions wrong, and I don’t care what language they use or if they want to use pseudocode. I don’t even care if their solution to the removeDuplicates problem is the obvious O(n^2) solution; I never ask them about the complexity because that never really matters unless you’re coding a video game engine. But I do expect them to understand the concept of a for-loop. I don’t think that’s too much to expect from someone before handing them a six-figure salary.
What about those who interview verbally, I visited to small companies for internship. Though I had developed two ugly web apps, those were not cared about. Rather I was questioned verbally like Do you know how to use/store files uploaded to php server? What do you know about API? How you can reverse string? What is alternative to Some Object Method in JavaScript in php? I just got angry and wanted to leave as soon as possible either with/without job.
Programming/Code is not a skill of Memorising, it is skill to solve a problem, only when it occures in real life.
Just ask them to send you some of their code. Good devs should have a github account with some stuff up there, or some personal projects they’ve worked on. I wouldn’t want to hire a developer who literally would have nothing at all to send me if I asked for a sample project; he’s obviously just in it for the cash and is unlikely to be one of the good ones.
Anything beyond that is annoying. I have a github with two hand-coded interpreters, a compiler and a video game engine on it. You don’t need me to write you an array sorting algorithm or do your stupid, weird, esoteric take-home homework. I can ace whiteboard interviews all day but that means nothing except that I know NLP and psychology. The only way to hire a good engineer is to get a significant example of their code and have your smart people review it.
It also happens to be the least intrusive to the candidate.