101–110 of 370 posts
Is there any engineer who you'd regret not hiring, who is unable to code FizzBuzz in real time in front of an audience? I'm skeptical.
I've seen a respected engineer that I worked with for years, be told by an outsider that he was incompetent because he couldn't fizzbuzz an interview. Yet, they had no problem acquiring the project he designed and wrote. So yeah.
Earlier quoted context omitted.
I think it's important to measure what's actually relevant to the job. If the job entails large periods of coding on the whiteboard, then yes, it's a perfect metric. If, however, the job requires careful consideration of dependencies, time domain, and, yes, edge cases - then you are NOT testing for that. Lock the candidate in a room and give a few hours to let her to produce the result would be a better measurement.
When I do whiteboard interviews I want a little bit of code because I'm stunned by the number of people who can't write a loop. But mostly I want to see the design process. I ask for a simplified version of a real feature that has an algorithmic core. This lets us code something but lets us discuss all sorts of edge cases and real world complexities that would come up in a true deployment. Lots of interviewers suck.…
I won't say this is you, but it's funny the number of people who will interview and say something like this and then still give a non-trivial problem/question to whiteboard.
Reminds me of a guy who interviewed me several months ago at a place in Mountain View (not Google, but another).
He started by asking me to create an object with a couple attributes. Then he slowly began to add to the problem by asking for X, then Y, then Z.
Little by little, the code became more complex because he wanted iteration, etc.
He would say "I just want to know that you're able to code."
Later on, I found out he didn't like what I wrote, meanwhile all the basic elements of coding he wanted I was able to add without any problems and I met his specs.
If there's a "communication issue" in whiteboarding, perhaps the interviewees shouldn't shoulder all of the blame. Perhaps the interviewers need to temper their expectations and learn to communicate them better, because obviously there is some disconnect in a situation like this, and it's not the first time I've seen this before.
Whiteboard coding does a good job at assessing that, regardless of the candidates ability to actually solve the problem (for all the reasons why whiteboard coding sucks).
Do you analyze the problem?
Write test cases first?
Write a mini spec?
Gather Requirements?
Ask Questions?
Jump into code?
Google?
Verbalize the problems you encounter?
In that respect, engineering coding interviews work well. But too often, they are essentially a binary Yes/No: Candidate solved the problem the way I want them to solve it.
VP of Engineering at Eaze, previously CTO at Getable and engineer at Yammer. No, not at all. Whiteboard interviews test one thing well: How well does a candidate code on a whiteboard. Engineers on my team never have to code on a whiteboard (whiteboards are really bad at running code), why would I make candidates do something that I don't ask the engineers already on my team to do? This comes close, but I think the re…
> Whiteboard interviews test one thing well: How well does a candidate code on a whiteboard. What if you consider part of someone's job to be communicating concepts to people, possibly with the help of visual aids and diagrams? I hate this concept that if it's not typing code into an editor then it's not "real work". I absolutely communicate with my coworkers using a whiteboard and pseudocode. I reject the idea that…
Clear and respectful communication is one of the most important skills for an engineer to have.
If you read the second half of my answer in the article I go into the communication side of things. In my experience there are better ways to evaluate a candidate's emotional intelligence and social skills than asking them to code in front of someone.
1. Have a senior engineer chat with the candidate for an hour about a few bugs/features in the repository, and how the candidate would solve them.
2. If the candidate is promising, give the candidate a week or so to fix the bugs or implement the features.
I think this would be a more relevant test than just giving them context-less problems to solve on a whiteboard.
VP of Engineering at Eaze, previously CTO at Getable and engineer at Yammer. No, not at all. Whiteboard interviews test one thing well: How well does a candidate code on a whiteboard. Engineers on my team never have to code on a whiteboard (whiteboards are really bad at running code), why would I make candidates do something that I don't ask the engineers already on my team to do? This comes close, but I think the re…
VPE at Eaze here (the original author of the quote above) - You're 100% correct. We give our candidates the choice between working through a problem at the office (on the spot as you say) or doing a take home project asynchronously. Not everyone has the time to do homework, but not everyone wants to do an in person coding interview either. We try to stay flexible.
Earlier quoted context omitted.
There's some logic to that. It's the one of the same reasons we have high stakes exams in school: to show what the individual can do under pressure. In an interview setting you can't simulate what it's like to be at the end of a high-intensity sprint, but you can ask the candidate to answer a tough question on a whiteboard and (ideally) get a notion of how they work when the going gets tough.
As a former air traffic controller and now data scientist, nothing in this career field is ever done under any real pressure.
Earlier quoted context omitted.
> Whiteboard interviews test one thing well: How well does a candidate code on a whiteboard. What if you consider part of someone's job to be communicating concepts to people, possibly with the help of visual aids and diagrams? I hate this concept that if it's not typing code into an editor then it's not "real work". I absolutely communicate with my coworkers using a whiteboard and pseudocode. I reject the idea that…
even then, this is not what's being tested with the whiteboard. thinking and presenting are two separate skills, and, in my opinion, can rarely be executed at the same time.
Earlier quoted context omitted.
> Whiteboard interviews test one thing well: How well does a candidate code on a whiteboard. What if you consider part of someone's job to be communicating concepts to people, possibly with the help of visual aids and diagrams? I hate this concept that if it's not typing code into an editor then it's not "real work". I absolutely communicate with my coworkers using a whiteboard and pseudocode. I reject the idea that…
> What if you consider part of someone's job to be communicating concepts to people, possibly with the help of visual aids and diagrams? Perhaps it would be more effective to have the candidate whiteboard a concept that they are already familiar with, be it a high-level engineering principle or a system/solution they have built in the past. Attempting to solve a problem you have just been presented with AND communica…
If you can't give me good examples from your past, I'm going to throw my own questions at you. I tend not to do coding on the whiteboard, though. Lots more boxes and lines and schema and system interaction-y stuff.
Earlier quoted context omitted.
> Whiteboard interviews test one thing well: How well does a candidate code on a whiteboard. What if you consider part of someone's job to be communicating concepts to people, possibly with the help of visual aids and diagrams? I hate this concept that if it's not typing code into an editor then it's not "real work". I absolutely communicate with my coworkers using a whiteboard and pseudocode. I reject the idea that…
>I reject the idea that being put on the spot is necessarily "artificial". To the contrary, I think that the number of engineering jobs where you can assume you'll never be put on the spot or have to communicate complex ideas verbally or visually is relatively low. I think it's safe to say that being put on the spot in front of people you don't know who are judging you is quite different from being put on the spot in…
We've never rejected somebody for having a "bad" answer, because they were able to at least talk about what they're doing. We have had people flat out refuse to even try, and that seems like a pretty big red flag.