Why we don't hire programmers based on puzzles and tricks • Hacker News Board

Re: Why we don't hire programmers based on puzzles and tricks

#431

Post by mbell » Sat, Feb 23, 2013, 7:34 PM UTC

kyberias wrote: post #419

mbell wrote: post #418

Earlier quoted context omitted.

I'm sorry but writing code on a write board, ever, is stupid. I'm happy to write out architectures on a whiteboard, but code, never. Asking someone to write code on a whiteboard is the equivalent to asking a UI designer to chisel wood to demonstrate their ability to develop a web UI. It's rediculous.

I'm sorry but you are incorrect. It is not equivalent. It would make perfect sense to ask UI designer to draft a design on a white board. Same applies to coding. You don't get the point. It's about seeing how the applicant thinks and communicates under pressure. The thinking out aloud part is more important than the white board part. Everyone knows this, except you?

You can determine how someone thinks without trying to code on a whiteboard. I've interviewed many people for tech jobs recently, I've never even considered asking them to code on a whiteboard.

Writing code on a whiteboard is massively obnoxious. The times I've been asked to write code on a whiteboard I've spent more time screwing with the 'interface' than I ever have spent 'thinking'. e.g. trying to keep a line of text level, figuring out how to get brackets to line up, and erasing lines to reorder or writing lines off to the side with an arrow pointing to where it should go. A whiteboard is the worst possible interface for creating strictly structured text.

You aren't testing how the person thinks, your testing how they deal will a situation you've artificially made as awkward as possible, why? What does this actually indicate to you about the applicant?

If you want to quiz a candidate on how they think when coding then hand them a laptop that is already setup to duplicate its display to a projector. Or give them a simple 'take home' project. You'll learn vasty more than having them regurgitate algorithms on a whiteboard.

Re: Why we don't hire programmers based on puzzles and tricks

#432

Post by mamcx » Sat, Feb 23, 2013, 7:34 PM UTC

mmorett wrote: post #400

doktrin wrote: post #353

Earlier quoted context omitted.

Reversing a string is actually an incredibly common interview question. It's a bit like FizzBuzz (IME even more common, but I can't really speak about the world at large).

It might be an incredibly common interview question, but it's not an incredibly common day-to-day task, particularly when there are methods built in to classes that perform this function. An interesting task? Perhaps. But not reflection of the dev's skills, per se. You're not asking about syntax with this. It's a problem solving question and at the end of the day, the only real metric here is not whether a dev could…

> So you continue to use that question?

Well, yes. Is the most simple one I can think that show if a person can declare variables, do a loop and show the result. If exist something better, I wanna know!

Before that question, I do things more complicated. Like do some CRUD, or some kind of task that was realted to the company I was before. But my first results with that lead me to simplify the interview a lot (in time and questions) because I see that if a person can't do this kind of task is pointless try with something better.

And I don't do much presure. I let them alone and give them all the time they want, with internet acces and that. I continue doing my work while they complete the task.

Is important to understand that in my past companies I was tasked to interview fresh graduated coders, and for a lot of backgrounds. And they pay badly. So no much oportunity of get "top players" back them. However, I interview several people with (in theory) experience or from reputable universities and that not change at all the end results.

P.D: Some point to the complications of do this task properly (because unicode). I don't even expect that kind of depth in the answer, looking more in the basic skill, code formatting, and the ability to explain the code writed...

Re: Why we don't hire programmers based on puzzles and tricks

#433

Post by saryant » Sat, Feb 23, 2013, 7:41 PM UTC

pm90 wrote: post #204

3pt14159 wrote: post #42

Earlier quoted context omitted.

"What is the big O time of heap sort?" vs "Would you mind writing a function that returns true if any two numbers in the list sum to zero? For example, it would return false for [2,3,5] and true for [-3,5,3]" Are completely different questions. The first is useless: It tests if someone remembers how a heap sort works, and whether or not they use the term "worst case" in the answer. The second one is much better. Some…

Very good illustration, I must say. I strongly disagreed with the GP's rant about knowing O-notation, but I realized he might have faced the first type of questions a lot (e.g tell me the O-complexity of X algorithm). My experience with Amazon was actually the opposite, but I might have been lucky. All the interviewers were very friendly and started from simple questions and went on to more complex ones. Never a "do…

That was my experience at Amazon as well. Most of the interviewers were very good and the questions were a reasonable judge of skill IMO.

I didn't get an offer (understandably so) but I thought the interview was good.

Re: Why we don't hire programmers based on puzzles and tricks

#434

Post by lrobb » Sat, Feb 23, 2013, 7:58 PM UTC

tatsuke95 wrote: post #380

crazygringo wrote: post #355

Earlier quoted context omitted.

Nope. No wage, no tips. In my case it lasted two nights only, and was paid the third night (and making the big bucks on weekend nights within a couple of months), but I'd heard of it being as long as a week at other places. The worst part was, you wouldn't even know how long the trial period was -- they'd just ask you, last minute, if you could come in again for another trial. If it's a place you wanted to work at ev…

> "Nope. No wage, no tips." That sounds illegal, at least here in Canada.

It's illegal in the US as well.

Re: Why we don't hire programmers based on puzzles and tricks

#435

Post by suresk » Sat, Feb 23, 2013, 8:10 PM UTC

jameshart wrote: post #429

suresk wrote: post #403

Earlier quoted context omitted.

I don't see how reversing a string is a "puzzle" - I'd put its difficulty on par (or maybe slightly harder than) fizzbuzz. In most mainstream languages, it requires 2 pieces of knowledge: 1) That a string is implemented as an array of characters. 2) How to reverse an array. The implementation is straightforward and should be trivial for just about anyone who's done much development. I don't know that the question is…

And at 1), you went wrong, in any language where strings are in unicode. Combining characters, byte order markers, surrogate pairs... And this is why I dislike the 'reversing a string' question. Because if you actually know anything about real world string handling, you know that correctly reversing a string is impossible, because there just isn't any logical way to reverse some constructs. How do you reverse a strin…

That is a really good point and it complicates a lot of string-based questions, which is why they are almost always constrained (either implicitly or explicitly) by assuming that the string is ASCII only, which seems reasonable to me.

There are probably better filter questions to use that don't require as many artificial constraints.

Re: Why we don't hire programmers based on puzzles and tricks

#436

Post by rdouble » Sat, Feb 23, 2013, 8:16 PM UTC

suresk wrote: post #403

mmorett wrote: post #400

Earlier quoted context omitted.

It might be an incredibly common interview question, but it's not an incredibly common day-to-day task, particularly when there are methods built in to classes that perform this function. An interesting task? Perhaps. But not reflection of the dev's skills, per se. You're not asking about syntax with this. It's a problem solving question and at the end of the day, the only real metric here is not whether a dev could…

I don't see how reversing a string is a "puzzle" - I'd put its difficulty on par (or maybe slightly harder than) fizzbuzz. In most mainstream languages, it requires 2 pieces of knowledge: 1) That a string is implemented as an array of characters. 2) How to reverse an array. The implementation is straightforward and should be trivial for just about anyone who's done much development. I don't know that the question is…

Reversing a string was initially a good interview question because in C you can keep probing multiple levels of knowledge with it. You learn if the interviewee knows the algorithm, then if they understand how to do it in place with a pointer, then if they understand the XOR pointer trick. It's not a very interesting problem in a language like Ruby or Python.

Re: Why we don't hire programmers based on puzzles and tricks

#437

Post by donw » Sat, Feb 23, 2013, 8:29 PM UTC

brown9-2 wrote: post #116

donw wrote: post #80

Earlier quoted context omitted.

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…

It's a late reply, but sure.

The purpose of pairing in this context is not to see a meaningful contribution; rather, it's to see how the candidate interacts with a codebase he's never seen before, and developers he's never worked with before. Can they spot mistakes? Recognize patterns? Read and write code? Does the candidate know the ecosystem well enough to suggest methods or libraries?

Most importantly, pairing tells us whether or not the candidate can communicate effectively. Are they terrified to offer suggestions, or overly arrogant and controlling? Can they explain clearly? Do they clarify when the other half of the pair doesn't understand?

For example, many moons ago, I did some pairing with a candidate that gave me a suggestion on how I could make a section of my code both smaller and easier to read by combining a couple of iterators in an obvious way that I hadn't noticed. We ended up hiring that guy.

The getting-up-to-speed part happens as they pair, with a lot of explanation happening as they work on the system, and it's another important part of seeing how they work -- can the candidate understand new concepts quickly? Do they stop and ask questions when they don't understand?

This type of interview is a performance hit for that employee for the day, but this is fine, as I consider hiring to be very important, and losing a day or two of engineering time over the course of a month is a price I'm willing to pay -- keep in mind that the phone screens eliminate a lot of people.

Admittedly, I've never had a day when my guys didn't have work to do, but not all interviews involved the company codebase.

I make it a point to carve space out for my team to do miniature research projects, in a fashion similar to the way HP used to work, or Google's "20% time". These are timeboxed, and at the end, the result needs to be made available to the team; and yes, "this didn't work because of X and Y" is totally acceptable. This always pays off in terms of education, and every now and then you get something useful out of them, but they're also fair game for pairing during programming interviews.

Hopefully I've answered your questions.

Re: Why we don't hire programmers based on puzzles and tricks

#438

Post by pauldirac137 » Sat, Feb 23, 2013, 8:33 PM UTC

rhizome wrote: post #387

rizzom5000 wrote: post #384

Earlier quoted context omitted.

I think that most interviewers will happily give you the definition of strcmp if you don't already know it. If you're not a bad web developer, you'll happily come up with some code on a whiteboard that meets the definition. Anecdotally, perhaps, 95% of professional programmers don't know the definition of the words, "Lyskov Substitution Principle". That's not the same as not knowing what it is.

Two weeks ago I interviewed at a subsidiary of a major web property, and "[w]hat is the Lyskov Substitution Principle?" was on a written test they gave me.

I would have told them that I had no idea what that was, but then told them what the "Liskov Substitution Principle" (named after Barbara Liskov of MIT) was. I mean seriously, if a company can't spell, do you want to work there? :-)

Re: Why we don't hire programmers based on puzzles and tricks

#439

Post by donw » Sat, Feb 23, 2013, 8:35 PM UTC

pseut wrote: post #389

ry0ohki wrote: post #361

Earlier quoted context omitted.

My point is that having someone work a day for free would be great in any industry, but somehow only we in tech tolerate this, why is it different?

Having a random applicant "work" a day for free is a pretty crappy proposition in most industries; I suspect tech isn't much different. You gave an example of asking a job applicant for goldman sachs to "trade stocks for a day." Are you kidding? Do you realize how much money a bad applicant could lose in a day? If it's different in tech, it's only because it's (often) easy and painless to roll back an applicant's mis…

Exactly. An interview is work, on both sides of the table, and I see no point in distancing that work from what we actually expect the candidate to do once they get hired.

Puzzles, whiteboard coding, and so on don't tell me whether or not somebody can actually build software.

If the goal was to get free work, we wouldn't sacrifice staff time on the interviews. We'd give the applicant a challenging "homework" assignment and ask them to do it on their own time.

Re: Why we don't hire programmers based on puzzles and tricks

#440

Post by hvidgaard » Sat, Feb 23, 2013, 8:44 PM UTC

klibertp wrote: post #379

danielweber wrote: post #372

Earlier quoted context omitted.

The algorithm design is all said out loud. If I printed up a page of code and handed it to the candidate and said "make it better" I might expect them to work on style. So I don't mind answering questions during the interview process. The candidate might be nervous and I should be clear about my expectations. I don't like mind games like picking a fight and making sure the candidate responds the "right" way.[1] I wou…

"The algorithm design is all said out loud." Ok, I thought it was being written as a code, even if just on paper or a board. "accepted that faster was better" The point we - grey-area and I - are trying to make is that it's not always the case, or rather that the "betterness" of faster implementation is, in practice, dependent in large parts on other characteristics of the code. If someone deleted slower implementati…

http://www.jstor.org/discover/10.2307/2346806 was not something someone came up with after a few days at it. They had deep understanding of the statistics behind the algorithm, and an almost unfathomable knowledge in the domain, not to mention a large network to help them. I'm sure that most intelligent people would be able come up with it if they had the same circumstances working in their favor.