[philbarr]

I got laid off recently and was applying for all the jobs I could find. So I had to do a bunch of these programming projects. I don't mind them per-se, but it takes so long to do each one and you have to be ultra-clean with each one. I don't think companies take into account that you might not have that much free time. It's particularly stressful when you don't get through.

On pair programming tasks, I had a pair programming session with a guy, he gave me an empty project and a poorly specified brief, verbally, then gave me 15 minutes to crank something out. It was pathetic. I didn't get the job and the feedback was, "he didn't know some of the keyboard shortcuts I'd expect." In hindsight, I'm glad I didn't get that one but at the time things were getting desperate.

The best process was the one where I finally got a job. We talked on the phone for an hour and a half and by the end you could just tell we had that, "developer bond". His approach was the best I'd seen. He just talked through some of the problems he had, I proposed solutions and we talked through pros and cons. He treated me as an equal from the start. After that we had the face-to-face HR questions (how do you resolve conflict, etc.) which they have to ask because it's a big company, and another one with another manager but by then it was pretty much a done deal.

And I think that's the way to do a decent hiring process. Don't behave like an authoritative dick, and use phone interviews to screen candidates. Programming projects don't work because it's going to take you forever to review them, and pair-programming doesn't work because there's not enough time, and it's kind of horrible for the candidate.

[busterarm]

Wholehearted agreement here. The only purpose of these challenges is to start a conversation about code. Why not just bypass the bullshit challenges and just _have a conversation about code_?

My best job experiences are exactly as you describe.

The worst have been companies that sought me out (I didn't apply) and then wasted my time during the phone screen (having background conversations with other people in the room, asking me to repeat answers to questions because they weren't listening)...I'm looking at you, Uber.

[ironchef]

"Why not just bypass the bullshit challenges and just _have a conversation about code_?" Because talking and doing can be different? _Do_ they actually write test cases? Do they write documentation? Do they make output machine parseable? etc. I want to see what work product looks like even if the work product is simple. (which is also why the homework I assign is nothing ridiculous like 8 hours nor do I timebox it)

[busterarm]

Talk about that stuff. People sometimes spend extra time polishing a code challenge than they do in their day-to-day. People can lie to you in code just like they can in conversation.

Sure, you know that their ability to do it is there, but you still don't know that they will and you still don't know that if they didn't they could learn. You can get that information from having the right conversation.

What testing tools do you use? What's your approach to testing? What pitfalls have you run into with testing? What projects have the best and worst documentation that you've used. How does this affect the work you do? How do you make your code usable to others? What's your opinion about input and output of functions? Separation of concerns, etc?

Or the best question of all: What books about programming have you read and liked and why?

You can't stare at somebody's code and know if you'll like working with them. More importantly, weedout challenges are a solution for the wrong problem. If you're worried about wasting your time bringing in the wrong people to interview, maybe focus on getting better indicators on the kinds of people that you (want to) bring in.

[collyw]

"People sometimes spend extra time polishing a code challenge than they do in their day-to-day. "

Maybe thats because they are under resourced in their day to day, and don't get a chance to do things nicely despite complaining to management about it constantly.

[busterarm]

A lot of people have the "get it done so I can get out the door" mentality and cut corners which they obviously wouldn't/shouldn't do during their interview process.

Though them not doing it and spending the energy to "complain to management constantly" might be a problem too. I'm sure we're all familiar with terrible management practices, but some people are complainers and some people are pushovers and you don't want either (or at least you don't want to bias your team towards one or the other).

Being able to calmly explain a process problem and demonstrate why is a critical skill. If you're in a company where that's a waste of time, don't complain, just leave. If you can't fix or guide people, your code still won't get shit done.

I think a lot of people, ourselves included, think that we're in the business of writing code, but this is actually a mistake. We're doing business Operations, yes, with the capital-O. The only difference is that our tools to get the job done are "our software, our people and other people's software" instead of just "our people and other peoples' software".

Developer is the right title for us most of the time.

[ironchef]

"You can't stare at somebody's code and know if you'll like working with them." Sure...and there's not mutual exclusion between the two. Looking at someone's work product is simply another set of data points. I'm not judging someone's fit for a position simply based on a code work product. Or a resume. Or one cultural fit question. I'm using them all to paint a picture and weighing the pieces to determine if I think this person will perform well under the complete circumstances (work/life balance, work required, what team they're on, etc.) Simply put, I've found several different kinds of work products have helped determine positive fit in the past for me.

[markbnj]

>> The best process was the one where I finally got a job. We talked on the phone for an hour and a half and by the end you could just tell we had that, "developer bond". His approach was the best I'd seen. He just talked through some of the problems he had, I proposed solutions and we talked through pros and cons. He treated me as an equal from the start. After that we had the face-to-face HR questions (how do you resolve conflict, etc.) which they have to ask because it's a big company, and another one with another manager but by then it was pretty much a done deal.

I've had the same experience, and I absolutely agree. Just about all my best interviews were with someone where we just hit it off and talked deep tech for an hour. On most of these we had to consciously cut the conversation off because we went long. I don't think that, when this sort of interaction occurs, you know the person is going to be good at writing production code. But at least you do know they're the "sort" of person you would expect to be good at it, and frankly none of the other methods discussed do a better job at providing that assurance.

[troels]

    I don't think that, when this sort of interaction occurs, you know the person is going to be good at writing production code. But at least you do know they're the "sort" of person you would expect to be good at it, and frankly none of the other methods discussed do a better job at providing that assurance.

I some times feel that part of the problem with hiring is that people expect too much of an interview process. Whatever tricks you pull to test out people, there's only so much that you can actually learn about people through a few hours of interaction, in a contrived context. Talking tech with developer candidates is great because a) it puts you in a natural conversation, which affords you to get some idea whether you like the person or not and b) it reveals at least something about their technical skill - it's hard to fake deep knowledge, if you don't have it.

[rbritton]

I'm actually in the hiring process at a place currently, and their process is reasonable for someone in my position coming from freelance:

1. Phone screen amounting to about 45 minutes.

2. Skype interview with small code samples between two interviewers at 45 minutes each.

3. 2-week paid trial doing real work.

I had #2 yesterday and am currently waiting to hear back from them about moving onward.

[Lawtonfogle]

>3. 2-week paid trial doing real work.

That could work for those without a job, but if I'm securely in a job, if I'm going to be switching to a 2 week contract, there needs to be a significant bonus attached.

[ctdonath]

It's #3 that makes all the difference: a task that means something, and makes it worth one's while.

Duolingo wanted a functioning nontrivial (albeit sparse) app, expected to take 10 hours to write. I found it amusing on its own, but interviewed & got multiple offers elsewhere in less time.

[ThrustVectoring]

That's actually harmful for getting quality candidates - "hot" prospects nope out of the process when they get an offer elsewhere.

A clever option is emailing the recruiter at Duolingo with something like "hey, I've got a competing offer, so the 10 hour coding challenge is really not something I have time for at the moment. Is there any other way to proceed through the hiring process?" Either way they answer, you're okay with.

[devonkim]

I did that before during an interview with a pretty good company overall and the employer refused to accelerate the process or make an exception and just stopped the process.

[ctrlalt_g]

Good luck!