Why do we always feel the need to upvote posts like these as if we don't discuss them every 2 weeks?
Next up in the topic cycle: Discrimination in tech. Why working more than 40 hours a week is killing your productivity.
Why we don't hire programmers based on puzzles and tricks
111–120 of 460 posts
Re: Why we don't hire programmers based on puzzles and tricks
#112I think the skills you need to throw together a nice RoR app are different from other positions.
I wouldn't want on critical infrastructure code alongside someone who can't reason through the performance implications of their code on the fly. You can waste a hell of a lot of time diagnosing and fixing performance problems because someone built an entire module around an inappropriate data structure.
Re: Why we don't hire programmers based on puzzles and tricks
#113About a year ago I travelled to the south west (of UK) for a job - A full day of interviews, product ideas, I nailed the whole lot. Apart from the obligatory coding test. I have 15 years in this game and I have coded OSS or commercial code every day or week in Python, the language of the test, since 96.
It was a codility.com test - I had not actually been expecting it but, kerpow. I rewrote my own abs() because I forgot such a thing existed, the problem itself is still blanked from my brain - and every passing minute it got worse.
After an hour and a half, the interviewer took pity on me and drove me to the station.
I actually sat on the train took the codility demo test. 100%, 3 minutes. Signed up, took more. I could do them. Just impossible to know what went wrong but it went badly wrong.
Ultimately it worked out well. I would have had to live weekdays down there and my marriage probably would not have survived it. Now I work 15 minutes walk away and give my kids breakfast each day after we sit on the sofa and watch Mister Maker.
For me that test was a wake up call.
Firstly, I run my own business - being at the mercy of one boss is rubbish.
Secondly, these tests are rubbish for deciding who to hire - but they are OK for programmers as a form of continuing education.
Thirdly, the exercises at the end of each chapter of SICP are much much better form of education.
Forthly, I was once asked how a large corporate IT shop should handle a reduction in workforce. I said march everyone into a room and those who cant code FizzBuzz get a pink slip
Even given my experiences above - I still think that is the best option. Sometimes a guy just dies on that day. Its unlucky. But sometimes it works out for the best.
edit: clarity
Re: Why we don't hire programmers based on puzzles and tricks
#114Sigh. 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…
I'm not sure if I'm that guy or not... but anyhow, here's the hiring process that's given me some good results. Note that this requires that your team does pairing. Interviewing answers three questions: Can they do the job? Do they get along with the team? And, can they adapt when the game changes? Before your phone interview, let them know that you want to do a short screen-sharing and pair-programming exercise via…
I don't know if this is a Silicon Valley thing or what, but the idea that someone would basically do a day's unpaid work on projects they know nothing about with three different people is just about the most foreign thing I can think of.
That being said, I've never done any pairing so maybe it would work better in that type of environment.
Re: Why we don't hire programmers based on puzzles and tricks
#115Coming up with good questions to ask in an interview is an effort that the hiring team needs to invest in. This involves a top down reflection of the job along with a vision for the job. It requires to ask him/her self before hand "What sort of tasks is this hire going to be doing" , " What language skills does he need" , " Does he need to reinvent a sorting algorithm to get this job " .
Well this rarely happens , to start of folks (generally) tasked with the hiring process are not the right "vision" folks. They are highly task oriented individuals aka MS Project specialists.
A real test would have to encompass among many things. - Do they are ask the right questions ? - Are they capable of picking up new languages, ideas , technologies while defending or questioning changes in an articulate yet respectable demeanor. - how they handle things when they get to a wall.
Re: Why we don't hire programmers based on puzzles and tricks
#116Sigh. 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…
I'm not sure if I'm that guy or not... but anyhow, here's the hiring process that's given me some good results. Note that this requires that your team does pairing. Interviewing answers three questions: Can they do the job? Do they get along with the team? And, can they adapt when the game changes? Before your phone interview, let them know that you want to do a short screen-sharing and pair-programming exercise via…
I'm curious if you wouldn't mind sharing a few more details of your experience pairing a candidate in the office with your senior engineers.
- Are the candidates able to help make meaningful contributions to whatever the senior engineers are working on without having the background and domain knowledge?
- Do the employees have to spend a significant amount of the 2-3 hours with the candidate bringing them up to speed on what they are working on, just so that the candidate isn't totally in the dark? If yes, does this totally sideline the employees day/flow?
- What do you do if the employees don't have several hours of non-stop coding lined up for the day?
I don't doubt this method works well - but I'm curious how you work through some of the stickier issues of pairing a total outsider with a fully-up-to-speed engineer and then evaluating the outsider based on what was produced in those 2-3 hours.
Re: Why we don't hire programmers based on puzzles and tricks
#117At ITA Software, we found in-person quizzing to be a lot less useful an indicator than looking at puzzle (or other) code someone had written "offline". We also found puzzles to be a useful talent magnet. If you're Google (or perhaps 37Signals) you don't need a talent magnet. If you're a small company nobody's heard of, one can be quite helpful.
I wonder if ITA Software is still able to use this recruiting approach now that they are a part of Google.
Re: Why we don't hire programmers based on puzzles and tricks
#118As Cletus wrote in his detailed comment, "this is the issue that will just never die." We discuss company hiring procedures here on Hacker News over and over and over, because most of us have applied for a job at least once in our life, and those of us who are building up a start-up have to think about whom we would hire. The point in the submitted blog post by 37 Signals, "The only reliable gauge I’ve found for futu…
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. But this is exactly what programming puzzles are (and to a lesser extent logic puzzles). A programming puzzle is simply the intersection of a work-sample test and an IQ test. And of course, logic skills and programming skills go hand-in-hand. Instead of writing endless blog posts and internet comments about how useless these tests are (trying to convince a potential future hiring manager not to use them on you), just get better at them! You'll be better off for it.
Of course, not all programming jobs (most, in fact) need top 10% programmers with gifted IQs. It is important that jobs are honest with themselves regarding the level of talent they need for their next sexting iphone app. But this too is a part of the problem. Everyone believes their shitty app or website is going to change the world, and thus need world-class developers to help them realize their vision. Egos will be the death of us all.
Re: Why we don't hire programmers based on puzzles and tricks
#119Sigh. 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…
I'm not sure if I'm that guy or not... but anyhow, here's the hiring process that's given me some good results. Note that this requires that your team does pairing. Interviewing answers three questions: Can they do the job? Do they get along with the team? And, can they adapt when the game changes? Before your phone interview, let them know that you want to do a short screen-sharing and pair-programming exercise via…
No, you're not that guy, tokenadult is :-)
Re: Why we don't hire programmers based on puzzles and tricks
#120Earlier quoted context omitted.
I think that question about why manhole covers are round is more of a urban legend than anything else. Or it might be a question asked to someone applying for a non-technical role, to see how they reason about the issue (though it is most definitely not the best question to achieve so).
I was asked that question during an interview for a technical role at Microsoft. Granted, it was 13 years ago at this point, but they did really ask stuff like that, and probably still do.
I haven't heard of those silly questions in the intern interview circuit. (2 at-school, 4 on campus)