When interviewing for a software engineering job, it's common to be handed a dry erase marker and told to solve some arbitrary problem:
"Write a f...
For further actions, you may consider blocking this person and/or reporting abuse
I too use whiteboards - though in my case it's a "draw me a system you've worked on before" to assess their communication skills.
That's followed by "OK, now, talk to me about something that catastrophically failed in this system, how you fixed it, and what it taught you."
Nice one! It also shows how much a candidate understood about areas they didn't directly work on, which is telling a lot about how a person works and how they go about fixing stuff. There's a lot of candidates that think it's ok to ignore stuff outside of their strict area of competence. While it's possible to be proficient even with a very narrow focus, the mentality and willingness to look at the whole system (or at least outside the direct area one is assigned to) always leads to become a much more effective engineer.
When i get answers like "i don't know, this was X's job" i take It as an indicator of the experience of the person I'm talking to.
Also interesting to hear the follow up on the "something that catastrophically failed in this system, how you fixed it, and what it taught you."
"Whiteboard interviews don't actually test for coding ability - they test for anxiety."
Good point.
Yep. This is the sole reason I’ll never get a single job at any tech company that whiteboards me.
Whiteboarding feels more like Waterboarding. 🤣
"it's important to choose whiteboard questions that don't require specialized knowledge of a certain algorithm or formula." -really agreed on this one.
as a lot of hardcore folks will tell you that if you don't know this sorting algorithm or this whatever data structure, you lack fundamentals. heck I can't even remember sql foreign key creation syntax, but I'm building lots of full stack web apps and are already being maintained by different people and still run smoothly.
I mostly agree, but imo I like interviews that focus on actual challenges faced by the team better, plus they also help identify most of the red flags. However, I completely agree with whiteboard interviews for new grads.
Absolutely. The better the coding exercise models the actual work you'd be doing in the job, the better of a predictor the test is.
Google found that a "work sample test" (i.e. whiteboard questions, take-home assignments, any sort of coding for software engineering jobs) was the best predictor of job performance and was able to account for 29% of the candidate's actual job performance.
(source: Work Rules! by Laszlo Bock)
One good thing about whiteboard interviews is that at least they are time constrained.
I hate open ended take home assignment supposed to take four hours but obviously will take 16 or more because we are perfectionists and don't know how we will be judged.
Also I dislike online whiteboard interviews more than offline what, because there ask you to compile and run your code in their super crappy online IDE, which is a major distraction because pseudo code is all you need really
Absolutely! There are trade-offs with each medium you choose.
For take-home assignments, I think having really clear criteria for what the graders are looking for is important. And equally important is communicating that criteria to the candidate. I once completed a take-home assignment during an interview that was supposed to take four hours, and they clarified that they don't care how the end result looks and not to focus on styling it up to look nice, and that was incredibly helpful to me.
For the online editors, I've run into those same problems as well. As an interviewer I think you need to decide what you're trying to evaluate here: either the pseudocode and problem solving, or the actual code and whether it compiles. If the exercise is something like a test-driven development exercise, then the immediate feedback and the tests running in real time is actually really helpful! But if you're just trying to see how the candidate solves problems and if they can think critically, then I agree, the code shouldn't need to compile.
We would ask ourselves 'has it happened yet?' Referring to the virtual lobotomy all our newly promoted tech folks received when they jumped into management.
Inevitably after about 6 weeks they thought and acted differently. Only about 20% were still admired by us as they seemed to jump out of the trenches.
Funny how you didn't like these things until you switched positions.
We would always say. Gee if they hired us now, we wouldn't be here.
The real question, which I've never seen answered, is do whiteboard interview questions result in better employees? How would on do a-b testing? Throw out WB tests for group A and use them for group B, then follow up a year (is that enough time)?
There's plenty material out there explaining all those kinds of things. Unless you're just starting, there's no excuse for not knowing at least the basics of algorithms.
I think they are looking at our communication skill, we shouldn't be intimidated about giving the wrong answers.