Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How I Interview

rkoutnik.com

Post reply on HN
Print view View original

11–20 of 129 posts

Re: How I Interview

#11

Post by ryandrake »

What? "Implement as much of Minesweeper as you can in an hour?" If you're going to build something--evens something as simple as Minesweeper, you're still going to need time to plan it out, diagram it, decide which modules call into which other ones, decide on the data structures, etc. Diving right into writing code so you can get _something_ done in an hour is probably the worst strategy if your goal is to do it right.

I'd rather work with the person who would approach that by taking 3 hours to plan, 3 hours to code, and 2 hours to bug fix, rather than the "Ready, Fire, Aim" person who took 1 hour to code, 4 hours to fix what he did, 8 more hours to find his design was totally wrong and re-do major portions of it, 8 more fixing the bugs in that version........

Unless you plan to filter out the people who just jumped into the code, in which the exercise is just a trick question.

Re: How I Interview

#12

Post by alexandercrohde »

vdnkh wrote: post #5

I had an interview like this recently. A "live coding" exercise after (in their words) two excellent phone screens. The test was to implement a class which would be run through a bunch of unit tests. Simple right? It turned out to be a disaster. First was the choice of language. They offered to take it in JS, Ruby, Python, or Java. I'm a .NET developer whose competent with JS, but I really could be better at it. I as…

I sympathize. I remember when I was first applying for tech jobs I was often given a mac (which I was unfamiliar with) set in Qwerty (I used Dvorak) and told "just write this."

Even asking them to change it to Dvorak for me (since I wasn't familiar with the menus) I could tell they were judging me. Once I bit the the bullet and learned the mac interface suddenly people were assuming I was super hardcore because I use Dvorak.... Stereotypes cut both ways I guess.

Re: How I Interview

#13

Post by autarch »

Where I work we do something similar but it's a "homework" question we give to people who pass our initial resume screen (https://github.com/maxmind/dev-hire-homework). We tell them not to spend more than 1-2 hours on it. We decide whether or not to interview them based on the quality of the code they produce.

In the interview we ask things like:

* what is OO and how is it different from procedural programming? (high level conceptual) * why do you want to leave your current position? * what appeals to you about this job? what do you think you might like least? * what is the purpose of testing? * tell us about the programming languages you've used. what's your favorite? what do you like most about it? least?

I'd rather have a more conversational interview after already having established their ability to code.

Re: How I Interview

#14

Post by ilostmykeys »

alexandercrohde wrote: post #10

I was really liking this piece, but one inherent flaw of the example given is that I've already implemented minesweeper in javascript once a couple years ago for a programming challenge, so I'd have a major advantage over most candidates. For example, I immediately recalled I solved the problem of mine placement with a 1 liner like: var cells = ('*'.repeat(mineCount) + ' '.repeat(size - mineCount)).split("").sort(fun…

typo: math.rand --> Math.random

Re: How I Interview

#15

Post by [deleted] »

lilcarlyung wrote: post #6

Would be funny to come into an interview as the candidate and give the employer pre-packaged tasks to complete to evaluate them on, to decide if I as the candidate actually want to work there.

[deleted]

Re: How I Interview

#16

Post by ilostmykeys »

fillskills wrote: post #3

Interesting points. Like the idea of the giving a developer actual development tasks. This is how I interview - We have a bitbucket set up with a project very similar to our current site. We simply ask everyone who applies to get the code from Bitbucket and install it locally. And then fix a simple bug. Most developers who are well versed in the basics are able to install the code in 2-4 hours. People new to somethin…

I love the bug fixing stuff especially if I'm allowed to re-architect your stuff so that it's less prone to bugs to start with ;)

Re: How I Interview

#17

Post by RKoutnik »

lilcarlyung wrote: post #6

Would be funny to come into an interview as the candidate and give the employer pre-packaged tasks to complete to evaluate them on, to decide if I as the candidate actually want to work there.

I've got the outline for another article along these lines (how I prepare for an interview) though it's been longer since I've been through an interview.

As a candidate, you'd bring less pre-packaged tasks and more questions and things to look out for. When I'm on the other side of the interviewing table, I evaluate the company as much as they evaluate me. Things like "What does it take to succeed at this company?" and "If I'm not meeting expectations, how will I know?" are critical to see if you want to work there.

Anyway, stay tuned!

Re: How I Interview

#18

Post by RKoutnik »

vdnkh wrote: post #5

I had an interview like this recently. A "live coding" exercise after (in their words) two excellent phone screens. The test was to implement a class which would be run through a bunch of unit tests. Simple right? It turned out to be a disaster. First was the choice of language. They offered to take it in JS, Ruby, Python, or Java. I'm a .NET developer whose competent with JS, but I really could be better at it. I as…

Ouch, that's just a crummy interview experience. If you're coming in with the understanding that .NET is your best language, seems odd they wouldn't allow that, or at least make amends, such as letting you know in advance that it'll be about Jasmine, or using your own IDE.

Re: How I Interview

#19

Post by RKoutnik »

ryandrake wrote: post #11

What? "Implement as much of Minesweeper as you can in an hour?" If you're going to build something--evens something as simple as Minesweeper, you're still going to need time to plan it out, diagram it, decide which modules call into which other ones, decide on the data structures, etc. Diving right into writing code so you can get _something_ done in an hour is probably the worst strategy if your goal is to do it rig…

I've had folks who just jump into the code without any planning. It usually bites them about 20-30 minutes in. On the other hand, I remember one guy who spent the first 20 minutes planning and only 40 coding and ended up doing better than most.

The point here is not "Write as many lines of code as you can". I want the candidate to plan - it's a crucial part of the job. FizzBuzz, sorts and the like don't require much planning. Minesweeper does.

Re: How I Interview

#20

Post by RKoutnik »

padolsey wrote: post #8
i_s wrote: post #4

Earlier quoted context omitted.

> Being given a pre-packaged task to complete feels very procedural and bland... This part is important: > Having a consistent test also allows me to compare candidates easily and without bias. Also, I think most people would care more about the content of the exercise, rather than whether it is prepackaged or not.

I get that. I just would rather not feel like a monkey being prodded whenever I attend an interview. An interview being repeatable (for comparative purposes) brings no value to the candidate.

It does if the candidate is something that the interviewer might be biased against (race, gender, opinions on Star Wars). Avoiding bias in interviews helps everyone except those who rely on irrelevant qualities to get jobs.
Post reply on HN