This is why you never end up hiring good developers • Hacker News Board

Re: This is why you never end up hiring good developers

#51

Post by pan69 » Sun, Aug 31, 2014, 9:10 PM UTC

Most often people like to hire people who are like themselves. If the interviewer has a fancy degree then he/she will be looking for someone else with a fancy degree. If the interview is self-made then he/she will be be looking for self-made.

There is a certain level of experience and insight required to rise above this as an interviewer. Having a good understanding of the direction of the company and the actual skills you're looking for. I've only seen a few people who actually got this but most of them were looking for clones.

Re: This is why you never end up hiring good developers

#52

Post by [deleted] » Sun, Aug 31, 2014, 9:22 PM UTC

andy_ppp wrote: post #4

Okay so the article is fairly standard stuff if you've read the Joel essays. When I interview now I get the candidate to break down a problem with me and answer it in sudo code. I'll ask questions and guide the candidate about how it could be done better, asking if there are there any edge cases we have missed and generally just build something out (a plan if you like). The best candidates tell you you are wrong (pol…

[deleted]

Re: This is why you never end up hiring good developers

#53

Post by fennecfoxen » Mon, Sep 01, 2014, 12:11 PM UTC

parennoob wrote: post #38

fennecfoxen wrote: post #3

Fizzbizz? Naah. What you want to do is something more like Minesweep. You go, "Mr. or Mrs. Candidate-Person, we're designing a Minesweep game. You've probably played it before. Here are the rules if you need clarifications. I'm handling the front-end, you write something for the backend." It doesn't matter the programming language they go for or the precise implementation they choose to any one of a number of issues.…

"There are basically two main types of candidates: the candidate who approaches the problem and says "I need to loop over every cell in sequence and assign a mine or not based on a random probability! Wait, what do you mean, I need to get a specific number of mines on the board? I'm not sure I can make that happen" ... and the candidate who's worth hiring." Since this interviewer seems to have made up their mind alre…

Any answer that gets the job done works. Looping through the mines in one pass with appropriate adjustment of probability (never seen it). Pick random spot and retry. Take all coordinates, shuffle, take N. Something I've never heard of? Sure, if you apply it and it works.

The preconception is that someone who isn't capable of coming up with a way to distributing X values into a data structure representing a M*N playing field isn't worth hiring. It's a stupidly simple task, light on the algorithms (much like the day-to-day programming tasks) and heavier on the "come up with something coherent and quasi-organized to accomplish a very simple goal" in a program.

As for the rules of Minesweeper, if you're rusty, I have a printout. :b

Re: This is why you never end up hiring good developers

#54

Post by dunmalg » Mon, Sep 01, 2014, 3:57 PM UTC

parennoob wrote: post #38

fennecfoxen wrote: post #3

Fizzbizz? Naah. What you want to do is something more like Minesweep. You go, "Mr. or Mrs. Candidate-Person, we're designing a Minesweep game. You've probably played it before. Here are the rules if you need clarifications. I'm handling the front-end, you write something for the backend." It doesn't matter the programming language they go for or the precise implementation they choose to any one of a number of issues.…

"There are basically two main types of candidates: the candidate who approaches the problem and says "I need to loop over every cell in sequence and assign a mine or not based on a random probability! Wait, what do you mean, I need to get a specific number of mines on the board? I'm not sure I can make that happen" ... and the candidate who's worth hiring." Since this interviewer seems to have made up their mind alre…

>Since this interviewer seems to have made up their mind already with pre-conceptions of which candidate is worth hiring, what is the "correct" answer to this question? "Pick random co-ordinates, check, and retry?"

The most efficient way (which is arguably unnecessary for Minesweeper) is to treat a 10x10 play field as a 1 dimensional array of size 100, stick your X number of mines in the first X cells in the array, then use something like the Fisher-Yates shuffle* on the array.

* Y = random number 1-100. Swap contents of cell Y and cell 100. Y = random number 1-99, swap contents of cell Y and cell 99. Repeat for entire array.

Re: This is why you never end up hiring good developers

#55

Post by henrikschroder » Wed, Sep 03, 2014, 4:27 AM UTC

sethammons wrote: post #34

deedubaya wrote: post #25

Interview questions often have less to do with the candidate than they have to do with the interviewer. Meaning: It's either a superiority thing, a desire to impress, or just plainly covering up for lack of real interview skills. Gauge a candidate's skill set by asking open ended general overview questions like "Tell me about SCM branching and what advantages they provide" or "Tell me about a time you might have enco…

I've interviewed candidates who can talk an amazing game but can't seem to code. Starting a couple of years ago at our organization, it has been required that candidates produce _something_ that can run (or come real close to it).

I agree completely. If you are hiring someone for a position where they are expected to write code, you should verify that they can actually write code, everything else is secondary.

And yet, here we have this article, and a bunch of commenters who seem to think it's perfectly ok to not verify the main requirement of the position. It's madness!