Live data from Hacker News

Hiring without whiteboards

github.com

161–170 of 372 posts

Re: Hiring without whiteboards

#161
post #13

Am I the only one who thinks the pressure a whiteboard adds is actually something valuable? In my last job there were a lot of situations where you had to solve a real problem under extreme pressure. People who couldn't handle it simply weren't cut for the job. I don't think all interviews should use it but for us it was good for filtering out candidates who would not perform in those situations.

What on earth were you doing that required solving software problems under extreme pressure?!

This sounds like an incredibly toxic working environment, where developers are either being allowed to create fires on production systems, or management is completely incompetent or both.

Also, being able to "handle it" has nothing to do with anything in this discussion. I'd much prefer to hire someone capable enough to not need to "handle it" than someone proud of the fact that they often s*it the bed but are willing to jump up and do the laundry under pressure.

Re: Hiring without whiteboards

#162
post #147

Earlier quoted context omitted.

> If they start talking about whether or not the arrays are sorted, how big they are, whether you could refactor the array building code to return the data as a object index instead ... then it's clear that the person knows how to code simple things, and all without needing to pick up a marker pen Having worked with people like this, I have to call BS. There are a lot of people with the distinct skill of being able t…

> Having worked with people like this, I have to call BS. There are a lot of people with the distinct skill of being able to effectively imitate the speech patterns of actual programmers. Asking questions, engaging in productive discussion, etc. But when faced with an empty editor, they simply cannot produce working code. Having never worked with anyone like that, I will have to call BS on this because it is simply t…

It's all too true. There are, in my estimation, probably twice as many people who can talk around in circles and make it sound like they know what they are talking about, as people who can actually knuckle down and get things done. There's a little bit of overlap in the Venn diagram there, but not as much as you might think, for whatever reason. Probably because the people who can actually do things are too busy implementing all the shit that the bullshitters get their teams on the hook for.

Re: Hiring without whiteboards

#163
post #120

Earlier quoted context omitted.

So you test their ability to write code on the whiteboard. I was once programming with pen and paper too (only had access to computers at university). They I bought my own computer.

Don't know why this comment is downvoted, because he has a point. Writing actual code on whiteboard is different, unless it's pseudocode without any syntax rules and standard libraries. I'm not a newbie (like, 15 years coding). But I haven't even bothered to properly remember standard libraries peculiarities - since they're different across the languages anyway, and with modern software stacks (that are quite diverse…

Why does everyone assume that you're asked to write perfect code on a whiteboard? I've been through 15+ interviews and have never been asked to worry about method names being right or signatures of methods being perfect and such. Most of the time people are amicably against me worrying about it. This isn't an issue.

Re: Hiring without whiteboards

#164
post #153

I work remotely and sometimes interview new potential hires. Does anyone have some suggestions for how I could imitate whiteboard questions without actually having a marker and surface available to me or the candidate? It's a little awkward to ask them to write on a piece of paper and angle their camera so I can see what they're writing! Is there any good software that can emulate this?

I do this all the time. What I do is make sure that the question, and anything that I would want to write on the whiteboard, is typed up ahead of time. Then, I use a teleconferencing program that supports sound, screen sharing, and IM. (Gotomeeting works well for me, but there's plenty others that work well too.)

In the actual interview, I IM the written parts of the question to the candidate. Then, I ask the candidate to share his/her screen, and use a program like Notepad or Textedit to complete the question.

It's useful if the candidate copy/pastes my IMs into Notepad / Textedit. Often I've provided a sample API that the candidate needs to program with.

I discourage using an IDE like Visual Studio or XCode. (They get in the way when you're just trying to quickly express an idea.) Most candidates "get it" that I'm just trying to see how they think and approach a problem.

Some candidates just feel more comfortable in an IDE, though. Other times, though, when a candidate uses an IDE it shows that the candidate will get too bogged down in details to communicate; or that the candidate really doesn't understand the language that he/she claims to be proficient in.

Edit: In the context of the article, I'm a HUGE fan of whiteboard coding. It tells me a lot about the candidate. Being on both sides of an interview; a successful whiteboard interview has more to do with how the interviewer plans the question and his/her expectations about what the candidate will answer. A whiteboard interview isn't there to determine that a candidate can think of a tricky algorithm; it's there to judge coding ability for very obvious problems with well-known APIs.

Where I think the industry needs to go, though, is a universal certification that demonstrates competence. Doctors have to go through this, thus doctors don't need to demonstrate competence when interviewing for a job. That's handled by the impartial 3rd party.

Re: Hiring without whiteboards

#165

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…

>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.

Lovely. Someone put up with you, but now you won't do the same and offer to teach.

Re: Hiring without whiteboards

#166

Earlier quoted context omitted.

My office is a satellite of a larger one in Austin; we provide laptops for candidates to use for the "remote" part of the interview, when they interview with someone in Austin. But in general, I think the idea of the whiteboard interview is a chance to see someone "think out loud", to see them reason through a problem. Getting a chunk of source code in an email isn't representative of that. (At worst, they paid someo…

> But in general, I think the idea of the whiteboard interview is a chance to see someone "think out loud", to see them reason through a problem. So thinking out loud while coding is a job requirement now? I have been an engineer for over 14 years, and a software engineer for 10, and I can count on one hand the number of times I have done that outside of an interview. I collaborate all the time , but almost never syn…

Reasoning about problems is a very essential job requirement. And doing that out loud is the one of the few ways people can see how/if you do that.

Re: Hiring without whiteboards

#167

I would like to see a compilation of companies that aren't requiring a "coding project" as part of their interview process. I much prefer to write on a whiteboard as part of an onsite interview than to do a "coding project" for every single company that "might" be interested in me. My experience lately has been an immediate request to complete a coding project right after speaking to a recruiter but before speaking t…

Presumably a lot fewer people send in completed coding projects, so you are competing against fewer other candidates. If you are good at selling yourself, whiteboard interviews are awesome. If you are nervous in interview situations, starting with a project could be an advantage. Edited to add: coming in for a whiteboard interview will also take few hours of your time (or longer if you need to travel). A sample proje…

Yea but the process is never just coding project... It's either just whiteboard interviews or a coding project and then whiteboard interviews. There's never a reduction in time here

Re: Hiring without whiteboards

#168

Earlier quoted context omitted.

I think the primary problem with this sort of interview process is that most companies don't hire enough people to discover whether or not it actually works, plus an interview is so much of a multivariate problem that you'll never really know which part of the process is broken if a bad hire gets though. And that's compounded by the fact any false negatives (great candidates who would have fitted in but got rejected)…

Why is mentioning loops a bad sign? The question is simple, and asks for only checking one value; that's a simple answer that, for one value, takes linear time, which is the best you can do (without assuming the array is sorted, but expecting someone to ask you if the array is sorted turns it into a trick question, rather than a real world one). I mean, yes, I'd prefer them to go to a library call for that, but I wou…

...that's more interview technique, not actual coding skill.

The skill and art of "coding" is in finding solutions to problems, not "writing code". When I interview people I'm looking for someone who can explore problems, ask questions, and find good solutions. If they don't feel like they have enough information I expect them to question things. If they're working on assumptions (like 'what does the array actually look like?') I expect them to question those assumptions. Expecting someone to go deeper in to a problem by finding out more is not "trying to trick them", it's a discovering whether or not they can do a fundamental part of any development job.

Re: Hiring without whiteboards

#169
post #131
post #60

Earlier quoted context omitted.

> 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…

> > 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. Or people who think they're impressive. I know I would've been able to point out many problems and solutions I found interesting and were impressed with when I was 15. Today, not so…

At this point in my career I'd have to say I agree. Many of my team are at the start of their careers. I find it really interesting the number of times they seem impressed by something I did that I'm just "meh" about.

Oddly enough, the opposite is true as well. I'm constantly impressed at the level of ability they have at this point in their career as compared to my ability at the same point in my career. They just simply know more. Of course, there's more to know these days but still, I find it impressive.

Re: Hiring without whiteboards

#170

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…

We do technical interviews on conceptual levels. One manager, one HR, one programmer (not always all three at the same time) and the interviewee.

We ask them about their experience with the tech we use / plan to use and test what they tell us with specific questions. If you tell us you know ASP.NET, I might ask you to describe the default routing or some specifics about razor views. If you tell me you are a git expert, I might ask you about interactive rebases and cherry-picking to find out when and how you'd use them.

General know-how is usually more viable than the ability to write working code in a pinch. The closest thing to a whiteboard test we have is giving you a page of code to ask you what's wrong with it (although, we don't do that often).

Post reply on HN