Hacker News Reader

Comment by Tunabrain | Hacker News Reader

> As brain-dead as I was after eight hours at my project, [..]

Is giving out an 8+ hour programming project as part of the application process really considered good hiring practice? If you apply to five jobs, you're expected to spend an entire unpaid work week writing code that doesn't benefit anyone? If a company receives 20 applicants, their ideal candidate selection wastes a collective work month?

I don't really understand this ideal. 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?

View on HN

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.

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.

"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)

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.

"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.

"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.

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.

>> 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.

    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.

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.

Good luck!

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.

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.

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.

>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.

(Speaking in personal capacity here.)

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."

Perfect, I've done +-4 onsite interviews and only got accepted in one of them. I get really nervous in on site interviews being judged by usually two people at the same time while I try to solve something.

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..

>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.
... To put it mildly: it is not guaranteed that if you're flown out you will get an offer.

..., 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.

> 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.

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

When many valley companies look for senior people (and they do), they still use the same mechanisms to hire those 30 somethings out of consulting firms. And that's when they have a 1/4 on site to offer ratio(es, that's an actual ratio of senior engineers that pass the phone screening.

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.

>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.

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

Any process will fit some candidates better than others.

If I had some process that fit male candidates far better than female candidates, with no clear benefit compared to other processes that had less of a biased fit, would that be a problem?

We all get old. Its actually pretty fair.

> Is giving out an 8+ hour programming project as part of the application process really considered good hiring practice?

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.

We ask candidates to pick a work sample of something they already have, if they have one they can provide. If they don't we give them a relatively painless coding test instead.

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.

I appreciate this approach. I'd love to be more active with outside-of-work projects, but my days are usually already full. And I can't provide a lot of code samples because the majority of my work is IP.

This is true for most good people at big companies. Your day is already 60 hours long, and your company forbids (via IP ownership) coding outside of work. I fear that most of the interview approaches pointed out in this thread select against people who are already successful at well-regarded companies. Don't you want people like this in your interview funnel?

You'd be surprised. There are an increasing number of folks who get to at least occasionally work on open source projects as part of their day job, and many other less obvious ways of getting a prior sample. But if they don't have one we don't hold it against them for the reasons you cite

Exactly. Furthermore my experience has been that requiring prior work samples unfairly biases towards younger developers. Our system is far from perfect but it allows us to see prior work where possible by provide a fallback when it isn't

I was one of this vast majority once, so I know how it feels. Eventually though however slowly, but I've gathered enough code samples on my github account, samples that are actually rather unique and at the same time useful and getting starred. It takes time, polishing, sure, but as a result quite a few companies stopped asking me doing coding tasks, so I'd say in the end it's worth it.

I built something specifically for that purpose, but people still seem to want me to do pointless coding tests.

Exactly. My after-work profile consists mainly of my non-driving kids getting to their non-school activities on time, the custom-built furniture in my living room, the lawn calibrated to give the HOA conniptions without actually breaking any covenants, the brake fluid level in my 2001 car that is definitely leaking it very slowly, my almost-completed low fantasy novel that I started for NaNoWriMo in 2012, DIY pajamas that my kids wear, a well-socialized terrapin, and yes, even all my online gamer achievements.

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.

Seriously considering putting a write up of how I repiped the natural gas lines in our house. One inch pipe to the utility room, valves on all tees and a stub for the meter so I could pressure test the whole house by zones at the first tee after the meter.

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

So what did the code inspector have to say about your DIY work?

Leaky brake hydraulics aren't anything to mess with, you should fix it or have it fixed soon. It could be something (relatively) harmless like a common hydraulic system shared between the clutch and the brakes (VW uses this design, perhaps others) in which case a failing master/slave cylinder in the clutch could cause the level to drop without compromising the brake system, but even then, soon you will be clutchless. But barring that unusual circumstance, the brake system is compromised and that's dangerous.

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.

Funny you say that, I once worked for someone who interviewed potential product managers by asking how they would spec, design, and build their own entertainment center. Seemed to work pretty well.

For promising candidates, we ask that they complete a pre-specified project in their own time. The project takes most candidates 2-3 hours to complete.

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.

That sounds entirely reasonable; by paying, you're respecting the time the candidates have to put aside and chances are it will motivate people to do better.

(I'd send this in email, but I can't find one in your profile)

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 bcoburn3@gmail.com if you'd prefer to respond that way

The time involved in these things really can add up... I was recently asked to do a take home challenge that took a couple of hours to hack together, followed by several hours of nailing down edge cases due to the nature of the task. Then the company scheduled a phone call during which I thought we'd discuss the design decisions I'd made while working on the task. Instead, the interviewer had never seen the code I sent in, didn't even know which challenge I'd done and had me screenshare-coding brainteaser puzzles for over an hour on the phone. Talk about wasting my time.

Often these things are scored and ranked separately. Your phone interviewer will likely have scored you on various things, the score from your coding challenge will be taken as well, then everyone will sit down and discuss how people did and rule people in/out.

That can be true, but it's still a waste.

The only purpose of a code challenge or whiteboard session is to get the candidate and the interviewer talking about code. This is the only signal that you really want out of these exercises.

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.

> 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.

Call it what it is then. It's not a challenge but a weed-out. I know full well that that's what your company is screening for, but that also means that I know that I don't want to work for you. My time and contributions will not be appropriately valued by such a company and I won't like working there. My skills/value are not commodity. I don't want to start out a hopefully multi-year relationship on dishonesty.

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.

I guess I'm not really sure what the difference is, the entire point of all hiring processes is to "weed out" those that you don't want to hire. Otherwise what's the point?

> 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)

In many ways, I see these projects as a stand-in for the kind of comprehensive professional exams taken in many other fields.

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.

> I don't really understand this ideal.

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.

I for one have "walked out" of any interview that has asked me to do a take home assignment. Usually, the request for the take-home comes early enough. This shows me that the engineering team is too busy with work to even give time for a 30 minute shared text editor code interview. If we all refuse to do it, this crap will stop.

I balked at a take-home. They agreed it was a nuisance, instead hired me for a week to work with their team as a contractor! At my rack rate. That was a great experience, didn't hit me in the pocketbook, and convinced the team we could work productively together.

This is a good idea. Doesn't work for people on visas but I can imagine working this out somehow. Basically, make the potential employer realize that your time isn't free.

I don't really agree - I remembered a take home assignment which combined enterprise-like object-oriented design (data model, strategy) with algorithmic thinking (several flavors of graph traversal). The job also turned out to be top-notch before the company was bought by a certain trading firm which has 2/5 (and falling) on glassdoor. 9 months later it was pure shite. it was the best team i ever worked in though - still keep in touch with some of the guys :)

True! Word.

I'm helping hire developers here at HelloFresh and I thought of this a lot.

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.

Why not just ask them?

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.

This sounds reasonable.

"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)"

That's actually a great suggestion and I'm ashamed to admit it never occurred to me. I'll definitely share it internally. Thanks!

I'd rather spend 8 hours programming than burn a full day on 5 whiteboard interviews the way Google does.

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.

The point is, they never wrote back.

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

I've been looking into changing jobs and yes: it is a huge time sink. Traveling to interviews, being available for phone calls, preparing and researching... Especially the smaller companies are struggling to set up a good hiring process. I tried to discuss salary ranges before going into interviews to filter out some companies, but it didn't help. One recruiter put me on a one hour train ride, turns out there was some miscommunication about the job description..

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'.

I, for one, am tired of processes that don't respect my time.

Would you rather Some Co. just hire you and try you out for a few months simply based on your resume?

Of course not, but it is (or at least should be) a two-way process. If the interviewer wants you to invest hours of your time this should be respected; either by paying for it, or at least by being sensitive to the fact that people generally apply to jobs while already employed somewhere. So don't give them a 24-hour deadline on a programming task that takes 4-5 hours, things like that.

There's got to be some middle ground between that and wasting all your time off/free time.

That isn't the only other alternative.

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.

Reneging on paying for interview expenses is the most scummy thing that companies regularly try to get away with (well, OK, no it isn't, but in this industry it is, mostly).

That's exactly why I tattle on this particular company--Tyler Tech, in Lakewood--at every available opportunity. (In the U.S., truth is sufficient defense against defamation.)

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.

If you haven't already, you should make sure to write that experience up on Glassdoor as well.

It doesn't have to be one or the other. There is a broad spectrum between "try out based on resume" and "6 hour whiteboard hazing session".

I interpreted that as "after 8 hours of work at my regular job", not "8 hours of working on the project". Otherwise, why is he thinking about it on the train, and talking about how fun working on it that night was?

I could be wrong, though.

Would you feel better about providing work samples if you got paid fairly for each one?

This almost always comes up in work sample discussions. There is a fairly obvious reason those of us who advocate for them don't do that. It would rule out a large contingent of the candidate pool who have signed agreements not to work for money without prior approval or notification to their current employers.

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

Not everyone can or wants to take on the onus of basically being a part-time contractor just to switch jobs.

Maybe this is a bit rant-y, but "Paid Fairly" is incredibly relative. Every time I've been asked about doing some sort of paid coding assignment in my free time, I've asked to be paid at my hourly consulting rate, which many people do regularly, which is $60/hr. This is really not that much for a consulting developer.

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 have the same issue. It costs me hundreds of dollars to even agree to an interview, at my hourly rate. To further ask me to do homework is to bilk me for thousands. I cannot afford to apply for most jobs, as long as I have a consulting backlog. Which I almost always do.

Do you interleave full-time and consulting gigs? If so, how does that work in practice? Wouldn't doing a fulltime job for a while tend to dry up your client pipeline, as they find someone else for urgent work? With that in mind, when is it worth it to even try to find a fulltime job? I'm about to start my career, and wondering how hard it is to walk the line between consulting and "regular" jobs.

As you mention, having a client pipeline is the easiest way to find contracts. My last fulltime job came out of a contract - they wanted me on board. Worked for a few years, then they changed direction.

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.

I'm pretty sure this is in reference to the his project that he was wrapping up at his old job.

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.

IMO the upper limit should be a couple hours, but I'm not sure that should be communicated to the people interviewing because it can stress people out.

> 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.

If the project is designed to take that long, it's ridiculous. The project we give at my company should take maybe an hour if you know the framework we use.

I read this as "8 hours at my day job". I.E., he worked a normal day and then went home to complete the interview challenge

There are enough employers that you can avoid ever doing these coding challenges. Any time I've been looking for work, maybe 2 out of 10 companies would ask for these challenges, and I would skip them while interviewing at the other 8. I always ended up with several good offers before ever wasting my time on the coding challenges.

I personally would love this style of job screening.

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

You're free to your opinion, but, you probably should be. Any company that deems your time worthless for the interview probably feels the same way about your time during the work week. Maybe 60-80 hour death marches are your thing, but, that's not a perk I am (and I suspect many others are) looking for.

> 8+ hour programming project

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.

Problem is the ones that are not worth having that ask for the 8h

No, it isn't but enough devs put up with it.

Reply on news.ycombinator.com