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

#421

Post by doktrin » Sat, Feb 23, 2013, 11:54 AM UTC

nitrogen wrote: post #401

doktrin wrote: post #342

Earlier quoted context omitted.

This is highly unusual (if not unheard of). A company would have to be pretty damn unique in order to justify having candidates pay for their own travel + lodging.

Most jobs are not provided by SV companies or Microsoft. Most prople are not in a career that typically hires from across the country at their own expense. Paid travel is a luxury enjoyed by a small segment of job candidates.

Expanding the scope of discussion to all jobs is disingenuous. It's pretty clear this thread (not to mention this forum) is fairly software centric.

Regardless, companies across just about all industries that hire from remote talent pools will pay for travel (consulting, finance, government, NGOs, banking, accounting, manufacturing, insurance, you-name-it).

Whether or not a given company expands its talent search to include workers in distant locations is bound by several factors, none of which are unique to "SV and Microsoft".

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

#422

Post by pi18n » Sat, Feb 23, 2013, 12:54 PM UTC

jasonshen wrote: post #235

ben1040 wrote: post #137

Earlier quoted context omitted.

>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. Yep. That basically amounts to an application fee.

If you think it costs you something to be interviewed (thus your suggestion about an application fee) it certainly costs the company at least that much if not more. They are paying their staff to work with you on something that likely will not produce direct value for the company (usually a throwaway project or trivial task) Plus they will spend time before and after the interview discussing your qualifications, perf…

The company is expected to have costs when hiring, it isn't appropriate to push them onto the applicants by having them work it off.

What if a company gave you an itemized bill after your interview? You're still exchanging something of value for their time; is that reasonable or ridiculous?

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

#423

Post by mseebach » Sat, Feb 23, 2013, 1:18 PM UTC

mmorett wrote: post #411

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…

Fair enough. Here's my solution: def reverse() { def a = "Can a fella get a job?" StringBuilder b = new StringBuilder() for (int i = a.length(); i > 0; i--) { b.append(a.charAt(i-1)) } print b.toString() } But it doesn't use arrays because quite frankly, I haven't used an array in years. I despise the noise of the brackets. :-) Seriously, I use ArrayLists instead of arrays. But even on this FizzBuzz lite exercise, I…

Your solution is fine, you've passed, flying colours. I might poke a bit around the edges to see if I can get you to say the word "array", but mostly out of interest.

The important bit is that this is not an assessment of your ability as a programmer, it's a negative filter: Are you one of these people who simply can't program, because if you can't, let's not waste any more of each others time.

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

#424

Post by maigret » Sat, Feb 23, 2013, 1:27 PM UTC

papsosouid wrote: post #178

maigret wrote: post #164

Kent Beck tweeted a very fitting comment: 'Programming contest problems shouldn't be algorithms, they should be like "set up continuous deployment of a multi-region Django app on AWS"' https://twitter.com/KentBeck/status/299528659746840576

Why should programming contest problems be tests of practical sysadmin skills? That makes no sense at all.

Because this is much more than sysadmin skills involved. You've got to get a scalable application written first. It doesn't need to be complicated, but it needs to be robust and keep data consistent... etc.

Also, this type of skills is badly missing to fresh grads.

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

#425

Post by alan_cx » Sat, Feb 23, 2013, 2:02 PM UTC

Not employed people for years, but I never put much value on ultimate skills. I used to think long term. So, give me the the right human being, with a reasonable level of knowledge, and very quickly they will be more than good enough. A little more time and for me, they become pretty much perfect.

I want the right personality. The ultimate skills will follow. So, I just chat to candidates and employ those who I feel I and my people can work with. I never left it so late that we needed instant skills. To me that would be poor management.

Prior to that, I have tested and done many of the things people cite here, but most of the time I got awful employees who turned out to be good at doing interviews.

Yeah, a bit hippy dippy, but it worked for me.

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

#426

Post by pifflesnort » Sat, Feb 23, 2013, 2:52 PM UTC

badgar wrote: post #393

pifflesnort wrote: post #378

Earlier quoted context omitted.

> 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 pr…

> This should have been caught before it was an emergency, through standard processes such as integration and unit testing. Things always go wrong in the development cycle. Problems happen. Conflicts between individuals occur. I was giving an example. Are you asserting these issues don't arise in the workplace? Or that my example is of a rare situation in software development? > If your coworkers and managers are ang…

Your examples are all cases where someone creates social stress by reacting poorly to avoidable, stressful situations.

Your goal seems to be to hire people that will put up with these avoidable stresses.

My goal is to build an mature workplace where we avoid creating unnecessary social stresses by applying collective wisdom and experience to plan ahead.

This is one of the many difference between engineering and hacking.

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

#427

Post by trotsky » Sat, Feb 23, 2013, 5:28 PM UTC

badgar wrote: post #413

trotsky wrote: post #396

Earlier quoted context omitted.

You're just lumping two different things together. Everyone has performance anxiety at times - whether rare, mild, common, or occasionally overwhelming it's something everyone deals with. Something like public speaking to a room of strangers or flirting with a super model really doesn't share many physiological triggers with diagnosing code you wrote while people you're friends with look on anxiously. Assuming that b…

> solve programming puzzles Your argument all comes down to dismissing the content of the interview. Since you clearly assume the interview is worthless, you aren't even discussing this in good faith, so I'm just ignoring this post.

It didn't at all. It carefully explained why the two activities produced entirely different chemical reactions in the brain. If you're too invested in your process to even consider that a test of one thing may not translate into the performance on a totally different task then perhaps you're taking this all a bit too personally.

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

#428

Post by 31reasons » Sat, Feb 23, 2013, 6:04 PM UTC

trotsky wrote: post #202

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…

One thing you're testing for is how well their brain works with an excess of adrenaline floating around in their body. All of the best interviewers I've known take great pains to make the interviewer feel comfortable and chatty - after all, they aren't going to be filled with interview anxiety when they're actually working there. A minority of your applicants are going to perform badly in that situation because the a…

As a company you should always advertise if you want your employees to work under a lot of stress. I would for one never choose to work for such groups.

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

#429

Post by jameshart » Sat, Feb 23, 2013, 7:08 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…

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 string which contains bidirectional control characters? What is the reverse of an optional line-breaking hyphen? Even simple things like parentheses might trip you up.

Once you really start thinking about reversing a string, you realise why it's so difficult to do robustly: because there is actually no logical reason to reverse a string.

As an interview question, I would only credit an interviewee for this question if they basically objected to the requirement in the first place, and explained how bad an idea it was - but since I wouldn't expect most interviewees to do that it would be a poor test to introduce in the interview.

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

#430

Post by mmorett » Sat, Feb 23, 2013, 7:09 PM UTC

mseebach wrote: post #423

mmorett wrote: post #411

Earlier quoted context omitted.

Fair enough. Here's my solution: def reverse() { def a = "Can a fella get a job?" StringBuilder b = new StringBuilder() for (int i = a.length(); i > 0; i--) { b.append(a.charAt(i-1)) } print b.toString() } But it doesn't use arrays because quite frankly, I haven't used an array in years. I despise the noise of the brackets. :-) Seriously, I use ArrayLists instead of arrays. But even on this FizzBuzz lite exercise, I…

Your solution is fine, you've passed, flying colours. I might poke a bit around the edges to see if I can get you to say the word "array", but mostly out of interest. The important bit is that this is not an assessment of your ability as a programmer, it's a negative filter: Are you one of these people who simply can't program, because if you can't, let's not waste any more of each others time.

Arrays. (Uhhg...I said it but I feel dirty.) ;-~

I've never liked arrays due to the brackets. But in a twist of irony, I now spend all day in Groovy and I use maps, thus brackets all the time. Yet I don't even notice.

So after carefully thinking about it, I now realize its not the brackets. I can't explain it. There's something about arrays I just despise despite having no similar ill will towards ArrayLists. They just feel so 70s.