Sigh. This is the issue that will just never die. Let's just summarize the points: - Not everyone can produce real-world code. Most of what we do for a living belongs to our employer. Side projects, particularly in the US, can be an issue for IP reasons (California is somewhat of an exception here); - Side projects, even open source projects, can be of questionable "real world" value; - I've personally encountered ma…
Why we don't hire programmers based on puzzles and tricks
311–320 of 460 posts
Re: Why we don't hire programmers based on puzzles and tricks
#312Earlier quoted context omitted.
All this teeth-gnashing regarding programming and logic puzzles are simply to cover up the simple fact that most people (even around here) are insecure about their programming skill, and more-so their intelligence. The fact is that these types of questions are indeed backed up by the very research you cite, namely that a work-sample test and general mental ability are the only reliable predictors of job performance.…
I think this is basically true. But a point worth making is that a "puzzle" problem is a much heavier thing than lightweight tests like FizzBuzz. If you hand someone a puzzle you're pretty much guaranteed (absent the rare, truly gifted candidate) to watch them struggle at a whiteboard for half an hour. FizzBuzz (or "reverse words in a sentence", or whatever) will tell you the same thing in a minute or two. Basically,…
Two bits of information could potentially answer this: does intelligence as a predictor of future job success drop off past a certain level? Also, what does the distribution of IQ look like for those who are fluent coders?
Re: Why we don't hire programmers based on puzzles and tricks
#313Earlier quoted context omitted.
I haven't heard of those silly questions in the intern interview circuit. (2 at-school, 4 on campus)
My impression is that they are no longer in vogue - for a few years when I was in college (2004-ish) they were all over the place. Our industry is extremely faddish, even when it comes to interviewing... You can still see them in some places I believe. I've heard anecdotally that Microsoft is still a fan of them.
I should add that my personal experience contrasts with yours - I did a lot of interviews around 2004 and got asked riddle-type questions by one, maybe two, people. My memory is that they mostly died with the original dot-com boom.
Re: Why we don't hire programmers based on puzzles and tricks
#314Earlier quoted context omitted.
"Asking a candidate a difficult brainteaser that may be even close to impossible can be extremely revealing." I prefer problems that are ridiculously simple on the outside; however, allow for lots of optimization. Choose the next best move in chess or go for example (or design a simple sudoku solver). A completely simplistic solver just chooses a valid move. It becomes more interesting as one looks at how are you mod…
"Choose the next best move in chess or go for example (or design a simple sudoku solver). " You make the assumption that your candidate knows anything about those games. If you placed me in front of a chess board, said "these are what the pieces do" and then asked me to tell you the next best move, that move will either be A) blindingly obvious to anyone who has played chess for years, or B) too difficult to someone…
Re: Why we don't hire programmers based on puzzles and tricks
#315Earlier quoted context omitted.
> As an interviewer it is important to ask questions that a candidate cannot answer to see how they react. In the context of an interview, that would just make me horribly frustrated--because my default response to not knowing the answer to a question, nor even being able to perceive a method to resolving my ignorance, is to go out and research the problem. Whether on the Internet, or by asking my coworkers, or findi…
Answering "In the context of an interview, [I get] frustrated because my default response to not knowing the answer to a question ... is to go out and research the problem [and I cannot do that in an interview]" is a nice response to not knowing an answer and would get bonus points for honesty and self-awareness. The best candidates will recognize and comment on the ways in which frustration can be either constructiv…
Re: Why we don't hire programmers based on puzzles and tricks
#316Earlier quoted context omitted.
I think the point of the article is this: Trivial puzzlers like:write a fizzbuzz program, swap two variable contents without using a temp variable, how do you count the stars in the universe Just encourage people to game the system. It's impossible to get real insight from them, because you can't differentiate between those who worked it out, and those who have read about it. If you're in an interview by now and some…
Come to think of it, swapping two variables in place is a horrible question - because you can't really do it! A statement like a = a + b requires the (invisible) presence of a register where a + b (or xor or whatever) is placed right before being written back to a. But then you might as well use this register directly for the swap instead of dabbling around with one-to-one functions.
Re: Why we don't hire programmers based on puzzles and tricks
#317I probe for weakness in 5-6 different areas of computer science in the phone screen - keeps me from bringing in weak candidates.
Then in the on-site, I give them my Macbook and ask them to solve a few simple problems with some flat files I conjured in a language of their choice that's installed on that machine (C/C++/Java/Python/Ruby/PHP/Perl/shell/etc). You get an idea of how they solve problems, think about solutions, fix bugs, avoid common errors, and what they look up on the web (I let them use a browser to lookup apis and so forth - it's a good way to weed out "cut and paste" programmers). The people who do well finish quickly and we chat about the company with the remaining time - the people who do poorly use almost all the time on the first problem, make a bunch of mistakes, and usually don't understand the proper data structure for the job.
Re: Why we don't hire programmers based on puzzles and tricks
#318Earlier quoted context omitted.
What is shocking is the fact that in companies where devs have no say in hiring, managers hire those people and then ignore the fact that they do nothing (or try to promote them out of development) to try and cover up their mistake. It is incredibly demoralizing working ten hour days trying to deliver working code while someone else is producing nothing, getting ahead, and going home at 4 pm. This shit is by far the…
How do you " keep it real " in interviews? Concerning the viability of firing under-performing individuals, how likely is that? Are there any implications with indirect costs such as unemployment benefits? (I ask because I do not know - any insight on this would be greatly appreciated.)
Re: Why we don't hire programmers based on puzzles and tricks
#319Earlier quoted context omitted.
Actually, yes...they do. I work in a building with an elevator control system designed by an internal engineer. More importantly, the elevator control system uses mathematical expertise that is normally used solving variants of the multi-commodity flow problem, used extensively in the Supply Chain.
Heh, that's pretty cool. How does it compare to the average elevator?