Photo by Mark Rabe on Unsplash.
Software engineers hate whiteboard interviews. How do I know? We continually tell complete strangers just how m...
For further actions, you may consider blocking this person and/or reporting abuse
Some of these answers point to "new alternative live-coding environments" which solve a bit of the problem, but this still seems like a less-than-ideal way to evaluate someone's actual coding experience. It also optimizes for what they happen to know this exact moment.
I really feel like if you want them to come work with you for longer than a month or two, the gaps in their knowledge will close pretty quickly as long as they have a good approach and perhaps some relevant experience. I can't think of a lot of scenarios where I want to have my opinion be formed based on an abstract live-coding scenario.
I genuinely think coding challenges give no indication of actual programming skill. Programming is like 90% problem solving so I think intelligence, experience, and creativity are much more important. You can test for 2 of those!
Stefan, you really hit the motherload! I agree with you 100%.
But the problem is, how can you test intelligence or experience or creativity? Sure, there are some ways, but sadly not everyone is qualified to test such things. Developers surely cannot test them. Most of HR specialists are not psychologists/sociologists.
I love these talks, and I am gonna remember your answer. I really want us all work together, use our collective brainpower to solve the interview dilemma once and for all, so both interviewers and interviewees are OK with the terms of interviews.
I think we should look at how business consultant interviews are done. Some of their interview questions might sound stupid (how many ping-pong balls fit inside of an airplane?) but they do test problem-solving skills and general intelligence. What is a developer if not a problem solver, using a programming language as his tools?
I think part of the problem is that we are "testing" or "challenging" someone. This implies a level of distrust and hostility which only serves to heighten stress levels in what is already a very stressful situation.
You're 100% on-point. Regardless of medium (whiteboard, live-coding in a shared editor, timed coding challenges e.g., Hackerrank, etc.), these are still less-than-ideal ways of evaluating someone. Enough that there's a cottage industry of tech interview prep companies out there which I feel are exacerbating the problem.
Technical tests of all kinds are great for people just starting out in the industry but once you have a CV with 4 or 5 years with references you have already proved yourself. When I'm looking for a role now, if they ask me to do a technical test, unless it's a company I really like, I politely declined and explain my reasoning. 9 times out of 10 this is acceptable to the employers and they see my point.
Great collection of answers!, this goes directly to my bookmarks.
I'm a software engineer and I do not hate whiteboard interviews.
When I say "whiteboard" I mean any env that lets you draw and type freely, from a physical whiteboard to draw.io.
Like any tool, the whiteboard is the best fit for specific questions (about the candidate. how they think mostly), great way to express yourself, and it does not exclude the other types of interviews, I see them as complementary.
I think the statement "my devs do not code on whiteboard" is just wrong, if you know your language you should be able to code on toilet paper, the environment does not matter. And noone expects that the whiteboard code should be syntax error free, is about the main idea/algorithm.
I love whiteboards, we have them at work on every wall (kind of, glass walls), I have one at home, and it helps me solve any kind of problem, from data structures to life decisions. But depending on the company and role it may not be the best solution for the interview.
Not really. A lot of the roles I've come into, I've never done the particular language or technology that I'll be working with before. In this sense, whiteboard tests really do not apply.
«if you know your language you should be able to code on toilet paper» this one goes straight to the list of my favourite quotes 👍
I think that they are a good first step, but I don't think that they should be the final result. The are a good way to test if a person is programmer, but asking someone a difficult problem on a whiteboard is not a good way to evaluate them as a programmer.
I lean more and more to the idea that a portfolio is the best way to evaluate someone. You can see the way that they work. But more importantly you can see the quality of the code that they produce. That being said, portfolios have their own issues. You could be a phenomenal programmer, but if you don't code outside of work, you can't really show that. Also, it is a huge time commitment, and some people don't want to do that. Lastly you can just plagiarize code.
There is no perfect interview method, but I don't think that whiteboarding is that best method for final evaluation, but it may be good enough for initial evaluation.
A portfolio is often the rarest thing you will find with full time developers who are working on key industry projects. Often they don't have time to code outside of their job or the last thing they want to do after coding at work all day is do the same when they get home in order to make a portfolio. If I see a developer with a portfolio who is not a contractor I start to wonder; do they have an unhealthy obsession with development and no social life or are they so devoid of work in their role that they have the time to do a portfolio on the side.
I think that these are all good, valid points. :)
I just think that it is a good way to judge the development skills of junior devs. When I got my first job, it was definitely being able to talk about the side project that I had created and the processes that I used that landed me the job, not my ability to solve fizz buzz and do SQL queries.
Once you are a mid-level or senior dev, I think that people are able to evaluate your skills in a different ways.
I'm curious to hear how these hiring managers are dealing with the other problems in this list: "The problem is that we often conflate several issues: using random CS trivia/riddles to assess candidates, interviewers deliberately creating a stressful environment for interviewees, competent humans who happen to interview poorly, and the job search sucking in general."
Nice job Lynne!
Nay in most cases.
"competent humans who happen to interview poorly"
Exactly. In truth, whiteboard interviews select for interview skill, not for competency, or even for day-to-day soft skills. In an actual work scenario, you won't have a senior dev breathing down your back and asking you a battery of questions about what you're doing. They'll check out your PR and accept it or make comments as needed.
You'd be surprised. A lot of the time the real talent is actually snapped up by startups as they are the ones driving innovation. You'll find that those working in an enterprise environment typically tend to be behind the curve and stagnate.
I love whiteboards for discussion within teams, but they seem too much of a crutch for use during interviews. Ask trivia question about an algorithm or something, make code monkey write it on the board, move them to the next step if they can do it.
If it's used in the way whiteboarding is used in real life, as a discussion, that's better for the interviewer and the interviewee.
"How would you approach this system?" They draw it out a bit. "What's that part over there do?" They explain, keep drawing, say they don't know how to proceed. Interviewer asks a relevant question to see what their thought process is. Interviewee answers and they talk it out.
It's hard to interview properly, but that's also how you can find the best fit on both sides.
Whiteboard interviews look at a small sliver of skills you'll need for a software engineering job namely problem solving and mathematical thinking. Other equally important skills are communication with colleagues and non-technical team members, design & modeling, familiarity with domain knowledge (especially in niche companies) & perseverance (a good developer is aware of the inherent frustrations of dealing with multiple layers of abstraction). A better way to test candidates would be to ask them to add a small feature/resolve an issue on your existing code base and pair them with an experienced developer (with due compensation for time). But this is not a scalable process as it calls for equal investment from the companies' side as well.
This reminds me of the old joke, how you shut up an engineer? Take away the whiteboard.
It's one of those "it depends" kind of tools. What do you want to use it for? An in depth, code me a function now kind of thing? No, I find its not the best tool. Honestly, these days, I barely even see them around any more. In our open office we use them more as movable walls than really to draw and communicate on, except for those times in Sprint planning we need to talk things out. For interviews that's the only good use I get out of them, as a way to make the candidate speak to something.
As a communication and lead tool on a question or problem we face all the time in my environment, I draw something start asking questions and use it more to lead into how the person thinks and problem solves. There are better and more efficient tools to use if you really need to have someone program.
If a whiteboard is used as support for discussion, I'm fine with it, from something like "here is a piece of code, what's wrong with it?" to "that's our infrastructure, how would you improve on it?".
However, coding "live" on a whiteboard, paper, PC or else stresses me a lot.
I heavily rely on code completion (and copy/paste) and added to that, I have a really bad memory for names, be it for function, methods, methodology etc ...
So when it is time to write, I spend more time trying to remember the proper name of a function than to think about the logic of the code itself.
Pseudo-code or flowcharts would be fine as long as we don't focus on the minute details of the drawing.
I'd rather be given an assignment to complete before the interview for them to check I can create a solution based on the requirements.
At our specific agency, 90% of new hires are graduates fresh out of university, so we look for candidates to prove that they can program (at all).
We give a pen-and-paper programming test that candidates complete unsupervised, testing fundamental programming skills (no special data structures or compsci) as well as a database design and diagramming task.
This is very successful at weeding out the bottom 50% of candidates, who, despite just finishing their Computing degrees, cannot write or describe a working computer program. But we can conduct the test without openly embarrassing the candidate.
Personally, I think having a portfolio of code you have worked on on github is the way to go. Use that and explain what the problem was, how you approached solving it and justifying why you took that approach. That's what you'll be expected to do in any job anyway, so it makes sense in an interview as well.
Nay.
Is that the right answer?
🤔 I can't tell if you're kidding, but...
the point is that it's not binary, even though some people treat it that way. If you read what the hiring managers quoted in the article say about whiteboarding, you'll see that it's really nuanced.
I'm mostly kidding, but if I had to make a gun-to-the-head choice, it's be no. It's a reply because the question is binary.
Whiteboard interviews obviously is a term that has grown to not just include actual whiteboards and there's room in the world for a lot of different techniques - you can learn a lot from asking people how to solve something in a practical sense :)
My opinion, white boarding is a skillset. Like the ability to speak to a crowd. Some can do it, some cant. I would always argue for white boarding to bring clarity to an issue.
It usually flushes out a problem between differing opinions. But for an interview, just throw glass on the floor and ask me to dance. I need to know you better before I can play charades with any team.
-rhodey
The question is what problem does whiteboard coding solve for whom?
I understand the need for some companies to establish some kind of gateway mechanism in order to reduce the amount of hiring false candidates. And live coding is one way to reduce the number of false positives after hiring.
I never did live coding so far. And to be honest, I think I would perhaps fail epically. So chances are low, that such companies would hire me.
It says nothing about me as a developer - besides, that I am perhaps bad at live coding. But that as I said isn't the purpose of it.
Here is a list of companies that do not use whiteboard interviews:
github.com/poteto/hiring-without-w...