The problem with whiteboards, is they're not reflective of real life. When was the last time you can honestly say you used a whiteboard to solve a programming problem instead of Googling and ending at a StackOverflow question with a great answer? I've never used a whiteboard for programming. I've used plenty of whiteboards for things one level back; planning, prioritising and visualising task related things. The real…
Everything depends on the project (e.g. programming games is different than making web apps), but:
> When was the last time you can honestly say you used a whiteboard to solve a programming problem
Every time there is some interesting hard problem which I want to share with the team. We used whiteboards almost daily.
> Googling and ending at a StackOverflow question with a great answer
I google like 5% of stuff I do, because:
* a lot of time is spent on debugging and you just can't google why your program crashes on in file X on line Y
* a lot of stuff is too easy and there is no need for me to google it
* architecture - you usually can't google "how do I architect system X"
The problem with whiteboards, is they're not reflective of real life. When was the last time you can honestly say you used a whiteboard to solve a programming problem instead of Googling and ending at a StackOverflow question with a great answer? I've never used a whiteboard for programming. I've used plenty of whiteboards for things one level back; planning, prioritising and visualising task related things. The real…
Tech interviews are not reflective of real life regardless if there's a whiteboard present or not. Whenever I've had a whiteboard programming interview, it's always been a trivial problem that's a smoke test for "can this candidate actually write code or is their CV faked". I think it took somewhere between 5 to 15 minutes, which I consider to be rather well spent time compared to spending hours or days on a take hom…
> But it's a good binary indicator of whether they possess any coding skills
Also: can you discuss technical issues with them? Code quality feedback, finding bugs, explaining their thought processes, acknowledging mistakes, etc.
Imagine they're part of your team, and you come to them with a problem you're stuck on. Do you come away with a positive experience, and closer to a solution?
I'm responsible for hiring developers at our company based in Berlin, Germany, and found it best to have a guided interview about the candidate's work experience and interesting problems that she/he solved. I never understood the whiteboard hazing/CS trivia that are so widely discussed on HN since it seems extremely disconnected from the actual work that's being done. That said, I'm always surprised how many candidat…
So true.. and this is a great interviewing technique. I basically ask one question during an interview: what was the hardest problem you ever had to solve? It may sound stupid at first glance, but it gives you insight into not only the breadth of their technical knowledge (since that problem may not be germane to the position you're hiring for), but also the depth of their abilities. The way they answer this question reveals quite a bit about the person. Not only technical, but also their interpersonal abilities.. how they manage their place on a team, how they manage expectations up and below, etc. I can glean quite a bit about the person based on how they answer this one question. Only asking questions about your particular domain doesn't necessarily indicate how good they'll be at solving those types of problems, only how much they happen to know about them. Of course, you can say that perhaps they shouldn't be interviewing for a position they may not be qualified for, but frankly the best people I've ever hired had very little experience in problem sets that were specific to my day-to-day responsibilities, but delving into details about things that they've done told me a great deal about how they solve anything. It may not be the best way to hire, because it requires a breadth of technical knowledge of the interviewer, but it definitely has worked for me. Asking someone to solve a ridiculous puzzle on a whiteboard..when they're obviously nervous about being there in the first place seems kind of dumb to me. However, digging into a problem that they've solved immediately puts them at ease.
It's funny, whiteboard interviews really would be a better discriminator for founders than employees. They test confidence rather than competence (or technically, competence + confidence). The former is incredibly important for founders, but the latter is probably what you care about more for employees. And yet founders almost never do a whiteboard interview, yet it's standard for technical employees...
My view is that you can't have competence at a certain level without confidence - unless you're just an easily outsourced code slinger. I'm often at a whiteboard explaining architecture, ideas, etc. How do you do that without confidence and some semblance of emotional intelligence.
There is really no comparison. Explaining architecture, ideas etc to your colleagues has pretty much no resemblance to a whiteboard interview, where you have several people staring at you and judging you. One is a discussion the other is a test, they compare like having a beer with a colleague is like holding a speech in front of a bunch of stranger.
This is great. I would add https://toggl.com/, but I'm just a silly marketer and don't have a github account. btw not affiliated with toggl whatsoever - just a fan :D
As a follow up to the first interview, we give promising candidates a quite simple task to solve at home and then send back via email the next day. This is used both for some basic evaluation of developers skills (whether they actually solved the problem, did they catch the small oddities hidden in the data set, did they document and write tests, etc.) and as something to discuss during the second interview, in which…
Some time ago somebody mention in HN a process which sounded pretty good and fair. For promising candidates: 1) Meeting where you are presented a problem and asked to immediately give your thoughts on how you would approach it. 2) Some days, for example weekend, to work on the problem. Candidate gets a monetary compensation for this time. 3) Next meeting where you present the solution. Yes, there's always a risk that…
> Paying for the work shows you are serious about the recruitment.
In that case candidates should also pay companies to show they are serious about the position
I thought I disliked whiteboard coding, until I recently had an interview on a provided laptop running one of those JavaScript IDEs. It was miserable. Extreme unusable OS X mouse acceleration, an awful keyboard, an unfamiliar hotkey setup in the text editor, and a tiny 11 inch monitor split into 4 sections which means my editor was maybe 10 lines tall. I failed miserably at a relatively short and simple challenge tha…
Sounds like a company to avoid if they throw the improper tool for the job at you and expect you to do it with that, even if a pen & paper would be better.
Some guys I've met, with different occupations and age, sincerely believe that smaller screens are more usable. Like small windows on 14" CRT when everyone had 17/19". Now it's guys that claim that 11-13" ultrabook is enough for them and they don't want more ever. This honestly baffles me every time.
As a follow up to the first interview, we give promising candidates a quite simple task to solve at home and then send back via email the next day. This is used both for some basic evaluation of developers skills (whether they actually solved the problem, did they catch the small oddities hidden in the data set, did they document and write tests, etc.) and as something to discuss during the second interview, in which…
You expect people to write documentation and tests for an interview coding challenge? I sure hope you mention that expectation or at least strongly hint that you're looking for a production-ready coding mindset. It would never in a million years occur to me to write documentation or tests for an interview coding challenge.
This honestly surprises me. The coding challenges are pretty much always simple enough for a junior to complete. The only way I've ever seen to set yourself apart from the bottom half of applicants is to include tests, comments and even documentation. I also wouldn't expect that to be in the instructions, otherwise everyone would do it and you'd be harder pressed to find candidates to eliminate. I'm curious to know if completing the challenges without tests etc is commonplace. Does anyone else think it's an odd thing to expect?
> That said, I'm always surprised how many candidates cannot even point to one problem they worked on they found interesting or one solution that they're proud of. It could be that this technique favors people good at telling stories. Personally, I'm a horrible storyteller. If you were to ask me what I did over the weekend, I'll offer some facts like "oh, went swimming in a river and Bob lost his hat, but we found it…
Or, they just don't find the work terribly exciting. There's a lot of unexciting work to be done in software, and somebody has to do it.
There's definitely an industry bias towards "programmers as artists". If you don't love your work with a passion you're seen as less good.
It's an alright proxy for other things, but there's a ton of good developers that leave their ego at the door, and their work at work.
What's with all the whiteboard backlash? I ask simple questions and expect people to be able to write code unaided to express their idea. Not "implement a linked list" or "write quicksort" but basic "You have two arrays - find if a number exists in both arrays" sort of thing, primarily to reason about runtime complexity, and to make sure they can actually write code.
If you tell a candidate to prepare, they should be able to come in and do this. If they can't write some simple code unaided, then I don't want to work with them. I was a copy-paste programmer once too.