Live data from Hacker News

Hiring without whiteboards

github.com

181–190 of 372 posts

Re: Hiring without whiteboards

#181

Earlier quoted context omitted.

Dismissing someone using an objective/concrete criteria such as a failed programming test is not problematic. On the other hand, if you dismiss someone because "is not a cultural fit" or some other subjective reason, the person can sue you, accuse you of discrimination and challenge you to prove your point over a legal mine field.

Most companies avoid that by not giving candidates a reason why they were not hired.

And anyway a generic reason is "we decided to move forward with another candidate."

Re: Hiring without whiteboards

#182

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…

>> What's with all the whiteboard backlash?

Here's the deal.

As a developer, I have about 30 repos out on GitHub with plenty of examples I've done in the last three years. If you want to interview me, then go look at my code first. I have a pretty specific style so all the code is consistent. Go look at my code, dissect it, ask me questions about it, ask me why did this instead of that, why I prefer some library over another one, etc. If you feel like my skill set is what you're looking for, then bring me in and then we can see if we're a good fit for each other. If you don't like what you see, then don't bring me in - it's really that easy.

Having one or two whiteboard examples will never, ever, show someone the depth of your skill set. You have to look at their code, which will give you insights a whiteboard interview never will. All the things you mentioned about "basic skills" are obvious when you look at someone's code. Did they use classic or prototypal inheritance? Did they know what closures are? Did they use a factory pattern? Are they using ES6 yet? What tools are they using for their projects? All this and a ton more simply from looking at their code.

And if you're a developer, you should have an account on codeplex, or github, or bitbucket where interviewers can go look at what you're working on and the stuff you're building. It completely cuts out the "coding" part of the interview and should simplify the whole process.

Re: Hiring without whiteboards

#183

Earlier quoted context omitted.

What does that entail? I thought the US was not as strict on law for workers / interviews.

Dismissing someone using an objective/concrete criteria such as a failed programming test is not problematic. On the other hand, if you dismiss someone because "is not a cultural fit" or some other subjective reason, the person can sue you, accuse you of discrimination and challenge you to prove your point over a legal mine field.

Ah right, in NL where I did most interviewing you are not allowed to ask a woman if she is or plans to get pregnant for instance. Not exactly a subjective reason, but I think akin to what you are saying.

Re: Hiring without whiteboards

#184

I have a question. When you hire complete freshers out of school, how do you interview them without asking for CS stuff? In my experience, fresh undergrads usually do not have any real world experience. I have experimented with short take home projects. This drastically reduces the available pool, since great freshers can get job in other places with whiteboards interview. Also, there is a sense that interview proces…

Ask them what they studied and what their favorite courses where. Ask them what they found interesting. Ask them what kind of problems they can see themselves working on. Ask about what kind of projects they did and what they found easy and hard about them. Ask them some general programming questions. And by all means ask CS questions as well, but don't only ask that, and don't make them carry more weight than any other questions.

Re: Hiring without whiteboards

#185

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…

Part of this is that a lot of interview practices (including whiteboarding) exclude people that suffer from social anxiety.

Just because somebody freezes up when being watched and critiqued by an Evaluator, doesn't mean that they are 'copy-and-paste programmers'. There are probably a lot of extremely good engineers who find this style of interview difficult.

People that call 'whiteboarding' a skill don't really get it. If you have irrational fear over people's judgements and this manifests when you're being interviewed, you can't merely expose yourself to this fear often to lessen it. It is very difficult to change how your mind and body react to uncomfortable situations.

Of course, you need to test ability, but you should also accommodate people's preferences on the environment that they are evaluated in. You can negotiate whatever this is by speaking to them: they might have a Github with projects which they can discuss with you, or they might be happy to do a small project, etc. You need to keep your standards high, while also ensuring that they feel that they are able to do their best.

Re: Hiring without whiteboards

#186

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 somebody has been promoted multiple times in programming roles, and especially if they have a visible open-source corpus (not necessarily GitHub BTW), then you know they can code. Making them do it in a highly artificial environment is pointless at best. Other words like "insulting" and "demeaning" also come to mind.

Asking people to reason about complexity is great, but that's not the way such interviews usually go. More often, the interviewer asks about complexity only so that they can compare to their own solution copied from the best of a hundred other candidates and then hand-tuned for days. It's a gigantic ego trip, and not even a fair fight. Candidates can see that, and it tells them a lot about what kind of person the interviewer is. Hint: it's not a pretty picture.

I was fortunate to go through an interview process recently where I had to do coding interviews, and it wasn't just a big ego trip. Second time in thirty years, vs. dozens upon dozens (all passed) of the worse kind. I could tell the interviewers had actually been trained, because I've been on the other side of that desk. They didn't care about the code I wrote, so much as how I approached a new problem, dealt with edge cases, explained various decisions, responded to challenges, etc. That's how it should be, but doing this stuff right is hard. Very few who pretend to do it have invested the time to do it properly, so they get results that are worse than useless. That's why there's so much hatred of the approach. Most people have never seen this kind of interview done right, and it's not their fault that's the case. It's on people who went from copy-paste programming to copycat interviewing.

Re: Hiring without whiteboards

#187

Earlier quoted context omitted.

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.

Because sometimes you are expected to write working code on whiteboard. Once interviewer was typing code I wrote on laptop and interrupting me on errors he had.

Re: Hiring without whiteboards

#188
post #184

I have a question. When you hire complete freshers out of school, how do you interview them without asking for CS stuff? In my experience, fresh undergrads usually do not have any real world experience. I have experimented with short take home projects. This drastically reduces the available pool, since great freshers can get job in other places with whiteboards interview. Also, there is a sense that interview proces…

Ask them what they studied and what their favorite courses where. Ask them what they found interesting. Ask them what kind of problems they can see themselves working on. Ask about what kind of projects they did and what they found easy and hard about them. Ask them some general programming questions. And by all means ask CS questions as well, but don't only ask that, and don't make them carry more weight than any ot…

You will be surprised how often people with good grades will have good answer for these questions. But can't write dual for loops.

I agree that asking people to write dynamic programming problems are not good interview questions. But if the job requires primarily writing code, I think it is fair to ask people to solve coding problems with loops, conditional statements, hashtables, etc.

Re: Hiring without whiteboards

#189
post #33

Earlier quoted context omitted.

It's not disrespectful for a company to ask you to write a little code for them. They're just as invested on the time front as you are since they have to read and analyze what you send them. Now, if you were to tell me that nobody ever looked at the test after you sent it in, then it becomes disrespectful. I had several companies do that to me a few months ago. Not that it matters much. I don't think code tests will…

A little time is fine but last time I was applying for developer jobs almost all of these tasks would take at least an hour to complete, probably more like two or three to do it in a way I'm willing to show to someone screening me on that basis. By requiring these tasks you're implicitly screening not only people who can't code but also people who don't have three hours to spend on applying to your company. If all yo…

Hmm. One of the best exercises I ever had to solve took me almost a day. [1] I have actually rewritten it twice, once in the manner they said they would have wanted it (same repo) and once in Python. (I didn't get the job, they didn't like the style I was using.)

I don't mind long coding exercises, it's what I do all day anyway. Better than watching yet another episode of NCIS or what have you :)

[1] https://github.com/mdpopescu/public/tree/master/SocialNetwor...

Re: Hiring without whiteboards

#190

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…

Whiteboarding itself is a skill. What I learned the hard way: - There is no insert. If you need to go back and insert a line of code somewhere you must either erase all the code below it to make room (then rewrite said code), or you draw a line from the insertion point to somewhere else on the white board and write the code there. For the former you waste a lot of time. For the later the code quickly becomes hard to…

I am assuming that you can use pseudocode
Post reply on HN