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.

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.

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.

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.

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.

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.

    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.

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.

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.

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.

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.

There exists a continuum of hiring practices which place more or less burden upon candidates. I would encourage HNers with input into their company hiring practices to choose less burdensome approaches over more burdensome approaches, particularly when less burdensome approaches also yield additional signal about ability.

A thing you can expect to be asked in 2016: you can expect to be asked to have an on-site interview in a city you do not live in. (How many people will be asked to do this for the SFBA or NYC? Literally jumbo jets full, this week.) For some candidates, this will involve more than 16 hours on planes, a (minimally) overnight stay in a business hotel, and six solid hours of interviews in the course of an 8~10 hour day. This requires minimally 2~3 days of these candidates' lives.

Most companies keep "conversion rate between onsites and job offers" very close to their vest. To put it mildly: it is not guaranteed that if you're flown out you will get an offer.

If you are hypothetically designing your interview process, and you replace the onsite with even an excessively long project, that's a win. The project can be written at the candidate's own pace and schedules conveniently around their other obligations. They do not have to arrange child care, take off time from work, or make tradeoffs like "Do I do the project or do I attend a friend's wedding?"

If you fly across an ocean and start bombing an interview, that's a terrible result for everyone. If you happen to be doing a project and discover "Oh, wait a minute, I've really miscalibrated here: this is far above my level of expertise with $FOO and honestly if this is the character of the work then I'm not sure I want to do it", then you have an easy option: simply close the window and, maybe, send a two-sentence email to the person who you were talking to.

Smart use of projects as a filtering mechanism can minimize costs to candidates and the company of administering high-cost testing (e.g. onsites, long projects, etc) to candidates who will ultimately not be successful at receiving offers and/or defer the high-cost assessments until the anticipated chance of receiving an offer is "very high."

..., and you replace the onsite with even an excessively long project, that's a win. The project can be written at the candidate's own pace and schedules conveniently around their other obligations. They do not have to arrange child care, take off time from work, or make tradeoffs like "Do I do the project or do I attend a friend's wedding?"

All true but my observation is that the companies that put candidates through multi-day-out-of-town interview processes can afford to miss out on the candidates that can't do it. Tellingly, the type of companies like Google and Microsoft that put a lot of burden on candidates hire heavily from a pipeline of fresh college graduates. Not surprisingly, a lot of 22-year olds don't have existing jobs or kids they have to juggle to commit to intensive interview processes. Sure, they also interview older middle-aged candidates but the benchmark tolerance for hoop-jumping is set by the 22-year olds therefore you won't get sympathy from employers about disrupting your life to stay in the running. For those companies, even if they are flying you out, you're still in the "evaluation" stage and could be 50/50 accept/reject.

Contrast that with boutique consulting firms that hire from the 30+ age bracket (often by poaching other consulting firms' employees.) A lot of their candidates already have existing (lucrative) jobs. Most of their evaluation is done on multiple phone interviews. If the company decides to fly you to their headquarters to interview, you basically have the job unless you unzip your pants and urinate on the interviewer's desk. The onsite interview is not a technical screening but a personality sanity check. At that stage, you're 90/10 accept/reject.

In one case I know, the interviewing + travel took two work days and two nights. That's thousands of dollars for a consultant! Add to that the grand or so of travel expenses for the company, interviewer time and overall, every senior hire costs applicants + company well over ten thousand dollars, past paying the recruiting team.

Compare that to a company that does the whole process over Hangouts/ScreenHero. The waste is amazing.

So basically they find a legal way to discriminate against older candidates?

All companies can afford to waste less money than they need too.

One company in Amsterdam, just last week, I went through a four step process, the last one being the onsite interview. I did really well in the first two, but then in third I went with a wrong approach to the problem and couldn't get my mind in the right position again. The person judging me just kept putting pressure. I got really nervous and couldn't do any more interviews that day... my mind really got completely blocked for the rest of the day.

That happens and, really, the company spent so much time of me (and me on them) for everything to be decided on that? feels wrong..

I'd say 8 hours is too long. I always strive for a 4 hours, but I've seen that 4 hours chop 16 hours off of the candidates time and more than 32 off of the companies.

> What's the point of maintaining an online portfolio and a github profile full of code

The vast, vast, vast majority of candidates do not have an online profile full of code. Either because their code is IP restricted or they do not have time outside of work to maintain that. I view using online profiles as a decided anti-pattern in hiring on the company side as it restricts your candidate pool to a tiny subset of the community that I've seen no evidence provides any more value in outcome and its much more prejudicial to the candidate population than any coding assignment can ever be.

It's not perfect, it'd be great if everyone could have a work sample but as you say that's just not the world we live in.

The reasons I don't like long coding assessment projects and the reasons I don't already have an example code profile are the same. Reinventing all the same wheels in different programming languages just isn't as fun for me as it once was, and I don't have as much time to dick around with any specific side project, especially ones that don't have any immediate utility to me or my family.

Does anyone ever ask about how I spec'd, designed, built, installed, and maintained my DIY entertainment center? No. Same methodology as building software, you know, except the problems are solved with different tools from a different toolbox.

If you're truly really looking for someone "T-shaped", you have to realize that the tittle on that T might include things entirely outside the realm of software or computer hardware, like how to hang a bear bag when camping, or how to fly a small single-engine aircraft, or how to train cats to use regular toilets, or how to run for political office, or what to do when you get a flat tire, or how to hold someone else's baby, or how to hit a gong target from 300m, or how to make a longbow for under $10 at Home Depot, or how to report a pothole so the city will fix it, or how to repair a pothole when the city won't do it, or how to play "Flight of the Bumblebee" while slowly rotating your B-flat concert tuba through 360 degrees.

All those miscellaneous, general-purpose skills do, in fact, make someone more effective at quite a lot of software-related tasks, sometimes in unexpected ways. But they are never going to appear on a resume, or crop up in the answers to any of the stock interview questions. When you include a criterion that specifically selects for people whose after-work hobbies also involve software, you are implicitly selecting against those who do other things, because there is much, much more to life than writing code.

There was only a very narrow slice of time when I actually wrote code for fun in my free time, from the ages of 15-25. It basically stopped after I got laid off from my first software job, and interviewing for software jobs became my next full time job. That's when I realized that I needed to do other things in my life, because it didn't matter how much I loved software if it didn't love me back.

So if you think need a portfolio to get a job, you might want to build one up that includes more than just code samples. The software industry does not love you back. It will move on to someone younger when it gets bored of you.

Systems, problem solving, engineering. Happens everywhere not just on a computer screen.

Otherwise I agree with what you said, and the best way to tease those details out of a candidate is to have an informal, personal discussion like getting lunch or getting beers together. But that's not enterprise scale.

The difference is that we do this as paid work. Whatever their going rate is, we'll match it.

A surprisingly high number of candidates interview quite well and look promising on paper, but fail horribly in a "real world" coding test.

What company are you talking about hiring for? I'm looking for work as a programmer, and I'd prefer to apply to places with a hiring process like this. You can find some code I've written (a server clone for www.stockfighter.io/) at https://github.com/bcoburn3/forex

My email is [email protected] if you'd prefer to respond that way

To do both is wasteful, but if I did either and that _didn't result in a conversation about code_, I wouldn't continue with the interview process. Their processes are broken.

That depends heavily on what they're actually screening for. I've received an embarrassing number of utterly atrocious code challenges from candidates in the past. If you can't code something like a roman numeral generator/reader (when allowed to do so at home, in whatever language you want, spending as long as you want on it) then continuing the interview process at this point is a huge waste of time.

In those processes, the purpose was to weed out people that simply could not code at all. Or even cheat, since there are solutions all over the internet for any language you want.

A later stage was to do some programming with us, and we'd talk through issues and see how they dealt with problems/etc.

I imagine though that if you explicitly call it a weed out that a sizable percentage of the quality talent pool won't apply...unless they're a referral, and then why are they doing a code challenge anyway?

On that note: giving code challenges to employee referrals, especially hiring to their own teams, is a clear indicator that you don't trust your employees.

> My time and contributions will not be appropriately valued by such a company and I won't like working there

I don't get how that's related.

> I don't want to start out a hopefully multi-year relationship on dishonesty.

There's no dishonesty there, the applicants were given a simple task to do in order to progress to the next step. If you're applying for a software engineer position and cannot even make a decent attempt at an extremely simple task when given complete flexibility then it's a waste of both of our time to continue.

(edit - I should point out that this was not at my current employer)

As developers, we often take a 5+ hour whiteboard interview on some of the fundamentals of CS, but presented as challenging problems. We may also have to do a take-home "project" which can be viewed as a "practical" component of a comprehensive.

I don't object to this per se. What I dislike about it (as I've mentioned on HN before) is that we take these exams without the protocols that evolved over centuries in exam-heavy institutions (universities, professions) to safeguard against abuse ensure the process is fair and decent to the people taking the exams.

The exam must not be capricious, it must be relevant and consistent across candidates, it must be created and assessed by competent members of the profession, there must be an associated study path, the content of the exam should't be a huge surprise to the candidate, candidates are provided with feedback should they fail.

And, perhaps most importantly, the process of taking and passing the exam provides the candidate with a certain stature, a lasting credential that is widely respected in the profession. The candidate doesn't have to re-take this exam over and over every time he or she interviews (in many ways, that is the point of the exam).

In many ways, I feel that programmers experience the downsides of this sort of professional entrance exam but without the positives.

I'm glad to see this discussed on HN, because I really do think that software "interviewing" as entrance-exam is one of the things that eventually drives people out of the field (or causes them never enter it in the first place). It's not a good thing for our field.

I'm not saying it's an easy question with an easy answer, just that our current approach is failing.

It seems pretty simple to me, if you consider the entire protocol as what it is: a negotiation, with one side asserting their dominant position.

Please excuse me hn for beating this horse to death, but for God's sake, Programmers of the World, Organize.

A surprising amount of people don't maintain a very impressive public profile (me included, tbh). These people need the opportunity to showcase their skills and the only way to do so is by spending some time coding a nice solution.

We try to minimize the candidate's overhead by providing general guidance in the challenges we issue (like "please demonstrate the SOLID principles").

Then we do a code review on the solution, in which we also spend some time. We point out issues, suggest possible improvements and give props on stuff we consider well done. At the end, if the candidate doesn't progress they at least learned something useful. We hope that this way our recruitment process might always be worth the time.

You're on the phone with them, you can ask them if they'd prefer a little challenge to showcase their skills, or whether they'd like to provide a portfolio example instead.

Maybe a bright self-taught college student switching tracks into software would pick #1, a parent switching jobs would pick #2.

"We ask that you provide:

1) an implementation of this sample project (estimated 8 hours time).

2) a work sample that meets the following criteria (same criteria we are looking for in the sample project)"

More generally, I think the target should be to make the work sample test take a similar amount of time to the in person interview you'd have to do instead.

That's just shabby and disrespectful, regardless of how many other candidates they're talking to, or how they evaluated this particular candidate.

However I really liked the Thoughtworks challenges and couldn't resist coding for eight hours. It's better than spending one hour on-site for a badly designed 'challenge'.

The way a company signals their respect for my time is by either compensating me for the time I spent on them instead of literally anything else, or by demonstrating that they are spending an equivalent amount of time on me rather than anything else.

If I am doing a project that takes me 8 hours, that company should either be writing me a check (for somewhere between $100 and $500, probably) or planning the mother of all individual sales pitches to convince me to not just work there, but also to go the entire distance through their interview process.

No company has ever done this for me. Every last one of them has expected the candidates to spend as much of their own time (and even money) as necessary. Several (all of them in Denver, possibly by coincidence) have even reneged on paying travel expenses. Tyler Tech in Lakewood, CO, tried to get out of paying for my hotel room, declined to spring for a rental car, and remains to this day the most hostile interview I have ever suffered through.

They also had me drive my own car from Madison to Milwaukee, to catch a flight that actually stopped in Madison after the first leg, just so they could save a few bucks on the airfare. And then they refused to pay for the mileage between Madison and Milwaukee, after promising earlier to reimburse all my travel expenses.

I put up with an awful lot of inconvenience from interviewers without comment, but every little slight is ratcheting up the minimum acceptable offer from that company. And if you act like sleazebags at the interview, you had best be prepared to lose any candidates with an ear to the grapevine.

I could be wrong, though.

It also opens the hiring company to potential liability with regards to IP laws if you are hiring in a similar industry.

Every time this has come up, the company would not pay that rate, and offered something more like $20/hr.

It is just insane to me that if you are interviewing me for a position which makes $105,000 a year and cannot offer even close to equivalent compensation for the interview.

I thought work might have dried up. But I got a call the next day from somebody who had dug up my number in an old rolodex, desperate to get me to pick up the slack on a project. So, right back in the saddle!

That works better if you have 10 or 20 years of experience at different places. So there are people out there thinking of you.

He is saying that even though he was working long hours at his current job, he was so enticed by this interview challenge that, even after a long and difficult day thinking about a (programming) problem, he couldn't keep it off of his mind on his train ride home.

> What's the point of maintaining an online portfolio and a github profile full of code if companies prefer to waste your time writing a pointless uploader?

There are a few problems with using GitHub or BitBucket profiles. First, not everybody has them, or they don't update them frequently, or whatever. Second, it's pretty easy to fake a GitHub profile by copy/pasting code from other places, using other people's code, or pushing broken stuff that doesn't really work. And third, a lot of people's GitHub profiles are cluttered up with a bunch of forked repos that they haven't even pushed code to and don't really contribute to at all.

I'm not at all worried about 8 "unpaid" hours.

It's better than a 5 minute brain teaser question. Any job worth having is worth spending 8 hours applying for. Anyone who views this as "free work" probably won't be a good hire for other reasons.