I agree with most of the article. My problem with the "Hire by Audition" section is a little more robust. I currently have a job. If I'm looking for a job, then I'm doing that in my free time. If I'm looking for a full time job, I'm not looking for a contract job.
Now imagine that I've applied to five companies. Each of those five companies has given me an "audition," something that I can take a week to do. I necessarily have to do this in my free time -- I can't very well do it at my current job! -- and not only do I have to solve your problem, but I generally have to do it within some sort of constraint that you normally have, whether that's your codebase or your language or whatever. I'm going to spend a significant portion of that time simply getting up to speed with that constraint. Maybe I have to install Ruby or I have to install Symfony or I have to study the documentation for Twilio. Who knows?
I've never yet had an "audition" like this that didn't require me to sign an NDA, then install that company's codebase and work within that codebase. And I've rarely been able to do this in one or two nights of work. Usually one night of work is spent simply installing it, the second night studying what's going on, and then the third, fourth, and possibly fifth nights actually fixing the problem, testing it, and making sure it's good enough to submit.
It's a lot of work to ask me to do, even if you're paying me as a contractor, because again, I'm not looking to be a contractor. I'm looking to be a full-time employee.
I want to solve your real-world problems much more than I want to answer academic questions, but at the same time, you have to respect my time as well. I don't want to waste your time by not giving you enough data to make an educated decision about hiring me, but you should also not waste my time by giving me a task that takes up my entire free time for a week.
There's a happy medium here. I don't know what it is, exactly, other than letting me solve the problem my own way with my own code and my own tools, but if I do that, then it's not "something you would give your employees right now if they weren't so busy," right? Maybe.
I do worry about requiring a one-week project from someone.
However . . .
Sometimes I worry "what if I lose my job today?" It really could happen, even today, through no fault of mine.
People who live in Silicon Valley will say "well you have five other jobs waiting for you." But people not in a top-5 area don't have a job market 5 deep. It takes time to get hired again.
If I were to suddenly be unemployed, I would really love it that there are some companies out there willing to hire me for a one-week project at a much lower activation energy than taking on a full-time hire. It would 1) give me a chance to prove I can do the job, and 2) even if it failed it would give me money in my pocket right now which would be a very nice stress reliever. (In fact, it reduces my stress right now knowing that I could find a few short jobs like this. I'm happier even if I never need to use it.)
I certainly wouldn't want all companies to hire like this, because most of the time when I am searching for a job I am employed. But I like knowing that there are some employers out there that it would be easier to work with being unemployed instead of the reverse.
Sure, but the possibility of going off of unemployment for a week and then back on again might be somewhat painful (especially since the interruption while reopening an unemployment benefits claim might last longer than just a week).
That's not how unemployment works, at least not in Texas. You wouldn't go off the unemployment until you were actually hired. You would simply report the income during that period (2 week periods in TX) and they deduct the amount from your benefits for that period.
Yes, most states encourage you to take work, even temporary work. A contract job won't require you to stop it and start it, you just "skip" a week.
Last time I was on UI, it didn't actually last for X weeks, it lasted for Y dollars, and if you earned more than a certain threshold in a given week, they would reduce your payout that week by 50% of the amount you went over that threshold. So one week of high earnings would, in effect, mean you get $0 that week but give you an "extra" week at the end.
I interviewed with Skype once, I ended up not taking the job because it would have meant moving to SF and I don't really want to do that, but they asked me to do something interesting. They asked me to complete an assignment that was similar to the work I would have been doing, but did not require me to install their codebase, nor was it such a huge task that it would have taken a week to do.
This, to me, feels more like a happy medium between whiteboarding and "auditioning". The task was simple enough to be completed in 8 or 10 hours that I could do after work, and I even had some time to add some flair to it for style points.
Ditto here - I did an interview with AirBnb once where I had 3 hours to build a mobile app from the ground up to a specification. They provided all the designs and assets necessary, as well as the API and specification. The exercise was broad, covered multiple areas, and was holistic (you get a shipping app out the other end, not an isolated non-contextual piece of code).
I rather enjoyed it, and at 3 hours wasn't a huge intrusion on my time. This sounds a hell of a lot more attractive than throwing a whole week of my spare time at a company I'm not sold on, and IMO is just as representative.
The extra perk of this approach is also that, assuming you give the same/similar assignment to every candidate, it makes their performance directly comparable.
I could see that 3 hours is fine for something you are familiar with. Right now I am at my desktop and everything is ready to go for building something Django based. But say someone decides I should do it in Flask. I have looked briefly at the docs, but the fact I don't know it means I am unlikely to get far in the first 3 hours.
Yes, exactly. That's what I do when I interview people. I make it clear that this is something I am actively trying to solve (or maybe I've just recently solved it), and not just some academic exercise I'm doing that isn't productive.
I think that makes a huge difference. And in the end, I don't care what language you do it in or how you do it, so long as you solve the problem. If I write it in Ruby and you write it in Java, then if it works, I can hire you and your first job will be to port it over ;)
I moved to SF and I love it, but I understand not wanting to move around. I'm resisting moving away from SF for other opportunities...
Oh I'm not against moving around (in the last 4 years I've lived in Toronto, San Diego, Sacramento, and Los Angeles)... My wife and I just found SF/Northern California is not really our taste ;)
The article actually has a very, very nice suggestion that I hadn't ever thought of - the idea of having that audition be a todo-item on some open source project your company uses.
Many companies rely on a bunch of open source components/tools/whatever, and they don't fit perfectly; so if you think about it, it's quite likely that you already have some 'good-to-have' items that you'd like to be done on those projects; important enough to pay for it but not important enough to have it done right now by your current people.
And the good thing is that it'd allow you to solve the problem your way with your favourite tools, not require any NDAs or granting access to internal systems, and also be useful for the rest of community.
That's true if and only if the codebase is something that's easy to set up. I tend to get these assignments from companies that are like "Here's our Github repo. Clone it and fix issue #12345." When I get to the repo, there's an INSTALL.MD file a mile long, where I have to install a dozen dependencies and so on. And it never, ever goes as smoothly as it should. They inevitably forget to document some quirk or another.
That's not true for everyone, but it seems like it's the rule rather than the exception.
My point being that you're not just asking me to fix a to-do item, you're asking me to recreate your dev environment locally, research your codebase (to isolate the bug and figure out a fix), and then actually fix it. And if this takes more than a few hours, I may not have time to do it whether you pay me or not. Like I said, I'm looking for full-time work, not contract work...
That's all I'm really saying. I agree with you, though, that the to-do thing is a good idea. I just think there might be some middle ground, like if your task is "Build a feature to send verification codes through Twilio", then instead of using your codebase, I do it on my own in my own way. Then you can use my code as a model for your own. You don't have to research the whole problem -- just port my code into your codebase. And I don't have to fiddle with your codebase until you hire me.
Something like that. (Just thinking out loud here.)
You could also, as an employer, supply a pre-built development environment appliance for VirtualBox that already has your source and everything set up. Then a person just has to install VirtualBox, add the appliance, and boot it. I think there is even a way to get it where the person doesn't even have to install VirtualBox.
As an employer you could also allow access to a remote instance of a machine that is already set up and configured and the person can SSH/RDP into the box and do development there.
I'm thinking that there probably isn't going to be a clear cut, one size fits all answer to this, but I do think there are some good options in any case.
This solves the "setting up the codebase" question but doesn't quite solve the "learning your codebase" issue. Especially if we're talking about a codebase with any sort of custom frameworks or heavy modifications of existing frameworks.
If I can't get a "Here's a real problem we have, solve it however you want" thing, then this is the second best answer. You're absolutely right.
Open-source projects will generally be much easier to set up than a typical corporate codebase. A lot of effort to set up a corporate dev environment is annoying, but to an open source project it's death.
Getting familiar with the codebase is still an issue, but at least that knowledge has the potential to be useful even if you don't get the job.
This is true, but generally speaking, most companies aren't working on open-source projects like Jeff's Discourse is. Most companies that want us to do this "real" coding assignment are in corporate dev environments.
I have no doubt this process works well for Jeff's company which is open-source (as far as i'm aware), but it doesn't work so well for, say, Stripe or Kickstarter, whose codebases are NOT open source and likely have complicated dependency requirements.
The specific problem with this scenario is that they give the audition too early in the process: they want to have a set of fully fleshed out apps to compared candidates from and use that as an initial/mid level filter. This is disrespectful on the part of the company precisely because in the best case only one will be hired (more likely none will be hired). It utterly devalues the time of prospective employees for the benefit of the company. This is wrong.
The solution here is to give the "audition" after the candidate has passed all of your other filters, and commit in writing to hiring the candidate if they do a decent job on the audition. And no wishy-washy bullshit: have an objective criteria to measure against and judge it fairly. This is the kicker here, which of course will be the tough swallow for most companies. Paying for their time is nice, but its really missing the pain point here. If you want someone to commit a disproportionate amount of time in the process of auditioning for your company, you need to put yourself on the hook in a similar manner.
I agree 100%, beyond that my current contract strictly prohibits this kind of work. One of the premises of the article is that the restrictions on location undermines the goal of hiring the best. Given his hiring requirements I couldn't even look at his company--it might as well be on the moon let alone the valley.
We have just had an article on here about Susan Kare - icon designer extraordinaire.
I guess that when Facebook picked up the phone they didn't bother getting her to do a new 'like' icon or whatever it was they needed using their tools in their special dev environment with their special workflow.
They probably noticed that her other work had done quite well and thought they might as well chance it with her. They probably hired her without her drawing one pixel for them. Her competency was not in doubt.
This cumbersome audition process people want to put you through might work well for someone fresh out of college that has no portfolio of work, however, for those of us with work that is live and on the internets, isn't that, with a few code samples, good enough?
It's a little more complicated than that. I do agree that given a few samples and an in-person interview process, you should be able to determine my coding skills without me having to do a huge, week-long project. But it's not quite so simple as "Hey, look at my Github. See? I can code." Because you don't really know how much that was cut and pasted and how much of that was written by someone else and how much of that was written by the candidate herself.
But I agree that there should be some metric that we can gauge candidates on coding ability without giving them a week-long assignment.
If it was an easy fix, Jeff wouldn't have had to write this blog post, so... Gotta keep thinking about it, though. There's gotta be a better way.
I think portfolios for developers is a great idea, but it is difficult to ascertain if its really the developer's work, and what their contribution was.
Portfolios are all well and good, but a large proportion of IT work (I would guess the majority) is doing in house apps, where you aren't actually able to build a portfolio.
I see where you're coming from, but I come at it from another angle to arrive at the opposite conclusion about "Hire by Audition" or "Overcome specific real problem" tests.
That is to say: I don't have the money, time, connections, nor geographical/familial luck to have been born in America or in a supportive environment and attend a "top college". Nor do I desire to throw away several years of my life and six figures to get a piece of paper from people dumber than me to say i'm as smart as they are.
In that respect, i'll take the one week of unpaid work over several years, thousands of dollars, and social/political/time barriers which are completely insurmountable to me because it puts me on equal footing with the stanford/mit/harvard graduate. If implemented well it means its more likely to have something to do merit, and i'll respect companies that have a process that at least TRIES to implement a merit based process far more even if i don't get the job.
I don't like it, but i prefer it over the alternatives...
For what it's worth, I went to a tiny college in rural Alabama, and I've got a six figure job at a pretty large startup that I'm almost positive you've heard of, if you live in the US. The "top college" thing is bunk, as far as I'm concerned.
I think you're misunderstanding me though. I'm not saying they shouldn't require that you do a work-from home assignment. I'm talking about the fact that most "auditions" I get are far more than a simple homework assignment, and those employers often expect far more time than I have available. Like I said in another comment, they aren't just asking me to solve a to-do item from their to-do list, they're also asking me to install their codebase (and all that entails), learn it enough to isolate the problem and formulate a fix, and THEN and only then do I actually get to implement my fix and submit it.
That's more like contract work and less like an audition.
To make another comparison and riff on the word "audition", as an actor (I am one), when I go audition for a play, I'm not rehearsing with other actors and performing on stage for 1 night (the equivalent of a 1 week contract in web dev). Instead, I'm showing up with a prepared monologue (60-90 seconds) and possibly doing some cold readings (the equivalent of a "homework assignment"). The entire audition lasts an hour, maybe two.
One of those requires far, far, far more work than the other -- and the second one is what an actual audition is.
So what I'm getting at is that the problem isn't a merit-based approach -- the problem is a merit-based approach that doesn't respect my time and energy.
I actually agree with you, it doesn't respect a person's time and energy. It sucks. But the status quo doesn't respect it either, and it in fact requires even more time and energy (several years, several thousands of dollars), but we just don't account it as such because its just the societal norm. I'm not proud of my degree. I view it as essentially a societal bribe i had to pay to the indentured institutions to be considered for 99% of decent paying jobs. So it goes.
I can't think of a way to accurately measure someone's abilities that doesn't require significant time and energy from both parties :( But i'll take such solutions over the current alternatives...
There are of course some ethical problems when companies literally try to get you to do their work during the hiring process which i can't pretend to support.
I don't really disagree with you. The entire situation sucks, and you're right. To quote a quasi-famous mad scientist, the status quo is... quo.
I just think you can give me a programming assignment that I can do in a few hours instead of an entire week, and still get the information you need to determine whether I can code well or not.
I personally love my degree. It's actually in theatre (not CS), and I really, truly believe that it taught me a lot about how to contribute to the workplace and to society in general. If I had to do it all over again, I'd probably do the same thing. But I guess we just got different things out of our degree programs. I do wish that there was a better alternative, though, for those like you who would (I assume) rather just go straight into the workforce.
What if the hiring company culled the list down to a set number of candidates and gave them all paid contract work, on something they needed done anyway, as an audition?
This gives both the applicant and the company a chance to see how working together might go. The company gets something on their to-do list done, and the candidate gets paid for their time.
Yep id want £350+ per day for contract dev work and as I woudl have to do this after hours or at weekends thats time and 3/4 so £600 per day x 5 thats 3 Grand for a week.
Oh and £350 is low for a day rate you can easily get £500 plus for high end devs in the city / big data.
I would absolutely charge for this kind of thing, but like I've said before, if I was looking for contract work, I'd be a freelancer. I'm not looking for a one-week contract with a possible extension, I'm looking for a full-time job. For Jeff to offer me a one-week contract as an "audition" completely misses the point of my goals in favor of his goals.
But yes, if you wanted me to work on something for a week, I'd absolutely want to be compensated for it. But in my current situation, I just personally wouldn't take that offer.
Auditions are wonderful for job seekers: they allow you to evaluate the company much more deeply than the company evaluates you. If the work is tedious, boring, and uninspired, you know that this job isn't for you.
I once applied to a company that insisted on interviewers doing a test first. Just looking at the questions on the test, I knew this wasn't a company I wanted to work for, so I didn't even bother doing it. They asked me "why didn't you do it?" and I told them I knew this job was a poor fit just by looking at your test questions. I'm not sure if that is what they intended, but the benefit was good for me.
You are not wrong. I have experienced the same thing myself. I'm not saying the audition system is a bad system -- I'm merely pointing out a flaw, that a week-long contract is a lot of time to ask me to work on a project for you if I already have a job.
There are certainly many benefits to the audition system, or Jeff wouldn't have even mentioned it!
You're on the right track. At my job, we use Vagrant and VMWare Fusion to load up our dev environments. I'm thinking it might be trivial (or at least, less complicated) to simply give the VM to my candidate... The problem is that sometimes they don't have VMWare or VirtualBox. Ideally, I'd just write a single script that installs everything for them, so all they have to do is write code...
Even "Lets have a quick chat on Skype" can be a pain in the arse. I use Linux, and don't use Skype regularly, so its frequently the case that I haven't set up /used Skype on whatever laptop I happen to have at the time.
People might assume that I am some sort of idiot for not using Skype, but I have a proper VOIP number setup, so I don't have the need.
At this point in Jeff's company he is looking for someone who wants to get paid to work on Discourse, not simply have a job. Someone who wants that would not think much of following the easy instructions to get Discourse, install it, and be able to make a small contribution to the project (not sure about contributing but the download and install process is extremely easy and is sort of a fizz-buzz test in itself).
I don't know if this good advice for everyone looking to hire but it seems like filtering for both ability and motivation is a good idea for young, growing companies.
The problem with any discussion here on HN is that, judging by replies, many commenters feel insecure whenever an idea is proposed that they feel could exclude them from a job, even though typically these ideas do not spread, and most people need only one full-time job at a time (writing about interviewing has the same problem. See the first few paragraphs of http://steve-yegge.blogspot.com/2008/03/get-that-job-at-goog...).
I agree that if every company started this practice in the same way, applying for five jobs at the same time while currently working at one would be difficult. But it seems very unlikely that would happen in practice.
True, but just because I want to get paid to work on Discourse doesn't mean I want it "simply to have a job." I already have one, remember? I would also love to get paid to work on any number of other projects, but that doesn't mean that I magically have a week worth of evenings available to work on your contract project.
I'm not upset at being excluded from a job at Discourse -- in fact, I'd probably exclude them from my search! Quite the opposite, my time is valuable to me.
Just because I can't take a week to work for you on a contract basis doesn't mean I lack motivation or ability. It just means I have priorities that don't include sitting in front of a computer screen 24/7. I may have a wife and kids, or I may be an Olympic runner, or I may be struggling to make ends meet with other contract work, or I may be taking care of a sick relative. Who knows?
All I'm really saying is that there's a happy medium here. Some way for you to give me a programming assignment, and for me to complete it in a reasonable amount of time. Offering to pay me just means that you want a LOT of my time -- time that I likely don't have to spare.
If I were a junior dev and desperate for work, then yeah, I'd make this a priority. But Jeff isn't talking about junior devs -- he's talking about the best. And the best already have jobs and don't need to prove anything to anyone.*
Nah, not concerned at all. I'm just pointing out that auditions like this necessarily rule out a large subset of the population right off the bat. Maybe that's okay for your business objectives, maybe it's not. Maybe you're looking for "the best" and not qualifying "the best what." Maybe you're ruling out the best senior developers (who may not have time for this or have little to prove) and picking up the best junior developers (who may have spare time and everything to prove). Maybe that's acceptable to you. Or maybe that's exactly what you want.
I'm not saying "don't do it." I'm saying that from my perspective, I think it's a flawed interviewing technique and it's not something I would be interested in when applying for a job.
If it works for you, then by all means go for it.
I'm just saying it doesn't work for me.
He's partners with Joel Spolsky, whose old article on hiring [1] set the stage for a lot of the modern hiring era. Even though almost all of the questions are considered unfashionable today, I think the gist of "find any excuse not to hire" still holds in a lot of people's minds. The more people you reject, the better your candidates are, right?
The weirdest about Joel's method becoming the gold standard was that FogBugz around that time (I last used it around 2004) just wasn't that great. It was clunky, weird, and required a Windows server. It was served through a browser at a time when presenting GUIs through the browser was a slow and tedious string of refreshes.
Trello and StackOverflow are so much nicer now than FogBugz was then so I guess he hired better people. But I think a lot of his advice became vogue more because he was an entertaining writer than a great software entrepreneur.
The process of applying for a new job while you still have a current job will take time, no matter what the process looks like. The hiring company will want a series of interviews, and either a whiteboard, pair program, or code audition. A small project would perhaps take a little more time than these other methods, but should not take take that much longer, provided the hiring company has put some thought into what small projects they are giving to you to audition. If they pay you for your time, that is also respectful.
Jeff probably has enough "internet fame" to get away with asking folks to audition with a longer project and get good results.
Personally I'd be happy with anything that should take less than a day to do, but giving folks access to a pre setup client that has RDP or SSH setup would make that a lot less painful. A week is a bit too long.
I'm currently looking around for a new job and I'm being fairly picky about what it is I want to do, my biggest pain point is getting time to actually interview. My own personal preference would be a couple of phone interviews, then an audition project followed by something face to face. By then it seems likely we're going to get on so taking a day off is worth the effort.
Finally as someone currently looking around salary is something I'd like to at least potentially discuss relatively early on (or at least check we're both in the same ball park) I'm going to ask slightly high but caveat that with a statement saying that I'm potentially flexible for the right job (I like your problem domain, it will look good on my CV, you're offering equity etc).
I agree with you on the general workflow of an interview process. Phone screen or two, programming assignment (not 1 week though), face-to-face, etc.
I need to get better about the salary thing. I've gotten several offers from companies (even YC companies) in the last year, and each time we're just not in the same ballpark. I think a lot of it just has to do with equity. Startup CEOs treat their equity as worth a lot of money, but at the end of the day, I can't use my equity to pay my rent. So unless I really, really, really believe in your company's ability to dominate in that problem domain and/or exit successfully, your equity just isn't worth the pay cut for me...
But that's another discussion entirely.
I, too, am picky about what I want to do. I want to solve real problems. I don't want to reinvent the wheel with yet-another-message-board (sorry Jeff). I want to save the world. I want to do something meaningful. And a lot of these startups I see around here are solving what I consider to be superficial problems. Yet another ephemeral chat service. Yet another Instagram. Yet another subscription clothing service. Zzz.
If Elon Musk called me up and asked me to come "audition" for SpaceX, I'd probably do it. That's an exciting enough field and opportunity that I'd spend a week of my free time to get it. If a company that was building out tools for combating malaria called me up and asked me to audition, I'd probably do it. Or updating farming with 21st century technology. Or engineering a way to purify water for pennies. Or... well, any number of what I consider "epic" problems.
But that's another discussion, too. :)
I totally just went off on two different tangents. Whoops. :)
The "audition filter" here will eliminate those people who are (a) really good, and (b) can get a job without such nonsense.
HN has thrashed this out before, but what the heck:
- My current employee agreement may prohibit me from doing such work (this is definitely true of ALL of my employers up until now)
- I'm pretty sure I can get a job at a great company without such a hoop, so I'm not going to bother with yours unless I really want to work at exactly your company [unlikely]
You need to work on your ability to assess candidates without involving fear-based behavior on your part.
To a first order approximation the job market is a market for lemons (jobs and workers). Generally, the best folks will spend the least time in the job market, if any at all (note that I said generally, there are exceptions which I'll get to, don't write letters). If companies make comparable offers but one requires a bunch more hassle and delay through an audition process then economics 101 says that people are going to choose the option with less hassle more often than not.
An audition is a cost, and without something to offset that cost most folks will simply choose to avoid paying it. If you really want to hire the best and brightest and you have to rely on an audition process then at least consider paying above average for the period of the audition and for the job (if you actually are getting the best and brightest, paying them above market should be expected anyway).
Alternately, look at other ways to hire. If you truly want a company filled with the best and brightest then I suggest you switch from a "filter bulk submissions" model to a talent scout model. Don't look to fill roles, just continually be looking for new talent, and form relationships with talented folks whether or not they're looking for work right then.
On the cost of the audition: the programmer who is not employed at the moment may have two, three options to pursue, your company may be one one them. let's say there are two others: One willing to offer full time employment starting tomorrow morning, the second one willing to do 3-month contract-to-hire. The third, you, offer maybe paid audition. Unless your compensation is spectacular, he'll pick you third.
If he has only your offer to entertain, then he's not the best, is he?
The big problem is there is two interview/recruitment processes: A) the undiscovered talent, where you want to make someone jump through hoops to find that talent. And B) the established person who's resume and a 5 minute chat can establish their abilities.
"unless I really want to work at exactly your company"
And that's exactly what Jeff, Discourse, and Discourse coworkers want. Someone who really wants to work at Discourse and not someone shopping for a new "best" job.
EDIT: No, this doesn't address the situation where a potential person who wants to work for Discourse can't because of current obligations.
EDIT 2: Wanting to hire the best and brightest is just marketing fluff that really means We Hire Very Talented People*
Thanks for verbalizing this. There are a slew of talented developers in the Valley, all of whom can do the technical work. The paid audition is a chance for both the hiring company and the candidate to make sure their values are aligned.
It's not a matter of liking real work or not. Of course everyone prefers real work to silly logic puzzles, but that's a false dichotomy. It's about trust and commitment. You're asking your applicants to assume virtually all of the risk in the transaction. They have to either quit their job or violate the terms of employment. They have to go all-in on your company for weeks as opposed to considering multiple offers. This way of hiring may work for the companies that are already highly desirable (though I think it's still cruel), but it's absolutely lousy advice for unproven companies in a competitive hiring environment. You totally don't want to work with bad people. Not at all. So suck it up, hire the people who look promising, and fire them promptly if they don't work out. But absolutely, positively, do not encourage every little startup to strut around like they are doing top talent some sort of favor by even considering them.
You're absolutely correct, and I want to highlight one thing you said: Nobody likes firing people. Every manager I've ever worked with hates firing their employees -- even really bad ones.
What the "audition" is all about is trying to make it so that you don't ever get into a situation where you hire someone, work with them for a month, and say, "Holy shit, this isn't working out at all, I'd better fire this guy."
In France or something, where it's super-hard to fire people, maybe that makes sense. In California, it's mostly about trying to spare the feelings of the manager.
I've found that bad managers tend to be unable to fire people, and one of the things I always tried to gauge when interviewing for a job was if the company was capable of firing.
And, yeah, I've had to fire some people. It really sucks, no matter how deserved (well, I'm talking about just not being able to do the job, vs. "for cause" where it's white line stuff, fortunately never had one of those cases).
I completely get that. I've had to fire people, and it really really sucks. But that's the point: you don't get to externalize that onto your candidates.
"hire the people who look promising, and fire them promptly if they don't work out."
What's the difference between that and a pre-hire, high workload paid assignment?
The only practical difference I see is that the eager employer gives the new employee some false hopes of slight stability, which may cause her to uproot her entire family, e.g. "got a job in city X, honey, we're moving".
I love real work. I hate doing basic stuff on whiteboards; puzzles and toy problems suck. But I firmly believe that doing what amounts to an internship is filtering out people that you would be ecstatic to have at your company.
Most of the really good engineers I've worked with can go anywhere. When they're available it's by their own choice, and they're gone damned quick. (One fellow recently got fed up with things over a couple of months, made a call, and the email he got back said in part, "Apparently you aced your interview. When should we tell HR you can start?". Seriously, how do you compete with that?)
The people are not on the street. These people will not suffer the gauntlet you have decided is necessary. They're going to think to themselves "That's cute," and look elsewhere. I won't do a weeks-long project. I know very few people who would.
You CAN assess someone well in eight hours; if you can't get a good handle on someone's skills in that amount of time then you seriously need to improve your own interviewing skills. The message you are sending right now is, "We mistrust our interviewing expertise to the point that we want YOU to take a multi-week risk, really a very high risk, just so that we can be sure."
Now, there are undoubtedly people who want to work at your company, and they are willing to go to any measure to do so. If you are all happy with each other, then I see no reason why our paths should cross.
I guess this is the point where you can publically rationalize your strategy by bucketing me as a jerk, "sour grapes," someone you wouldn't want to work with anyway because of red flags and such. I won't steer you away from this, since I can't offer any proof that I'm not.
But I'm darned sure you're missing good people, even if you're convinced I'm not one.
That makes sense, but doesn't address the OP's other major point: how do you deal with people who either 1) are contractually prohibited from freelancing for you or 2) are too busy with their day job to be able to give an honest effort? Have you ever had a candidate that you suspected would be a good hire but was in that situation? How did you deal with it?
The articles suggests asking candidates to consult for you for a few days or a week. That's just not very realistic. I'm all in favor of doing real work with a candidate instead of bullshit whiteboard problems, but candidates who already have a job do not have time to do your consulting job alongside their current job (and their job search!).
Candidates who do not currently have a job perhaps have more time, but still probably are not that interested in suspending their job search to consult with you, and also (correctly) judge this to mean that you're skeptical about their abilities, and want to take a job with an employer who is more enthusiastic about them. That may be somewhat irrational of the candidate, but it's also true.
I think the GP's point was that if they are looking to get a job, they probably has many options of good places to work (even if perhaps not as good as yours) which would not require this of him, and therefore your audition can be seen as extra work which they do not need.
Now, if I were Very Interested in working at Discourse, Fog Creek, or any similar place of work, rather than just at any place with a nice paycheck, I think the audition is a great idea, and something people would be willing to do.
The GP's main objection is that you only get the best people who want to work at __your__ company enough to spend time on your auditions. There are likely many engineers like them who have a network of job opportunities compelling enough that the added draw of it being Stack Overflow, Discourse, or Fog Creek is not enough to merit the extra work.
It might also work if the audition was applicable to many potential employers, like how talent scouts in sports and the arts go to events where the potential talent performs rather than having the person audition for each potential employer. (I'm not an expert on arts or sports so I might be off on my analogy.)
I hear a lot about GitHub, blogs, and open source contributions which essentially act as your audition open to all talent scouts.
Perhaps if the audition challenge could be posted to the applicant's GitHub account then it would be a bit more useful to the applicant. The challenge could be skipped if a project in the GitHub account already demonstrates proficiency in the desired application domains.
The sports analogy is partially correct, but college prospects in all the major sports have to go to the talent recruiters before they are signed. (NBA tryouts, NFL Combine, etc.)
I think you're setting up a false dichotomy here. The best job offers I've had in the past have been from people seeking me out and where the interview process was mostly a formality. I think that's true of a lot of folks out there (I can certainly point to a butt-load of examples I've witnessed). The idea of a random person walking in off the street and being assessed as being the norm for an interview process is, I think, erroneous. As too the idea that merely giving someone an audition project will ensure they are of the highest quality. Hell, I'd say that sometimes it's even possible to code side by side with someone for a year and not truly understand their potential. There's no silver bullet for assessing dev. skill level. The biggest fallacy is believing that whatever method you come up with won't have huge flaws and gaps in one way or another. I think the best to hope for is ending up with a good enough "batting average" to build a talented team.
I get a similar impression in my industry. The best-and-brightest automatically have ten different job offers, usually by virtue of the people they have worked side by side with in the past. You know, as in "I worked with this guy for 5 years back at company X, we want him".
I think every candidate prefers a real project to BS puzzle questions and whiteboard coding - it gives them the opportunity to show their real skills, and to also evaluate the culture and the team at the company.
But only students, freelancers who want to quit freelancing, and the unemployed would be able to take "a few days to a few weeks" for such a project. For someone in full-time employment, a few weeks would be most of their vacation time for the entire year, just for one interview!
It's certainly a hoop if you're already employed and have a multitude of options that I would presume the best and the brightest all do. It can come across as nonsense because if I'm good and know I'm good, I'd expect any potential employers to be able to recognize that easily without a trial period. And it certainly reflects a fear of commitment, warranted or not. I'm not sure why any in-demand developer would subject himself to that kind of trial period - not only is it against the terms of most employement agreements, it represents disproportionate commitment to a single job lead, which may be better spent on interviewing and receiving other offers. You, as an employer, are not special and the best and the brighest recognize that.
I don't think it works well as a filter either - a technical interview can easily assess capabilities and while you're right that it cannot accurately assess work ethic or motivation, a trial period cannot either! A desperate candidate during a trial period is generally going to behave very differently than he would a year down the road when he feels bored and the job is secure in his mind. Is it a better filter in a vacuum? If you start with the same sample of candidates, all of whom had to go through whatever process you devise, would a trial period make it easier for you to find the best candidates? Of course. But having such a process significantly skews your candidate pool to the desperate. That's not necessarily a wrong approach to recruiting, but it has nothing to do with hiring the best and the brightest. In addition, unless you're extremely careful, you'll be mostly judging candidates based on their familiarity with your technology stack and workflow, as opposed to long-term potential because that's what short-term productivity depends upon.
It may not apply to you in particular, but one other thing that would make me worry about a trial period is that it's indicative of two other personal flaws on the part of the hiring manager - he may be 1) indecisive and 2) technically incompetent. The indecisiveness part is obvious - not only is not being able to hire without a trial period a mark of indecisiveness by itself, it's also a hedge against future indecisiveness in getting rid of employees that don't work out. I also find that technically competent people can judge competence in others very well, very quickly. They aren't always right and there are qualities that only manifest over a longer period of time, but those qualities can't be judged in a few days of work.
"How do you be a good angel investor? The first thing you need is to be decisive. When we talk to founders about good and bad investors, one of the ways we describe the good ones is to say "he writes checks." That doesn't mean the investor says yes to everyone. Far from it. It means he makes up his mind quickly, and follows through. You may be thinking, how hard could that be? You'll see when you try it. It follows from the nature of angel investing that the decisions are hard. You have to guess early, at the stage when the most promising ideas still seem counterintuitive, because if they were obviously good, VCs would already have funded them."
Stringing people along while not being able to make up their mind is what mediocre investors and VCs do - without seeing good evidence to the contrary, I'd guess that this applies to employers as well.
Edit: in case my point wasn't clear, I'm not saying the approach is wrong or doesn't work or anything along those lines, merely that it's not how you hire the best and the brightest. Now, it's possible he meant "the best and the brightest" in the cliched way where everyone thinks they hire the best and the brightest, in which case it's fine. But in a literal sense, if your organization needs the best and the brightest, you won't get it following those suggestions.
Edit2: the point of pg's advice isn't that being decisive somehow is correlated with risk-taking and thus higher returns. The point is that being indecisive doesn't lead to significantly better decisions and if you can't make decisions quickly, you won't get the very best deals. If you're known to be indecisive or advertise this up front, no one who can get other investors will come to you. This is absolutely the case for talent.
Cultural fit is not a good reason either. If you can't judge whether someone fits in during the interview, you're probably not going to figure that out during the trial period during which you have a desperate person desperately trying to fit in. What's worse, this very mindset of "let's hire people who fit in" leads to the worst culture. If culture matters to you, hire people who are different.
And yes, finding good engineers, regardless of cultural fit, is by far the hardest problem. If you're optimizing for cultural fit and you're not Google/Facebook-type talent magnet, you're not even in the competition for the best talent. This may be fine if your bar is low - and let's face it, almost everyone's is - but again we're no longer talking about the best and the brightest.
>It can come across as nonsense because if I'm good and know I'm good, I'd expect any potential employers to be able to recognize that easily without a trial period.
I can only speak for startup / small team hiring, but the problem I see here is that the only hiring metric that you seem to be testing for is if the person is a good engineer or not. I believe that is rather objective, and in these days pretty clear to assess with the plethora of people writing open source projects. Simply put, if I was recruiting, I would not have contacted if I didn't believe you weren't capable of the work. (I also have the same problem with "Traditional" interviews, inviting a person for a job then testing them with fizzbuzz is like hiring an athlete to join your sports team, and on the first day asking him if he can kick a ball.)
What really worries me - and why I'm more a fan of a trial period, is how do you, as a human being, fit inside our community. Other than "not being able to do the work" there are a million other reasons why someone would not enjoy, or atleast put up their place of work. Maybe the team always has 6 o clock beers, and you don't drink so you feel left out. Maybe the team are composed of entirely of Montagues and you are a Capulet. There are human factors in the work place, and I believe, everyone should be comfortable where they work - and despite talks of equality, openness, and acceptance, there are people that just plain can't get along with other people for whatever reason. Were human and we move on.
Now again, I'm trying to build a small startup team and it might be different in corporate. However what would you say to employers that are looking at "trial period" hiring as a way to gauge culture fit and ultimately employee happiness?
Hiring employees is not angel investing. You want to minimize risk, not maximize it. VCs and angels are in the business of assuming massive amounts of risk.
In that case, your goal isn't to hire the best developers, but good enough. You're managing risk. Perfectly valid, but not what the article was titled.
This is a nonsensical comparison. If you were truly "angel investing" in your employees, you would be there at birth handing out shares. Or maybe "series A" would be recruiting them at their high school graduation.
I make no statement if you're angel investing in your employees or not -- I'm not even sure what that means.
All I'm saying is that if, as a business, you are seeking to minimize your risk portfolio during hiring you are, by definition, not seeking to hire the "best" employees, but to hire the best employees with the lowest risk profile.
Once again, I don't think this is bad. You're running a business and the task is to get the highest probability you'll hire a productive employee.
Nonetheless, the OP has a point that you may lose employees due to your risk tolerance being too low.
Example: I work on the C# compiler. I'm not going to take a prospective employer's "knowledge test" on C#, regardless of if that is statistically a good filter for them in hiring.
Every form of interview looses someone. If you follow that argument to the end the best interviewing process is waiting until you have a few candidates, throw a dice, hire the lucky one, dismiss the other candidates.
Chris, I love to work for Stack Exchange. The problem is I don't like to work on .NET systems anymore. I don't want to lose my Unix command line tools! :)
Indeed. The proposition is "If you finish this work successfully, we will put it in production and you'll get paid for it."
It's hard to get more real in my book.
I do agree it's a hoop (what hiring process doesn't have those, even if it's a mutual trusted friend vouching for them?), if you can't get it done then one or more of us has made a mistake, but....
An onsite interview can (and probably should) involve sitting you in front of their computer, and getting you to close a ticket.
If you give people homework problems, then it's possible they will either palm them off to a more competent friend (or just pay $100 for a freelancer); or consider it an insulting waste of time.
Neither will test whether the candidate is reliable. But at least an onsite test will be harder for them to fob off to someone else; and it's less of a waste of time. It might take them a day or more to set up a "hello world" build at home (depending on the build requirements, and how well you've automated things).
I thought grandparent's "fear-based" stuff was over the top, but why are you so sure that your current strategy is the proper one, enough to dismiss other interview methods with talk of "B.S. puzzle questions"?
I actually don't mind whiteboard stuff, as long as it is done at a higher level (not nit-picking about leaving a semicolon off). It allows you to actually discuss your thought process, which a homework assignment doesn't. And as someone else pointed out, how do you know the homework assignment was actually done by the candidate? Also say candidate A has a slightly cleaner solution than candidate B. How do you know that candidate A didn't spend 4 times as long as candidate B on the slightly less cleaner solution.
All things considered, I am more likely to apply to a company that makes starting the process quick and easy.
I already have a job. When I search for other jobs, I do that in my free time. I really hate doing it. It is tedious and very unrewarding. So I want to maximize the number of leads I create per unit of time.
When I see a code audition, I see many hours of useless bullshit done in my own free time that could create at most one lead. At that point, you pretty much have to pay me to apply for your job.
So much gets said about the number of applicants per position, and how to filter those. Well, the converse is true. All those people are also applying to multiple job openings. They filter based on published requirements and ease of application.
Not only do you want to hire the best applicants, but you also need to make sure that the best people become applicants in the first place. That won't happen if the very first thing you do is prove unequivocally that you do not value other people's time.
If the applicant doesn't get anything out of it, then it would be a waste of their time. But as an applicant, wouldn't you also want to make sure that your potential future coworkers / managers are people you'd want to work with? You're evaluating the company just as much as they're evaluating you.
Agreed. But what an audition tells me about the company is that everybody there was willing to put up with it. Anybody who has lots of options probably didn't end up there. So maybe the company is so awesome that good people were willing to jump through hoops to get hired there, but even so it's a pretty safe bet that they don't have the the best and brightest working for them.
You're assuming that everyone views try-out periods in the same negative light that you do. If that were the case, then your conclusion would be right. But not everyone shares your views. Some people prefer to have a try-out period, because it gives them a chance to evaluate the employer.
I'm assuming that the best and the brightest don't have time for a try-out period, because they're busy doing stuff, and don't need one because they can easily get another job.
A try-out can just be on the weekends. I'm sure some people can't even spare any weekends, but there are plenty that can. Many people work on open source in their free time - this isn't all that different.
And true, nobody needs a try-out period - but some want one, in order to help them evaluate their potential employer.
If your assertion is that none of the "best and brightest" want to test out their potential employer, then we'll have to agree to disagree.
Thus excluding everyone with a shred of self interest or any experience with drinking the corporate mystery beverage.
Clever, but you won't end up with "the best."
Somehow, I don't think that "the best" would forego thousands of available opportunities to work for a company that won't even consider hiring someone who might be able to compare their offer to someone else's.
A lot of people find it within their own self interest to work somewhere that is careful about hiring. Personally, I find that job satisfaction depends a lot on who my colleagues are.
And I don't think this hiring practice precludes employees from evaluating other offers - if a company goes through this process and decides to extend an offer (and they're growing fast), they're likely to be willing to hold the offer for you while you evaluate other opportunities.
I'd much rather hire very good and local to the best and remote. Someone who comes into the office adds so much more to the company besides the work they produce.
They attract other very good people just by virtue of being there. They contribute to things outside their specific job description in ways that a remote person can't (company policies, culture, company direction, leads on customers, etc - often serendipitously). They are frankly worth more in an acquisition scenario because they are more likely to stay with the company. They can grow into senior or leadership roles in a way that a remote person simply can't.
Frankly, I think the best and the brightest is kind of a mythical unicorn anyway. If you keep chasing them, you'll end up passing on a lot of great people.
This is one of the first really good points I've seen against remote workers, at least for smaller companies.
E.g. just because I'm that way, bought my first DECtape in 1978 (sic), backup my home systems on LTO-4 today, I almost always ended up being the guy who did the company's backups at the startups I joined. Especially if you can't afford a tape library, you've got to be there to do that, to make damned sure it gets done.
Or someone asks me, a couple of decades ago, "we're dissatisfied with our ISP, you know any good ones?" and I say "well, I've been personally using DIGEX for a few years and they have their act together." Etc. All outside the scope of my official work as a programmer.
Or even more obscure, one of the things my family back home back then did was real estate and I picked up a lot of things by osmosis, and later reassured several sets of small company management that the clock cycle of that field was much, much slower than ours, and they didn't necessarily have to be concerned by how long it was taking to get new office space etc. Again, something I'd not be able to contribute without being there to hear them grumbling about the issue.
Also, if someone wants to politically trash you, being remote puts you at a terrible disadvantage. I had that happen when I mostly "dissapeared" for 6 weeks to produce a MVP a potential client challenged us to make, because I had a much faster machine at home and didn't have an office mate who's job it was to talk a lot on the phone (yeah, the company didn't get several things).
Completely gratuitous, the guy was of ill intent, left the company taking our biggest customer which probably doomed it. But it, well both of those, set up the conditions for my getting constructively terminated as soon as I finished V1.0 with my team, and with the guy I'd mentored on what was almost his first job into a good software engineer, leaving soon after, removing all knowledge of the system's backend from the company, that product died.
On the contrary, we have had a great experience with remote working teams. We are a young startup, and we started out wanting to hire the best local folks (that is clearly preferred, if you can do that in a reasonable time). But that was taking a lot of time and/or money (both we couldn't afford to lose much of), and we started working with remote team-members on fixed-term assignments - they got us started quick. After working with them for several months, I can say they are contributions have been invaluable. I'd happily hire them as full-time remote workers. The key, of course, is to find people who are good with the extra communication that remote working typically needs.
I see a lot of drawbacks to the consulting project:
1) Anti-moonlighting clauses
2) Time commitment from both parties
3) Tax/thought overhead to signing agreements and getting paid. This way I'm a 1099 everywhere I interview. There's a reason I'm not an independent consultant full-time.
4) Different challenges. How do you objectively, fairly evaluate candidates when they're given a different issue to fix or different feature to implement?
But I agree that work-samples are essential to good hiring.
A staged, small-challenge approach (like Thomas Ptacek / Matasano use) seems better to me from the standpoint of an interviewee for a few reasons:
1) Less overall time commitment.
2) Fail-fast. If I blow the first hour(s?) long screen, I'm done. No weeks of work involved.
3) Consistent, fair evaluation. Presumably a set of "canned" challenges are used and the time taken and quality of output can be evaluated directly against the performance of others.
Speaking of moonlighting clauses, can you imagine the legal shitstorm if you were to moonlight for a direct competitor? There's no angle in which that doesn't look bad.
My company's direct competitor contacts me on a weekly basis to try and poach me. I'm super, super highly qualified for that job, and I could probably leverage a massive raise... but I would feel so, so dirty for doing that.
It's fine to go to a direct competitor, I think. I'm just saying working for both at the same time would be... well, probably career-ruining in my line of work. I believe our little industry has an unwritten rule of 2-week minimum cooldown when switching companies.
I have first hand experience with mentoring a junior dev and he is dead on about it not working remotely. In my experience it quickly devolves into the senior dev answering a continuous stream of emails or instant messages to help troubleshoot some simple issue. Interestingly, one of the biggest issues I have seen is an inability to succinctly communicate the facts around the issue that the individual iss struggling with. A lot of time is spent interrogating them for more info to find out what exactly the problem is. These are the kinds of situations where you really must be able to sit down next to the person to efficiently bring them along and not being able to quickly becomes an exercise in frustration for both parties.
I've found that it takes more preparation from both parties but is still doable.
Each interaction should be treated like a mini presentation. I have a toolbox I use for this that includes:
1. screenshot software
2. screencast software
3. screensharing software
4. videoconferencing with an HD webcam
5. a whiteboard I can point my webcam at
6. note taking (I use evernote)
7. remote assistance software like logmein or teamviewer that lets me take control of the other persons PC or vice versa.
it's not completely seamless, but if everyone is using the same toolbox and is capable of starting a video call, snapping screenshots and sharing them, switching to the whiteboard to brainstorm posting a quick video of the issue/prototype whatever in the shared space then it works pretty well.
The biggest barrier to good remote teams or mentoring that I've found is when no one has the same tools or is willing/knows how to use them. Also, if either side has a resistance to learning knew remote processes or has a grudge against the remote person for being remote or for the need to hire remote (because of lack of talent in the local area) then there's more problems than just not being able to collaborate remotely.
Wow, you go all out! I've mentored remotely and been mentored remotely with nothing beyond email, text chat and (rarely) phone. I'm not sure how that couldn't be sufficient given all of the open collaborations successfully occurring.
Of course it helps if the junior developer also has a project (or any other tasks) matching their current skill set to work on so issues don't have to be solved in real-time to prevent idle+frustrated engineers.
I've actually had more trouble with local mentoring. It is hard to get people thinking deeply about how something works and how to solve problems when they know an answer is a few grunts away.
well I don't use all the tools all the time but I've certainly used all of them at one time or another.
It's not so much having all the tools, but standardizing on a certain set of them and making sure everyone uses them and knows how to. Then if I say, "Let's collaborate on this, I'll send you the document link" my co-worker knows I'm talking about a google doc or a whatever we use.
Sometimes you need feedback but it's not urgent. Could be for a problem your having or maybe just on a new interaction or UI element you're working on. That's an ideal case for grabbing a short video clip rather than trying to describe in an email, "The drop-down panel re-sizes the entire parent element to 100% but only when I . . .etc".
Videoconferencing should really be the default for team interaction remotely. It's takes no additional work over a phone call but you can read the other person better. Over time this makes a big difference in team cohesion.
I keep notes on my work process regardless of whether I plan to share them or not. Being able to share them and even collaboratively edit them is another big time and bandwidth saver as both of us can add debugging notes to a running log or brainstorm together on a new idea complete with screenshots of mockups or grabs from a similar webpage or app.
Interestingly, one of the biggest issues I have seen is an inability to succinctly communicate the facts around the issue that the individual iss struggling with. A lot of time is spent interrogating them for more info to find out what exactly the problem is.
Over 15 years helping people on IRC has taught me that dealing with this is a mentoring skill. There are lots of shortcuts that both get to the root of the problem and foster skills in the junior to suss things out for themselves, or at least formuate their problem better. Streamlining two-headed troubleshooting is a form of pairing and can totally be done remotely.
What's even worse , is that your manager is not aware that you are spending the first hours of your day troubleshooting other's problems and answering questions.
In the office environment the junior dev will come to your desk and everyone sees it, in the remote work he will ping you privately because he is too shy to ask it in the general chat...
Allowing only public chats will not help but just pollute the general channel of communication.
If I get email questions from a junior dev, I try to cc my boss when I respond, just to keep them in the loop and make it clear that I am spending some cycles helping him or her.
It's a long article, so let me excerpt a few bullet points for those don't have enough time to read the whole article:
1) Don't just hire local talent, hire nationally, even globally. There are lots of successfully companies embracing working remotely.
2) Evaluate the value of a person's contribution based on how much they have done rather than how much time they showed up (what's done >> what to do). Some effective way to measure so is to track Github commits to see how many bugs they fix, etc.
3) When hiring, hire by audit. Pay the interviewees some hourly rate to finish a mini-project that is a part of your company's real work (e.g. add a feature), and let their performance in the mini-test be a large factor in deciding hire/no-hire decision. Also, try to hire from your tech community.
4) Effective communications for remote work: real-time chat, video chat, online bulletin board, weekly team status report.
5) Some big drawbacks of remote work are: brainstorming is hard + mentorship is hard. Luckily, some of the companies don't need brainstorming much. And for mentorship, don't hire people that need extensive mentoring.
I've been thinking about this issue lately. Jr developers, interns, fresh grads, etc all have some alluring properties: they are cheap(er), have few(er) bad habits, and are more open to being coached into their roles.
Netflix, on the other hand, hires no folks like this.
My current company is comprised almost exclusively of newer engineers. It has put me in a strange position as someone with > 10 years experience in my field when that long ago, most were in high school.
I think the reality is that only large-ish companies have the slack time necessary to devote to mentoring. Companies have to get to a certain size first.
At a startup, you are running full tilt 24/7 by necessity.
Startups are not (usually) engineering firms with super high quality requirements. My first job (still in college) was at a startup. I was the only developer under the CIO. It was a java webapp and both of us barely knew Java when we started. It worked pretty well, we had minimal serious quality issues compared to most companies I've worked at, we had zero unit tests and a shoe-string budget. That company is still going strong and has made millions off the project I started practically on my own over 10 years ago.
It can be argued that startups require a broad range of skills in a wide array of technologies, and you don't get that with inexperienced people.
In a mid-sized organization you can work on a java webapp - as in your example - and possibly only on a part of that java webapp. In early stages of a startup, you're likely to have to know your way around the webapp's frontend, backend, mobile app/mobile web adaptation, handle SEO, plan for scaling, be a part DBA, handle server administration DevOps style, and do all kinds of internal business process automation unrelated to that product you're building. You'd need to be a jack of all trades at beginning - since there's noone around who's specializing in that other stuff - or spend half of your time becoming a jack of all trades.
I installed the servers in the rack at the data center, configured the load balancers, installed and configured the database with a hot backup and wrote 90%+ of the application code when we went live. You don't need people with all that much experience.
Well, mentorship was mentioned as being hard to do remotely. So, don't hire remote interns or remote junior devs. That seems like reasonably good sense to me.
But of course "remote" is a reciprocal relationship. If the senior dev is remote and the junior dev is local, it doesn't matter, the senior dev still can't mentor the junior.
Ideally, your audition project should be a regular consulting gig with an hourly rate and a clearly defined mission statement. Select a small project that can be done in a few days, maybe at most a week or two. Let the candidate choose to come into the office or work remotely.
So, only hire people that can afford to quit their current job for an interview? Or at least blow all their vacation time on you?
Just like IT projects, there is no silver bullet to interviewing, and you have rightly brought up some good points about why this will not work.
Despite producing over 60 apps for the iOs app store, a new employer wanted me to whip up an app with a tableview that is sortable and searchable. I told them to stop wasting my time.
The dirty secret of remote working is that unless your company is located in the middle of nowhere, the pool of developers that have the discipline and skills to successfully work remotely on a permanent basis is even smaller than your average local pool of talent.
Right now it's still an opportunity because the number of companies fishing in this pool is still relatively small, but that is changing rapidly.
The scarcity we're dealing with is still mostly a scarcity of mature professionals, and with remote working anything less than that is not an option.
It's not really about scarcity of mature professionals, but of how hard it is to find the ones that are out there, and get them to apply.
Take this large-ish city in middle America. I have worked with a few local developers I would call mature professionals: If I was starting a startup, I know where I'd call. But I only know their skillset through having worked with them over the years. How can someone that doesn't have a network find them?
A few you can find in user groups and meetups. But that gets you one very specific brand of mature developers. Many in my list wouldn't go to one of those: They are often just sausagefests, with 25 to 35 year old males trying to impress others about how good they are. That and recruiters who tend to not know anything. Same thing by going with speakers in conferences: You get a few people, but those are probably not going to make your company their number one priority. It's more likely that you are an excuse to make money between other engagements.
An ad in a recruiting site? The really good ones don't get jobs like that: They mention a friend they are unhappy in their workplace, and they quickly get recruited. I got my last job like that, without even an interview. So and so says you are great and would mesh very well here, so have an offer.
Pestering recruiters? You can talk to those, but they can't tell the good from the bad. Also, the mature professional can't tell if your newfangled startup is good or bad. Will you want insane hours? Do you have a crazy idea, like mandating that all code is organized in tiny web services 100 lines of Clojure or less? Unless they are unhappy in their existing position, you have to find them and prove to them that you are a worthy employment option. And they might not even buy into your pitch. No, They might think that a web of tiny services doesn't really fix all the world's problems, or they might not want to do boring business analytics.
So, more than the scarcity of professionals, the real problem is that you can't even contact them.
If there wasn't a scarcity, the people you describe couldn't afford to make themselves that hard to find.
The fact that they don't bother applying for jobs or, directly or indirectly, publicly soliciting offers is a symptom of that scarcity.
Also, the problem I encounter with calling on the people I worked with and would like to work with again is that most prefer to be self-employed, and can easily make more money that way.
>Also, the mature professional can't tell if your newfangled startup is good or bad.
What? I can tell if an early stage startup is good or bad, by talking to the non-technical cofounders for a few minutes, just like a good programmer can evaluate me by talking to me for a few minutes.
Common red flags:
- no technical co-founder
- hiring an outsourcing company for MVP
- a "technical advisor" who is not a full-time cofounder
If you see any of those, forget it. I wonder why angels are still dumb enough to invest in such things.
As somebody who lives in a non-English speaking country, with not-so-great prospects of well-paid local work, I encounter the opposite problem of not knowing where to look to find people willing to hire professionals.
Also, it seems that a big proportion of people who are looking for "remote" work are actually looking for people who live in the US, and can still go to the office when required. That is going to limit your pool a lot too.
Assuming you are someone who actually looks for these professionals, what sort of process would you go through to actually try and find them?
I live in SF and operate a startup in the US but almost exclusively work with resources outside of the US. I believe this model, with it's challenges, does work and can work for many business. I also believe that many talented people (right now many of them coming from Eastern Europe and South America) lack the ability to get exposure to opportunities from well funded US (mainly SV) based companies.
That being said, if anyone (mainly front-end UX/UI, iOS, android, rails/django, node, and various MVVC js frameworks) who feel you are talented but aren't getting the right opportunities to work on cool, well-funded projects in the US, feel free to get in touch.
Same here, been working exclusively with devs from Eastern Europe and it's been working great. Also want to plug that we're always looking for capable Rails devs so hit me up if you're interested!
On the point of hiring the best and brightest wherever they live: I worked for a startup that hired from all over Europe and North America. We did hire some great people, but there are definitely considerations and downsides. Here are some of the cons I noticed:
1) It took a lot of effort to discourage cliques based on location. People from different countries or parts of the country bonded more easily. New hires would also quickly bond because they didn't know anyone, but together they felt excluded by the established groups. This was critical to their happiness because they didn't usually have friends outside of work. We managed, but it does require more effort to prevent internal politics.
2) This wasn't the sort of job where everyone could work remotely, so we regularly lost people who decided to go back home. That's why I left, and I was neither the first nor the last. People miss their families and friends, especially if they miss a large event.
3) Moving people can be expensive. Obvious, so I won't elaborate.
4) Recruiting from all over is also more expensive. You may or may not need to fly people out, but you also have a lower rate of interest for the same amount of effort. On job boards you'll get 500 resumes, out of which 100 people actually realized the position requires them to move. For the low-profile startup it just takes more effort and money to get the word out to the right people across the country.
Was it worth it? Sometimes. In the end, you need to consider whether the position is really worth the extra time and cost of hiring or whether you can find local talent that will do as well. The issues I've raised above are obviously harder for positions where "telecommuting" doesn't work.
The whole point of the article is explicitly on hiring people who aren't willing to relocate - those who are eager to move to SF already make up the current market.
What are the positions where "telecommuting" doesn't work and reasons for that? The OP argues that for pretty much all development jobs that isn't the case, and gives examples of how successful companies have implemented this.
The mostly unrelated world population density map [1] really distracted me, partly because of how entirely wrong it is.
The map is actually of the populations of countries, not of world population density as claimed in the caption, and it's pretty aggressively thresholded, too. A density map would look something like [2], which is so dissimilar as to undermine any conclusion the reader might have drawn.
The reality is, there are not enough "best people" to go around. And, for that matter, it's probably arrogant to think that your idea is so hot that you need Google/Apple/Facebook-level talent. You are much better off figuring out which imperfections you can live with, ditching any lazy elitism ("only top schools") and looking in places that are not quite so over-fished.
In my experience having all local employees works well or having all remote employees works well. It becomes a logistical nightmare when you start to mix local and remote employees.
More than logistics, the problem is a cultural divide. 6 people talk to each other constantly, but the other 3 guys are stuck on chat.
There's also the problem of remoting requiring a different skillset. I know many developers that are very good, yet they are terrible remote developers. I know one that would spend her days tweeting or enjoying her boyfriend. Another one that will fight a problem for a week instead of asking a 5 minute question. Another will undertake major refactors without telling anyone. And all those three are amazing developers while on site: You just have to keep them on an extremely short leash while remoting, and they really don't like that.
I don't like the words you're using to describe the people in your second paragraph, it doesn't sound like a problem with skillsets as we normally think of the word, or culture necessarily, at least the "culture" of workplaces.
It sounds like these people have to be on a short leash, period. It's just that the leash is implicit on site, but has to become explicit in a bad way when they're remote.
Although I do empathize in other contexts (especially the long term unemployed, or those not making it into the job marketplace) the general "skillsets" of working, of "showing up on time", being diligent, properly subordinate to your superiors, etc.
It depends on the culture. I'm one of 3 remote employees at my company and there's no support from management or recognition that remote is different. It makes it tough. I'm the only dev on my team that signs in to IM reliably.
That must be frustrating, have you tried bringing up your concerns with management? Sometimes they just don't realize you're having difficulties until there is a major issue.
Yeah I've brought it up to management. The lead dev on my current assignment doesn't like to use Skype because it "slows his computer down"
I tried to get a yammer site going but it died as well. My boss said that he prefers face-to-face interaction so I got a high-quality webcam but it's already enough of a pain to make sure he has his microphone plugged in.
-.- sounds like lazy management to me. It really shouldn't be that hard for you boss to be available on a video chat service when he knows he has remote workers.
it's more like management that's too busy working and not managing.
that might sound ridiculous but the CEO is the lead PM on the biggest project we've ever taken on as a company. He's so busy going to planning and user meetings and managing the requirements that he doesn't have time to work on the company. I love the work and I live in the middle of nowhere which are two lame reasons I haven't seriously pursued other options.
It's hard only hiring the best and brightest as I assume there is only x% of people who you qualify as best and brightest. How many other companies are you competing with to get this so called "best and brightest"?
> How many other companies are you competing with to get this so called "best and brightest"?
If you're willing to hire remotely and hire from your online community as Jeff suggests, you're competing with surprisingly few companies.
I'm part of a small Microsoft SQL Server consultancy, and competition for good database performance tuners is notoriously difficult. However, when we publish a blog post that we're hiring, we get overwhelmed with applicants. Most of our competitors require an onsite presence, make the employees show up in an office from 9 to 5, and hire in cities with high costs of living. We don't - so we don't end up with much competition for brilliant people who just happen to have family ties to smaller communities.
With so many companies infamously doing a bad job of hiring and managing people, if you're good at both, I don't see why it couldn't be achievable.
Sure, plenty of those companies say, and maybe even think, they're "only hiring the best and brightest", but if they're wrong, or not good at retaining them....
The existence of articles like these seems to suggest that there really might not be that many people out there competing for the best and brightest (competing effectively anyway). If only 5% of companies are willing to pay top dollar, and only 5% of those are willing to allow remote, there may not be that much competition left over.
I guess the problem many companies/startups have with international workforces is: how do I deal with local laws/taxes? Do I need to establish a branch in the country of the prospective employee? Do I need a bank account in the country or can I use one European bank account for all my European employees?
Does anyone know of a company/startup which provides "remote employment as a service", including managing payroll, days off/holidays, local law/tax compliance and the whole slew of paperwork?
For me the simplest way to work for from EU to a USA company would be to register a mini-company for myself. I don't have one, but many freelancers do it just for local customers, because you can get a bit of tax savings that way.
The process then is simply making a periodic invoice from my company to yours; the ongoing costs involved would be whatever an international money tranfer costs for you, + I'd pay something like $50/mth to a local accounting company to handle all the taxes&reporting for that.
I don't know of any full "remote employment as a service", but there are a lot of outsourced accounting companies who'd do the taxes & paperwork - most local small businesses do it this way, since there's not enough work to have a full-time accountant/finance person on board. Actually executing payments and managing days off is a bit trickier, since the first requires full access to the company funds, and the second involves managing people, which is hard to outsource - you probably could get them to calculate 'what is owed to whom' by the local laws, but you'd have to pay salaries yourself & schedule vacations directly with the employees.
This however doesn't grant you days off - if you don't work you don't get paid.
Also, at least in Germany, if you only have one client/customer, you're vulnerable to committing a tax/social security offence called "Scheinselbstständigkeit" (roughly: faked entrepneurship), as you'll end up paying less in taxes, social security and insurance than a full-blown employee and people have abused this in the past to maximize their profits on cost of the employee or the systems.
Sure, this is the 'contractor' approach where you bill for services provided at a higher rate than a pure salary, and pay for your vacations/sicknesses/whatever out of that.
As for that "Scheinselbstständigkeit", I believe most other countries have some similar legislation. It's not an issue with freelancers as you have rotating clients, even if it's only one at a time; but yes, if you're creating it just for a single employment then that can be treated as tax avoidance - having the employer run a shell-subsidiary-branch would be preferred in that case.
This part is absolutely a pain. You are supposed to set up (or contract with) umbrella corporations that can handle local taxes, etc. Most reasonably large countries will have an agency willing to do this.. for a fee of course.
If you get, say, Facebook or IBM or Microsoft large then you just have lots of regional offices to handle this.
Hiring the best and brightest presumes that you, the employer are the best and most successful.
On both sides of the table, society constantly pushes us to think we're number 1 when we're really not. Non-top-tier companies and top-tier companies shouldn't have the same hiring practices. Nor should non-top-tier applicants and top-tier applicants have the same recruiting strategies.
Can we all stop pretending to be something we're not? The world operates on a normal curve and not everyone can be the 1%.
That said, if you are the top employer, I think a great metric is simply to gauge the time an audition takes. A technical problem for the best and brightest might take a couple of hours, whereas for someone less qualified it takes much longer. And this exercise should come with suggested timing to weed out people who know they're not able to crack it in the allotted period.
I think this could be a way to not have long term auditions, because what you've done is focused on creating a quality-assessment (difficulty of problem) as opposed to a quantity-assessment (length of time).
I disagree with what other commenters have said; having anything but long term auditions will not sufficiently gauge fit with corporate culture. But hey if you're going around the world to hire remote workers, culture is probably not your top priority anyways.
I've taken a different approach to the audition -- I have something that would take a developer 8 hours to do: something that we do in the core product, but, in an entirely different context.
For example:
"At LowBudget Brands, we provide reservations, customer support, front desk software, and backend support for property owners who want to own a successful hotel brand. A large portion of our travelers may not know which television station to turn to or have their smartphone or other device know set to the local weather, so, LBB wants to build a solution that:
-> Provides Hotel managers to create an account that allows them to set their property number and zip code
-> Queries Weather Underground to determine the three and five day forecast for that zip code
-> Generates a single page .pdf file with that content
-> Mails the hotel the day's weather at 3 in the morning.
"
If you've gone through the interview process, we know that you have experience with API's, background tasks, and PDF generation...or two of the three. I pay a flat rate of $200 for this task, and then we throw it away once they're either hired or we decline.
We provide a Vagrant file and an amazon t1.micro instance if that's easier, and that's proven to suit our needs rather well...
1. Its realistic. It has a customer and it has needs.
2. You're prepared with the resources needed. [You've thought about this before]
3. You're willing to put your money where your mouth is. I get the feeling that many of the lengthy coding tests or auditions are nothing but timewasters for punishing a new applicant.
4. It sounds like a weekend project/take home exercise.
Don't complain about not finding the best engineers if you're not an engineering-centric company; by definition, you don't need the best, you just need good enough. There's nothing wrong with this.
I don't think I have the guts to call myself the best and brightest lol. Does that mean I'm never going to find a job? Seems like every company insists on hiring the best and brightest, and everyone here thinks they're the best and brightest.
I feel about the same. Looking around me I see I am maybe top 25%. There are a couple of really smart people, and a fair few that I would classify as below average.
Of course we can't. Practice is critical in mastering a skill, and frankly as an industry we really don't practice the skill of recognizing the best people. At all.
Hiring processes throughout the industry are entirely non-rigorous, and there is almost never any loop-closing when it comes to hiring signals and eventual job performance.
We are spectacularly bad at recognizing talent because we've never sat down and rigorously connected signals to success and failure.
Tech hiring is the ultimate cargo cult. It goes through fads (remember when logic puzzles where the thing?), and works primarily via arguments that sound logical but were never even remotely verified. It's monkey see monkey do at a mass level.
I hate the hiring process. I've been unemployed all my life, and an interview feels like pop idol. Everything is about the looks, the communication, what are you flaws, what do you like, why do you want to work here, etc.
Maybe it's because I live in france and that employers can't easily fire people, maybe I'm not the "best and brightest", maybe I'm bad at communication, maybe I can't manage to sell myself properly, maybe I have issues.
It feels like buying somebody to be a friend in a club, not paying him to do some work.
I think employers like to hire people "they can trust", and I find it stupid. It's normal at first, but I wonder why there aren't any company trying to hire people who are not likable and finding ways to make the company work. I mean a company is not a group a friend doing chores and having coffee, of course you need people to behave a little, but I don't understand why it can boil down to simply exclude elements that can create "awkward situations that can put the company in danger".
.. you're also not hiring the best and the brightest because you aren't paying enough. Top talent knows what it's worth and enjoys those rewards .. finding them through consulting, banking, or entrepreneurship.
Only the mediocre are going to settle for $160k/yr + options at some "me too" A16Z startup.
Depends if that start up is a 10 min to walk to work and you say have a wife and newborn child to support some times you will take any job.
And some one really good might take a CTO role at a me to start-up to tick that box make your mistakes where it doesn't matter then move on to bigger and better things after 18 months 2 years.
For some reason I can't quite articulate, I find just about all "how to hire" advice is mostly a mix of platitudes, anecdotal evidence, weighed down heavily by personal opinion. In short I don't find much if it useful in actual practice.
I suppose this is true of most entrepreneurial advice.
Interesting points all around. As someone working as a remote consultant; rarely if ever meeting the clients in-person: I dig this. It's interesting this culture culture where the masses have these obnoxious, noisy, single room shared workspaces where they invite employees to "collaborate". Working on-site as a requirement simply has to go.
One problem I personally have with most remote jobs is they don't give me the same social security as I have in my own country, and don't allow me to pay my taxes locally. I want to support the community I am living in, and know that community to have my back.
I'd rather hire people who are good, and can do the job, rather than snag the all-stars.
Driven people with practical applicable experience are all the more worthwhile to me than folks who while smarter and brighter, often need an external source of motivation beyond a paycheck.
"I’m talking about a real world, honest-to-God unit of work that you need done right now today on your actual product."
This bit sounds unethical. Your asking someone to do work for you without paying them.
Exactly what happened to me. I interviewed with a company from a position of weakness (I had been out of school for several years and worked as a recruiter then Katrina hit, so I was flat broke and out of a job for a year) and I was looking for my first real programming job. They had me build something for them that they decided they needed but that no candidate had been able to create so far. I built the tool in a couple of hours, learning the language along the way. They turned around and used the tool in production without compensation.
Does anyone else have an issue with the world population map claiming the Russian steppes have a population density on a par with the South East of England? Or am I bad at reading keys on maps?
Rapid development by McConnell has loads of examples of where co-located teams are by far the best solution - And my several decades of experience I woudl also agree.
Thanks. My gut tells me there are advantages for both, but that it's at least somewhat situational.
How do you feel about the fact that the book is quite dated. I mean our ability to be integrated into the team, information and workflow while working remotely has improved by leaps and bounds since 1996. He's referencing a time before, DVCS, team chats (IRC I suppose), shared work boards like Trello/Pivotal, DropBox, Google Docs, Github, screen sharing. The list really goes on and on.
wow first time I have heard real sense on this topic from a SV VC. the other option beyond remote work is to physically locate your company out of SF and near the engineers (like we did!)
Now imagine that I've applied to five companies. Each of those five companies has given me an "audition," something that I can take a week to do. I necessarily have to do this in my free time -- I can't very well do it at my current job! -- and not only do I have to solve your problem, but I generally have to do it within some sort of constraint that you normally have, whether that's your codebase or your language or whatever. I'm going to spend a significant portion of that time simply getting up to speed with that constraint. Maybe I have to install Ruby or I have to install Symfony or I have to study the documentation for Twilio. Who knows?
I've never yet had an "audition" like this that didn't require me to sign an NDA, then install that company's codebase and work within that codebase. And I've rarely been able to do this in one or two nights of work. Usually one night of work is spent simply installing it, the second night studying what's going on, and then the third, fourth, and possibly fifth nights actually fixing the problem, testing it, and making sure it's good enough to submit.
It's a lot of work to ask me to do, even if you're paying me as a contractor, because again, I'm not looking to be a contractor. I'm looking to be a full-time employee.
I want to solve your real-world problems much more than I want to answer academic questions, but at the same time, you have to respect my time as well. I don't want to waste your time by not giving you enough data to make an educated decision about hiring me, but you should also not waste my time by giving me a task that takes up my entire free time for a week.
There's a happy medium here. I don't know what it is, exactly, other than letting me solve the problem my own way with my own code and my own tools, but if I do that, then it's not "something you would give your employees right now if they weren't so busy," right? Maybe.
The rest of it is fairly spot on, I guess.
Just my two cents.