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

#371

Post by mturmon » Sat, Feb 23, 2013, 1:46 AM UTC

achompas wrote: post #294

mturmon wrote: post #291

Earlier quoted context omitted.

It is a source coding problem. Kind of like a Huffman code. Depending on how theoretical or applied your information theory coursework was, you might have worked out simple codes like these in class, and that might be an advantage. It's actually very similar to your tree reasoning above. The information theoretic outlook uses the probabilities of each of the N states to make a more efficient code, but since there are…

Thanks! Haven't taken a formal information theory class yet, but I'd like to soon.

If you are mathematically inclined and good with probability, it could be a lot of fun.

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

#372

Post by danielweber » Sat, Feb 23, 2013, 1:48 AM UTC

klibertp wrote: post #364

grey-area wrote: post #351

Earlier quoted context omitted.

Ok, I think that clarifies your intent, the question is purely hypothetical (many records, infinite resources) and designed to elicit the platonic algorithm given no constraints save time. You surely recognise though that 'improving' depends on the constraints which were not given? I find it curious that you characterise questions attempting to relate your problem to real world constraints as 'a sea of bullshit' :) S…

I think this - I mean the "meaning of better" being obvious or not - is a major difference between most of industry and academia. In academia code readability matters less, it's asymptotic performance matters more and constants can be safely ignored. Reimplementations of things tend to be rewarded, because it shows the student's understanding. It's completely different in the "real world". And this is why looking at…

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 would hold no points against them for asking on clarification for what "better" means, as long as I didn't they they were trying to be difficult and accepted that faster was better.

I'm sorry if you don't think I would hire you. Maybe I wouldn't, but that doesn't mean you aren't a good coder. But I also think you shouldn't be intimidated by "algorithm invention." You probably do this a bunch already. In the order you write your code you are probably already doing implicit algorithm invention. I think you can write the code to figure out the biggest number in a list if you sit down to do it, and once you do that finding the second biggest just involves keeping track of one more thing and doing one more test on each pass through.

Often the question is figuring out what data structure you should be using.

Oh, I don't actually expect anyone to give me the perfect answer of how to find the nth-biggest element in the list. In fact, if a candidate did give the perfect answer, I would say "this person is more qualified than me, please hire." I'm not capable myself of giving the perfect answer even though I've thought about it a few times and it's essentially a question I've practiced.

[1] See question 7 at http://www.joelonsoftware.com/articles/fog0000000073.html

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

#373

Post by freework » Sat, Feb 23, 2013, 1:51 AM UTC

robomartin wrote: post #352

cletus wrote: post #44

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…

I get it. That said, isn't there concern about candidates just cramming on the top 100 programming puzzles just to be able to ace such interviews? I take a bit of a different approach. I want to know how they think. Pose a problem and collaboratively work through it on a white board. No code. Just state diagrams, flow charts, whatever. Not looking for a solution. Looking for the thought process. Then put up a piece o…

"Not looking for a solution. Looking for the thought process."

This is the part I can't understand. When the person is on the job, the opposite is in effect. If you tell the candidate to solve a hard problem, you don't wan them to just spit out their thought process, do you? No, you want them to solve the problem. Why the opposite for interviews?

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

#374

Post by suresk » Sat, Feb 23, 2013, 2:09 AM UTC

freework wrote: post #373

robomartin wrote: post #352

Earlier quoted context omitted.

I get it. That said, isn't there concern about candidates just cramming on the top 100 programming puzzles just to be able to ace such interviews? I take a bit of a different approach. I want to know how they think. Pose a problem and collaboratively work through it on a white board. No code. Just state diagrams, flow charts, whatever. Not looking for a solution. Looking for the thought process. Then put up a piece o…

"Not looking for a solution. Looking for the thought process." This is the part I can't understand. When the person is on the job, the opposite is in effect. If you tell the candidate to solve a hard problem, you don't wan them to just spit out their thought process, do you? No, you want them to solve the problem. Why the opposite for interviews?

If I'm an employer and you are working for me, I am asking you to solve a problem because there is some value in the result.

If I'm interviewing you, chances are, the result has no intrinsic value - I already (hopefully) know it. What I want to know is "Can you solve other similarly difficult problems?" In this context, being able to come up with a solution to the problem isn't as useful in answering that as knowing how you solved it.

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

#375

Post by rhizome » Sat, Feb 23, 2013, 2:39 AM UTC

hackinthebochs wrote: post #210

pekk wrote: post #174

Earlier quoted context omitted.

It isn't that people are insecure about their programming skill and intelligence. It's that they are irritated by tests which don't measure what they're supposed to. If any insecurity is involved, it's about ability to ace unrepresentative tests ranging from trivial nonsense to outright hazing. You advise readers to "just get better at [the tests]". That's practical. But it goes right back to the problem, that many o…

> It's that they are irritated by tests which don't measure what they're supposed to I disagree that programming puzzles don't measure what they're supposed to. Programming puzzles are a microcosm of what programming entails day-to-day. They test the same exact mental faculties. Sure, no one needs to write strcmp using primitives anymore, but the task of doing so exercises the same mental processes that are involved…

Sure, no one needs to write strcmp using primitives anymore, but the task of doing so exercises the same mental processes that are involved in orchestrating the various components when handling a web request.

I don't know what strcmp is in the way that you're using it. Does that make me a bad web developer?

Something orthogonal to this came up recently on Reddit, and it was observed that in the real world (anecdotally), 95% of professional programmers don't know what the Lyskov Substitution Principle is.

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

#376

Post by rhizome » Sat, Feb 23, 2013, 2:45 AM UTC

redditmigrant wrote: post #236

brown9-2 wrote: post #116

Earlier quoted context omitted.

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…

I havent done pairing interviews but I have tried giving candidates some started code and having them develop a solution based on that. One piece of logistical advice here: keep different kinds of keyboards/IDEs available. I use a mac and I interviewed a candidate who wasnt comfortable with the mac keyboard. In an interview situation where a person is already slightly nervous the last thing you want is for them to be…

I think a half-done chunk of example code to be finished is a great technique.

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

#377

Post by altoz » Sat, Feb 23, 2013, 2:59 AM UTC

derefr wrote: post #237

hackinthebochs wrote: post #219

Earlier quoted context omitted.

> a programming puzzle is the intersection of a work-sample test with one question from an IQ test In the worst case this is true. But ideally the question will have various components, and various levels of difficulty. I'm reminded of a blog posted here some time ago that had the candidate split a string based on a provided dictionary of words (or something to that effect). The best candidates produced maximally eff…

That still doesn't help the candidates who just don't see the trick. What if you know memoization and dynamic programming, but it just doesn't occur to you that day, that to correctly split on spaces (not adding empty tokens at the beginning and end of the string, etc.) you need to use a state machine? You could give the candidate that "step" of the solution and continue on to see if they know the rest, but the candi…

The "loss of confidence" part, I don't see why that shouldn't be taken into account. If a candidate can't recover from failing, they're not likely going to do the same when they fail in their job. It also may indicate that the candidate is not teachable if they can't understand or have a hard time with your hint. Hints are a good way to progress an interview.

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

#378

Post by pifflesnort » Sat, Feb 23, 2013, 3:04 AM UTC

badgar wrote: post #365

seanc722 wrote: post #310

Earlier quoted context omitted.

Agree. I have enormous social anxiety that completely wipes out my thought process... But give me a project to do with a due date (ex a school project due in 2 days) and the stress from that actually motivates me to get it done and does not mash my brain up like the stress of being in a social situation like a interview.

Work is social. What do you when a couple teammates walk up to your desk out of nowhere, abruptly interrupt your coding zone, and ask you why the build broke when you changed the FoobarService to return X instead of Y when Z? They can't release the latest features until it's fixed! What you were doing isn't important anymore, you're holding up everything! If you want to work for a web services company: what are you g…

> What do you when a couple teammates walk up to your desk out of nowhere, abruptly interrupt your coding zone, and ask you why the build broke when you changed the FoobarService to return X instead of Y when Z? They can't release the latest features until it's fixed! What you were doing isn't important anymore, you're holding up everything!

This should have been caught before it was an emergency, through standard processes such as integration and unit testing.

> ... you're oncall, and angry users, coworkers or your manager start asking you what's wrong?

If your coworkers and managers are angry during an outage, or asking anything other than "what can I do to help", they're not helping.

> Sometimes the co-workers involved aren't gentle about things in the heat of the moment ...

Those coworkers need to be instructed in proper workplace behavior.

The time to be critical about work is before an emergency occurs. Institute policies to ensure code quality and IT robustness, define roll-back plans to be enacted in case of failure, and supply other policies, procedures, and evaluation criteria necessary to steer your employees to ensure that the chance of success is maximized (and the chance of outage is minimized).

When (not if) the shit hits the fan, you -- and all your employees -- are prepared for it. If a nervous manager is still checking in every 2 minutes instead of asking how they can help, it's your job to MAKE THEM STOP.

This strategy is how you prevent most failures, and make the ones that happen manageable. Your strategy is how you create failures, and then make them worse for everyone involved when they happen.

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

#379

Post by klibertp » Sat, Feb 23, 2013, 3:21 AM UTC

danielweber wrote: post #372

klibertp wrote: post #364

Earlier quoted context omitted.

I think this - I mean the "meaning of better" being obvious or not - is a major difference between most of industry and academia. In academia code readability matters less, it's asymptotic performance matters more and constants can be safely ignored. Reimplementations of things tend to be rewarded, because it shows the student's understanding. It's completely different in the "real world". And this is why looking at…

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 implementation along with tests and docs and replaced it with faster, but undocumented, untested implementation I would not consider it a change for the better.

And I think you would agree with this in general (of course there are situations when a change like this is necessary!), and I think this is just a misunderstanding on my part - I was thinking about actual code, an implementation, all along while you were talking about description of the algorithm with words. In this case - with one additional assumption that memory complexity is irrelevant or not changed, but that's nitpicking - of course faster is better! :)

"I think you can write the code to figure out the biggest number in a list"

Yes, of course: (foldl max (first lst) (rest lst))

And I can even explain what foldl is and how it works.

"you shouldn't be intimidated by "algorithm invention.""

I am not "intimidated". I know my limits. I wouldn't be able to invent quicksort during the interview and I wouldn' be able to invent this: http://www.jstor.org/discover/10.2307/2346806 even if my life depended on this and I was given all the time of universe to do this (but I still coded it).

This also depends on what we mean by "inventing". Does using some previously learned technique or adjusting other already known algorithm count as an invention?

But from what you say I gather that you wouldn't want me to invent quicksort on the spot - and then it's ok, it seems like I still have a chance of getting a job! ;)

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

#380

Post by tatsuke95 » Sat, Feb 23, 2013, 3:29 AM UTC

crazygringo wrote: post #355

dyno12345 wrote: post #334

Earlier quoted context omitted.

Yes, but during a trial period don't you get paid?

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.