Great list. One thing I want to add/emphasize is to consider the remote worker's motivations.
I'm personally not driven by money (it's just a means to an end). So a shortcut to getting bites on a job posting is to understand that there are people working in your field who may very much like to work with you. But they are deterred by past experiences in the office that drove them to work remotely in the first place.
Here are a few things to consider with freelancers:
* They are often most productive outside normal work hours
* Roughly half their time is spent doing research and keeping up with the latest trends
* They probably left the workplace to bootstrap their own startup someday
* Their productivity usually goes down if they are on call or interrupted often
* Beware loose specs and feature creep or you might burn them out and lose them
* Their productivity is limited more by time and money than challenge
* Sometimes they solve problems completely differently than you imagined and that’s ok
* Their short game might stink in some areas so balance them with administrators that take care of formalities
* Self-actualization can be more important for them than recognition
* Perks and benefits probably aren’t in their vocabularies unless they have families to support
For example: I love where I live and I'm not leaving. I own the house where I was raised. My grandparents are within walking distance. My parents, some siblings, and other assorted relatives live in this city, and my wife's family is within an easy day's travel. It's got my favorite sports teams, the church of my childhood, beautiful outdoor spaces, an excellent school for my son right down the street...
So I'm not motivated by your company's "great location" in the NY, SF, or Boston area; in fact that's a deal breaker for my family [0]. I'm not motivated by a 50% higher paycheck, most of which would be eaten up by higher taxes and cost of living and flying out here several times a year to be with family. I'm not motivated by a "hip" project that helps people go clubbing or hook up or share more selfies or other things that aren't really interesting to me in my current life stage. If that's your company, target other developers -- but if that's not your company, and you market yourselves like it is, you might lose me. One of my biggest motivations is being able to stay where I am and live a nice quiet comfortable life with my family.
The best fit is a hard challenge with clear requirements that requires expertise in multiple programming languages and paradigms, graduate-level mathematics or logic skills, ongoing learning and self-development/reflection, and that would benefit from long uninterrupted stretches of focus at whatever time of day is most convenient (might be 8pm-4am sometimes.)
[0] I'm a stay-at-home dad; my wife just started a new remote position. You can think of this section of the post as written from our joint perspective.
> Sometimes they solve problems completely differently than you imagined and that’s ok
sometimes this is okay, sometimes this isn't okay.
i've seen situations where there is a clear and coherent specification (use django, make a web app, have it call these APIs) to be implemented and the remote contractor completely deviated from it without telling anyone, wasting 2 weeks of time (delivered ruby, not a web app, using different APIs). this was done under questionable-at-best circumstances, saying one thing, and doing another, shirking responsbility for things that didn't tickle the guy's fancy, etc.
as a manager you need to be able to terminate and cut sunk costs or one person can derail an entire project. toxic people who say one thing and do another rely on the inability of management to make decisions like that.
As a freelancer I agree with all of this. A few things I'd add:
> * Roughly half their time is spent doing research and keeping up with the latest trends
Depends a lot on current workload. Generally speaking I think freelancers spend more time learning than in-house people do. BUT maybe that's just a top-performer vs. normal-performer trait and top-performers correlate well with freelancers for various reasons (the challenges usually come quicker and are more varied than at a company).
> * They probably left the workplace to bootstrap their own startup someday
Or just because they have the drive, discipline, and motivation to actually make it on their own. The freedom is pretty great.
> * Their productivity usually goes down if they are on call or interrupted often
This is true for everyone on the maker schedule. Even employees.
> * Beware loose specs and feature creep or you might burn them out and lose them
Depends on savviness of freelancer. Feature creep ain't bad at all if you're on retainer for X days/week. But sucks tremendously on fixed rate projects.
> * Sometimes they solve problems completely differently than you imagined and that’s ok
Everyone sometimes does this.
> * Perks and benefits probably aren’t in their vocabularies unless they have families to support
As a 27 year old cynical bastard I don't really need perks and benefits. Just pay me more, I can handle my own "free" lunch and stuff. Promise.
> Their short game might stink in some areas so balance them with administrators that take care of formalities
That's true of just about anybody. There used to be people that did this full-time (secretaries/admins). I'm not sure why you wouldn't want a dedicated one per dev team over a certain size (12?).
How do you deal with the isolation/loneliness of working remotely? After doing it for over 10 years I'm finding this the killer: sitting at home, me and my cat, talking to nobody.
Sqwiggle helps (seeing the rest of the team's faces) but it's a hard sell to convince others to use it.
> Also, in the job posting, ask them to apply in a unique way—don't just ask for resumes. Instead, try to make the application process prove their abilities for the job.
I can't think of a quicker way to turn down top applicants, at least in software, than asking upfront for work that is likely to be rejected. Even the custom contact forms on companies' websites are a drudge to fill in and usually not worth it. Candidates know this and won't bother. The best approach is to have a connect with LinkedIn or just a simple email that can receive resumes. Anything else might make it slightly easier for the company at the expense of losing out on qualified applicant.
I went through a round of applying for jobs on HN (based on the first-of-the-month posting), and the most common reaction from the company is no reaction at all.
I have this nagging suspicion[1] that many job postings are not done to find developers but just as a form of soft advertising to get the name out in the community.
[1] I'm heavily biased to find this true, even if it isn't, so be skeptical.
This comes up often on HN and I feel like most people who make these comment are missing the point.
Interviews are rarely about finding all of the top notch candidates. They are about finding N candidates who are a good fit. That's it. Doesn't have to be the best developer or best communicator, they just have to meet the needs of the position.
If one of Zapier's requirements is "you must really want to work at Zapier" then this is a perfect filter. It weeds out developers who are just looking at job openings, and only candidates who are excited about working there will apply. It doesn't matter if they miss 10k great ccandidates. They just need to find enough to fill their open positions
As someone working remotely, this line rubbed me the wrong way immediately:
> More potential warning signs are individuals who are poor at following up via email, forget when the interview was scheduled, or aren't flexible with an interview time.
Communication is a two way street. If you're looking to hire people remotely and you expect them to simply adjust to your timezone, you're setting up a bad remote employment relationship.
I've worked for years with a 10-hour offset from most of the people with whom I communicate, most recently with Heroku. A large part of what made Heroku attractive to me as a workplace was the pleasantly frank conversation about communication and limits. I'm generally available for meetings (my) 10p-midnight, which is noon-2p in SF. Otherwise, email / trello / hipchat / etc. Obviously, exceptions happen, and they really are exceptional (no "just this week" things that appear every week).
I've spoken to a ton of distantly-remote employees over the years and all of the stories that involved radical timeshifting on the part of the remote employee ended in a move to HQ or burnout and quitting — with a lot more of the latter.
It struck me as I read through the traits of "great remote workers" (wondering, as a remote worker myself, if I had these traits and was thus a great one) that it's never going to be easy to hire a junior developer - or a junior anything, really - in a remote role: in particular, the ability to prioritise is something that you can really only acquire with experience, and "propensity towards action" is a little pointless unless you're actioning the right things; likewise, many developers, in particular, take some time to get their written communication up to an acceptable level; and as for trustworthiness... well, a junior developer is just as (if not more) likely to be honest than anyone else, but would you actually really trust that they're doing it right, based on your past experiences?
This leads me to the conclusion that remote working is perhaps best reserved for those with a little more experience, and that maybe this great movement away from centralised offices may never quite materialise in the way that some seem to imagine it inevitably will. Perhaps I'm wrong though!
The email is not personal. It has a name and a few words (the "<insert something interesting they mentioned>") but it gives no feedback on why you are not hiring them. Reading the rejection email as someone who might be receiving it, it would leave me wondering and frustrated, and more likely than not I'd reply to ask why I was rejected. You're not going to hire me, there is no reason not to just tell me.
Maybe this is just American culture (they seem a bit less straight-forward with negative things than the average Dutchman), but the ever-polite "hopefully you'll stay in touch" is more annoying than nice to me. Staying in touch is regular communication, not a line you should say to everyone regardless of how terrible their resume was and how applicable they may be as a future employee in a different position when really you're meaning to say goodbye.
In America, if you discuss why a candidate was rejected and your reasoning can be interpreted as one of the many reasons that have been deemed illegal, you open up your company to being sued for discrimination. Given that your company will likely have many reviewers discussing many, many candidates, the only way to be sure no one ever slips up and gets sued is to have a blanket policy of never discussing why a candidate was rejected. Not with the candidate. Not even with people inside your company but outside of that candidate's hiring process. I have never discussed hiring process with a company that did not have this policy.
Judging from the comments I've repeatedly heard from Europeans, Americans are generally a lot more friendly to strangers than the average European. They are a lot more likely to reach out and strike up a random conversation with someone they have never met and will likely never meet again. Apparently, Europeans a more binary -lots of communication or none at all. Being open to any communication is the norm in America. Implying otherwise is unusual and indicates something is wrong. In practice, it's not expected that a very loose connection will actually say a whole lot, but the channel is never closed without strong reasons.
From all that, saying "stay in touch" is just being polite and making sure the other person doesn't get negative and assume you are thinking "I'd prefer to not speak to you again." -which would be an overly strong rejection (even if it's true).
I'm not sure why any venture backed startup, in an area that has local talent, would want to deliberately go the remote workforce route. It hampers your ability to scale, hurts your future acquisition chances, creates and will lead to communication redudancy, and culture distractions. It rarely works out positively.
In short, while I am sure that there are some instances where it works well (eg Basecamp / 37signals), I'd expect that they are the exception to the norm.
Note: I did build a remote startup with incredibly talented people and after a lot of soul searching and time required them all to come join us locally (or helped them find a new job elsewhere). Hardest decision we made at the company and certainly the right one.
NOTE 2: the best remote recruiting tool we had was to handpick whole invited to work with us. We hung out on mailing lists and read potential employees blog posts to see what kind of amazing open source projects they were sharing with the world, before trying to individually recruit them.
There is a recurring theme in this post about "putting candidates to the test" - sometimes simple testing in the hiring form (to select the ones with the highest intent) and them to "test with a project" to find out the best ones. I wonder if this is very practical for a company that isn't a popular/based-in-vally startup. I have a two part question: (a) How successful have you been in getting this level of engagement with candidates before you hired them? I would love to learn more about this. And (b) How well does this work for "non-programming" roles - that is, can you really devise practical projects/problems for people to solve. I know the business development example mentioned in the OP, but that is a small test in the form of a question - but I can't imagine what a real "project" for this type of role would be? -- sorry, thats 3 questions :) .. but I am curious to dive deeper into this aspect of the post.
I did a bit of testing at my previous employer, where I was the hiring manager, but it was in the interview (so candidates had no choice). I think that is a nice compromise--the candidate is fairly far along in the process, and you can still learn a lot about a developer with a small project. Granted, these were junior positions.
As far as (b), I have no experience in this, but I can think of problems for a non technical person to fulfill. If confronted with doing this, I'd just ask the hiring manager to list 2-3 pressing problems and have the candidate outline a solution to one of them. Maybe I'm missing the thrust of your question?
Here's a long story: I did a sample work test last week, limit 4 hours; it was for a LAMP developer position (if you check my post history you can see for whom!). The entire time I spoke with an HR rep, which I've no issues with but felt very impersonal. I was e-mailed the project and requirements, and there was no vagrant included. I had a few vagrant boxes of my own but I figured I'd just get a new one from puphpet... HUGE mistake. puphpet box requires latest version of Vagrant. Vagrant successfully updated after over 40 minutes (this includes Vagrant updating ALL existing boxes). New and shiny puphpet box didn't work. Try existing LAMP box, something went wrong with the update, it's broken. Too much time lost, install WAMP quick! Uh oh, missing DLL file... Installed wrong DLL (x64? x86? I don't even remember), 2 computer restarts. I had a dev environment after 75 minutes. Water break 5 minutes, I was now stressed out.
I spent the rest of my time with the exercise, already drained but the exercise was very simple which was encouraging. Unfortunately, 2.5 hours just wasn't enough: I missed two of the requirements and I wasn't happy with the UI. The framework for it all was already there, I used PDO prepared statements so I wasn't worried about SQL injection, but knowing that I didn't finish the project I knew my prospects went dim. Oh, and this was after work so I was coding from 8pm-12pm.
I sent it in, two days later, I received an e-mail from HR person saying I wouldn't be moving forward. Overall, a draining experience, nothing gained (usually talking to technical hiring managers you learn something), no consolation prize of a technical review on the project, no offer. I probably won't be doing one again
Depends on how much work it is. The company should put roughly the same investment of time into you that you do into them.
Also: involuntary unemployment happens in our industry. Sometimes it can take a while to find a new job. People who live in top-5 cities might say "any good candidate has offers three deep by the time they leave," but that's just their big city privilege speaking. Since we are talking about remote workers, most of them are in places where this isn't the norm.
So, anyway, if one is involuntarily unemployed, it's nice for there to be some employers out there who would say "here, spend 8 hours working on this," because it gives said-unemployed a chance to show off that they would be a good hire.
It has benefits and drawbacks to the hiring process, and I definitely worry what would happen if all employers demanded it regardless of the job market. But it sure beats "tell us about your last big project" and then waiting to make sure the candidate says the right buzzwords.
Personally, I would never do sample work, but perhaps I'm not the target candidate.
I've been working remotely for ... 8 years now? I've worked for startups through that time and it's always been companies that were already aware of my work.
I don't think I'd ever go through a proving process, but I've been doing this a long time. Perhaps for someone new, it makes sense to do that.
To me it feels insulting, and I've heard stories from friends that they've done sample work that has been used within the company, but they didn't get the job.
If the "sample work" only takes a few hours, then I think it is okay.
As an interviewer, I would much rather this than ask candidates a bunch of technical questions which probably don't relate too much to the actual job. I also get to see how they write code, use source control, etc. Then the interview time can be spent determining if the candidate has good communication skills, is a nice person, etc.
As a candidate, I would much rather a "sample work" test because I am a pretty good software engineer but often fail the brain-teaser technical questions. I would much rather have an opportunity to prove that I have the technical capability to perform the actual job.
I just updated the post to include some more context:
> The test should only take a few hours. We want to be cognizant of everyones time. If it is more than a few hours we always pay the candidate for their time.
Sample work in liu of interviews, of the same length, is ok. Especially if your already working and cannot interview during their work hours. Or an interview would be at midnight at someones location or similar.
Communication is absolutely key for remote teams to work. That being said, I often find remote teams using hip tools as a crutch for communication. We use Trello/HipChat/Hangouts/etc, but it doesn't mean Asana/Slack/Bootcamp/etc work as well.
IMO, I usually rate remote resources on the following:
- Are they a resource that will "finish my sentence"?
- Do they constantly set expectations about progress and milestones?
- Do they tell us when things aren't going well and need help?
- Do they update our communication channels frequently?
And we do this by putting them in a small project first and then moving forward after. The project typically has very little to do with code, but rather to see if the points are true.
Source: I've almost exclusively been running/working-with remote teams for 8 years now.
I have a question as a potential remote employee: If I live in a city with a very high cost-of-living, will it be difficult to find a remote position that pays reasonably well relative to my cost-of-living?
I assume one of the biggest benefits to hiring a remote worker is you can hire someone with a very low cost-of-living and pay them relatively relative to that. But if I'm living in a place with a high cost-of-living and the company can hire someone from any part of the world, why wouldn't they wait and find someone that's super inexpensive?
Because you should never compete on price, but on how good you are. If your only value prop is that you're cheaper than somebody else, you have already lost.
Remote teams is one of those things that can be a secret weapon.
I think remote work doesn't work for a lot of companies. A big part of what a company is is a culture and that culture is usually built around a physical place, for better or for worse. But, there is evidence aplenty that culture, great work and collaboration can be happen online. It's a new world and a company needs to find its own way, but if successful a remote working culture that works can be a secret weapon.
I recently wrote a small eBook about building distributed engineering teams, based on our experience in building the team that builds odesk.com (yes, we eat our own dog food and we've learned a lot along the way).
Yes! A very good overview of how to hire people remotely. Removing extra (often irrelevant) constraints such as location lets you focus on other more crucial things. Also, a remote team leads to more personal freedom, goal-oriented focus, and encourages that you work via a Asynchronous workflow and thus more efficiently.
Thank you for writing a detailed guide about your best practices. It is a long-term struggle to convince managers that good remote work environment can be done (and good for both their budget and their employees well-being), and such stories definitely help this effort.
Can't help but notice that 8 out of 10 of their accepted applicants' locations are in US. I've been wondering whether american startups even consider hiring somewhere from e.g. eastern europe or africa or central asia.
They do, but all things considered, it's simpler to hire within the US when possible. You keep similar time-zone, work with native english speaker (usually), and have a well understood set of employment laws.
It looks like they are looking for remote workers nearby
Location: Western Hemisphere.
If you want to work remote, that's cool. If you want to work near others, that's cool too. Our team is distributed across the world because it lets us work with the best people. You don't have to be located in the USA either, you just have to be talented!
They definitely do - I'm from EE (Poland) and I've worked remotely at a US startup, and now am discussing another remote position in another US startup. As long as you speak decent English and adjust your schedule so that there's decent overlap (ideally, full) with theirs, there's actually little difference between a US contractor and an outsider. Paperwork and taxes aren't any harder from what I've gathered.
[+] [-] zackmorris|11 years ago|reply
I'm personally not driven by money (it's just a means to an end). So a shortcut to getting bites on a job posting is to understand that there are people working in your field who may very much like to work with you. But they are deterred by past experiences in the office that drove them to work remotely in the first place.
Here are a few things to consider with freelancers:
* They are often most productive outside normal work hours
* Roughly half their time is spent doing research and keeping up with the latest trends
* They probably left the workplace to bootstrap their own startup someday
* Their productivity usually goes down if they are on call or interrupted often
* Beware loose specs and feature creep or you might burn them out and lose them
* Their productivity is limited more by time and money than challenge
* Sometimes they solve problems completely differently than you imagined and that’s ok
* Their short game might stink in some areas so balance them with administrators that take care of formalities
* Self-actualization can be more important for them than recognition
* Perks and benefits probably aren’t in their vocabularies unless they have families to support
By them I mean me, so YMMV..
[+] [-] lotharbot|11 years ago|reply
For example: I love where I live and I'm not leaving. I own the house where I was raised. My grandparents are within walking distance. My parents, some siblings, and other assorted relatives live in this city, and my wife's family is within an easy day's travel. It's got my favorite sports teams, the church of my childhood, beautiful outdoor spaces, an excellent school for my son right down the street...
So I'm not motivated by your company's "great location" in the NY, SF, or Boston area; in fact that's a deal breaker for my family [0]. I'm not motivated by a 50% higher paycheck, most of which would be eaten up by higher taxes and cost of living and flying out here several times a year to be with family. I'm not motivated by a "hip" project that helps people go clubbing or hook up or share more selfies or other things that aren't really interesting to me in my current life stage. If that's your company, target other developers -- but if that's not your company, and you market yourselves like it is, you might lose me. One of my biggest motivations is being able to stay where I am and live a nice quiet comfortable life with my family.
The best fit is a hard challenge with clear requirements that requires expertise in multiple programming languages and paradigms, graduate-level mathematics or logic skills, ongoing learning and self-development/reflection, and that would benefit from long uninterrupted stretches of focus at whatever time of day is most convenient (might be 8pm-4am sometimes.)
[0] I'm a stay-at-home dad; my wife just started a new remote position. You can think of this section of the post as written from our joint perspective.
[+] [-] beachstartup|11 years ago|reply
sometimes this is okay, sometimes this isn't okay.
i've seen situations where there is a clear and coherent specification (use django, make a web app, have it call these APIs) to be implemented and the remote contractor completely deviated from it without telling anyone, wasting 2 weeks of time (delivered ruby, not a web app, using different APIs). this was done under questionable-at-best circumstances, saying one thing, and doing another, shirking responsbility for things that didn't tickle the guy's fancy, etc.
as a manager you need to be able to terminate and cut sunk costs or one person can derail an entire project. toxic people who say one thing and do another rely on the inability of management to make decisions like that.
[+] [-] Swizec|11 years ago|reply
> * Roughly half their time is spent doing research and keeping up with the latest trends
Depends a lot on current workload. Generally speaking I think freelancers spend more time learning than in-house people do. BUT maybe that's just a top-performer vs. normal-performer trait and top-performers correlate well with freelancers for various reasons (the challenges usually come quicker and are more varied than at a company).
> * They probably left the workplace to bootstrap their own startup someday
Or just because they have the drive, discipline, and motivation to actually make it on their own. The freedom is pretty great.
> * Their productivity usually goes down if they are on call or interrupted often
This is true for everyone on the maker schedule. Even employees.
> * Beware loose specs and feature creep or you might burn them out and lose them
Depends on savviness of freelancer. Feature creep ain't bad at all if you're on retainer for X days/week. But sucks tremendously on fixed rate projects.
> * Sometimes they solve problems completely differently than you imagined and that’s ok
Everyone sometimes does this.
> * Perks and benefits probably aren’t in their vocabularies unless they have families to support
As a 27 year old cynical bastard I don't really need perks and benefits. Just pay me more, I can handle my own "free" lunch and stuff. Promise.
[+] [-] humanrebar|11 years ago|reply
That's true of just about anybody. There used to be people that did this full-time (secretaries/admins). I'm not sure why you wouldn't want a dedicated one per dev team over a certain size (12?).
[+] [-] porker|11 years ago|reply
Sqwiggle helps (seeing the rest of the team's faces) but it's a hard sell to convince others to use it.
[+] [-] atmosx|11 years ago|reply
hm, sorry, can someone translate that in too plain English for us non-native speakers! ty!
[+] [-] joesmo|11 years ago|reply
I can't think of a quicker way to turn down top applicants, at least in software, than asking upfront for work that is likely to be rejected. Even the custom contact forms on companies' websites are a drudge to fill in and usually not worth it. Candidates know this and won't bother. The best approach is to have a connect with LinkedIn or just a simple email that can receive resumes. Anything else might make it slightly easier for the company at the expense of losing out on qualified applicant.
[+] [-] danielweber|11 years ago|reply
I have this nagging suspicion[1] that many job postings are not done to find developers but just as a form of soft advertising to get the name out in the community.
[1] I'm heavily biased to find this true, even if it isn't, so be skeptical.
[+] [-] joncalhoun|11 years ago|reply
Interviews are rarely about finding all of the top notch candidates. They are about finding N candidates who are a good fit. That's it. Doesn't have to be the best developer or best communicator, they just have to meet the needs of the position.
If one of Zapier's requirements is "you must really want to work at Zapier" then this is a perfect filter. It weeds out developers who are just looking at job openings, and only candidates who are excited about working there will apply. It doesn't matter if they miss 10k great ccandidates. They just need to find enough to fill their open positions
[+] [-] idan|11 years ago|reply
> More potential warning signs are individuals who are poor at following up via email, forget when the interview was scheduled, or aren't flexible with an interview time.
Communication is a two way street. If you're looking to hire people remotely and you expect them to simply adjust to your timezone, you're setting up a bad remote employment relationship.
I've worked for years with a 10-hour offset from most of the people with whom I communicate, most recently with Heroku. A large part of what made Heroku attractive to me as a workplace was the pleasantly frank conversation about communication and limits. I'm generally available for meetings (my) 10p-midnight, which is noon-2p in SF. Otherwise, email / trello / hipchat / etc. Obviously, exceptions happen, and they really are exceptional (no "just this week" things that appear every week).
I've spoken to a ton of distantly-remote employees over the years and all of the stories that involved radical timeshifting on the part of the remote employee ended in a move to HQ or burnout and quitting — with a lot more of the latter.
[+] [-] bshimmin|11 years ago|reply
It struck me as I read through the traits of "great remote workers" (wondering, as a remote worker myself, if I had these traits and was thus a great one) that it's never going to be easy to hire a junior developer - or a junior anything, really - in a remote role: in particular, the ability to prioritise is something that you can really only acquire with experience, and "propensity towards action" is a little pointless unless you're actioning the right things; likewise, many developers, in particular, take some time to get their written communication up to an acceptable level; and as for trustworthiness... well, a junior developer is just as (if not more) likely to be honest than anyone else, but would you actually really trust that they're doing it right, based on your past experiences?
This leads me to the conclusion that remote working is perhaps best reserved for those with a little more experience, and that maybe this great movement away from centralised offices may never quite materialise in the way that some seem to imagine it inevitably will. Perhaps I'm wrong though!
[+] [-] lucb1e|11 years ago|reply
The email is not personal. It has a name and a few words (the "<insert something interesting they mentioned>") but it gives no feedback on why you are not hiring them. Reading the rejection email as someone who might be receiving it, it would leave me wondering and frustrated, and more likely than not I'd reply to ask why I was rejected. You're not going to hire me, there is no reason not to just tell me.
Maybe this is just American culture (they seem a bit less straight-forward with negative things than the average Dutchman), but the ever-polite "hopefully you'll stay in touch" is more annoying than nice to me. Staying in touch is regular communication, not a line you should say to everyone regardless of how terrible their resume was and how applicable they may be as a future employee in a different position when really you're meaning to say goodbye.
[+] [-] corysama|11 years ago|reply
[+] [-] corysama|11 years ago|reply
From all that, saying "stay in touch" is just being polite and making sure the other person doesn't get negative and assume you are thinking "I'd prefer to not speak to you again." -which would be an overly strong rejection (even if it's true).
[+] [-] rafe33|11 years ago|reply
In short, while I am sure that there are some instances where it works well (eg Basecamp / 37signals), I'd expect that they are the exception to the norm.
Note: I did build a remote startup with incredibly talented people and after a lot of soul searching and time required them all to come join us locally (or helped them find a new job elsewhere). Hardest decision we made at the company and certainly the right one.
NOTE 2: the best remote recruiting tool we had was to handpick whole invited to work with us. We hung out on mailing lists and read potential employees blog posts to see what kind of amazing open source projects they were sharing with the world, before trying to individually recruit them.
[+] [-] guybrushT|11 years ago|reply
[+] [-] mooreds|11 years ago|reply
As far as (b), I have no experience in this, but I can think of problems for a non technical person to fulfill. If confronted with doing this, I'd just ask the hiring manager to list 2-3 pressing problems and have the candidate outline a solution to one of them. Maybe I'm missing the thrust of your question?
[+] [-] physPop|11 years ago|reply
[+] [-] arenaninja|11 years ago|reply
I spent the rest of my time with the exercise, already drained but the exercise was very simple which was encouraging. Unfortunately, 2.5 hours just wasn't enough: I missed two of the requirements and I wasn't happy with the UI. The framework for it all was already there, I used PDO prepared statements so I wasn't worried about SQL injection, but knowing that I didn't finish the project I knew my prospects went dim. Oh, and this was after work so I was coding from 8pm-12pm.
I sent it in, two days later, I received an e-mail from HR person saying I wouldn't be moving forward. Overall, a draining experience, nothing gained (usually talking to technical hiring managers you learn something), no consolation prize of a technical review on the project, no offer. I probably won't be doing one again
[+] [-] danielweber|11 years ago|reply
Also: involuntary unemployment happens in our industry. Sometimes it can take a while to find a new job. People who live in top-5 cities might say "any good candidate has offers three deep by the time they leave," but that's just their big city privilege speaking. Since we are talking about remote workers, most of them are in places where this isn't the norm.
So, anyway, if one is involuntarily unemployed, it's nice for there to be some employers out there who would say "here, spend 8 hours working on this," because it gives said-unemployed a chance to show off that they would be a good hire.
It has benefits and drawbacks to the hiring process, and I definitely worry what would happen if all employers demanded it regardless of the job market. But it sure beats "tell us about your last big project" and then waiting to make sure the candidate says the right buzzwords.
[+] [-] AndyNemmity|11 years ago|reply
I've been working remotely for ... 8 years now? I've worked for startups through that time and it's always been companies that were already aware of my work.
I don't think I'd ever go through a proving process, but I've been doing this a long time. Perhaps for someone new, it makes sense to do that.
To me it feels insulting, and I've heard stories from friends that they've done sample work that has been used within the company, but they didn't get the job.
[+] [-] rpedela|11 years ago|reply
As an interviewer, I would much rather this than ask candidates a bunch of technical questions which probably don't relate too much to the actual job. I also get to see how they write code, use source control, etc. Then the interview time can be spent determining if the candidate has good communication skills, is a nice person, etc.
As a candidate, I would much rather a "sample work" test because I am a pretty good software engineer but often fail the brain-teaser technical questions. I would much rather have an opportunity to prove that I have the technical capability to perform the actual job.
[+] [-] WadeF|11 years ago|reply
> The test should only take a few hours. We want to be cognizant of everyones time. If it is more than a few hours we always pay the candidate for their time.
[+] [-] mahyarm|11 years ago|reply
[+] [-] mbesto|11 years ago|reply
IMO, I usually rate remote resources on the following:
- Are they a resource that will "finish my sentence"?
- Do they constantly set expectations about progress and milestones?
- Do they tell us when things aren't going well and need help?
- Do they update our communication channels frequently?
And we do this by putting them in a small project first and then moving forward after. The project typically has very little to do with code, but rather to see if the points are true.
Source: I've almost exclusively been running/working-with remote teams for 8 years now.
[+] [-] unknown|11 years ago|reply
[deleted]
[+] [-] tieTYT|11 years ago|reply
I assume one of the biggest benefits to hiring a remote worker is you can hire someone with a very low cost-of-living and pay them relatively relative to that. But if I'm living in a place with a high cost-of-living and the company can hire someone from any part of the world, why wouldn't they wait and find someone that's super inexpensive?
[+] [-] Swizec|11 years ago|reply
[+] [-] netcan|11 years ago|reply
I think remote work doesn't work for a lot of companies. A big part of what a company is is a culture and that culture is usually built around a physical place, for better or for worse. But, there is evidence aplenty that culture, great work and collaboration can be happen online. It's a new world and a company needs to find its own way, but if successful a remote working culture that works can be a secret weapon.
[+] [-] skasriel|11 years ago|reply
I recently wrote a small eBook about building distributed engineering teams, based on our experience in building the team that builds odesk.com (yes, we eat our own dog food and we've learned a lot along the way).
People can get it for free here: http://work.odesk.com/recruit-manage-distributed-engineering...
Hope this is helpful, I'd love to hear everyone's feedback about it.
[+] [-] EGreg|11 years ago|reply
[+] [-] syntern|11 years ago|reply
[+] [-] xentronium|11 years ago|reply
[+] [-] cedsav|11 years ago|reply
[+] [-] byoung2|11 years ago|reply
Location: Western Hemisphere.
If you want to work remote, that's cool. If you want to work near others, that's cool too. Our team is distributed across the world because it lets us work with the best people. You don't have to be located in the USA either, you just have to be talented!
1. https://zapier.com/blog/partner-engineer-liaison/
[+] [-] lgieron|11 years ago|reply
[+] [-] dharbin|11 years ago|reply
[+] [-] sethammons|11 years ago|reply
[+] [-] fernandotakai|11 years ago|reply
[+] [-] clebio|11 years ago|reply
> Not everyone is cut out for remote work...
sort of lost me somewhere between the lines.
[+] [-] EdwardDiego|11 years ago|reply