FYI: thoughts based on posting/studying CL ads, so application to SO may be limited.
Title
> ASP.net (c#) and Javascript Developer (Fast Growing Startup)
Straightforward title, like the inclusion of the type of company and type of work you will be doing (fast growing startup)
Job Description
> We're looking for a talented ASP.net (c#) and Javascript developer to work with us in our SW London office based in Twickenham.
Would probably include 'fulltime.' Would also suggest a short description of what the company does. You are kind of burying the lead by not saying "We develop a Windows program that lets anyone make HTML5 games." As a start up employee WHAT I'm working on is as/more important that what I'm doing in code.
Roles
> Develop our website
This is vague, are they working on a team? Make this more specific, are they in charge of design too? Do you have a designer?
> Help to develop a large separate Javascript web application
Also very vague, what would their role be here? How large is the team they would be working with?
> Perks
>
> Lots of opportunity for creative solutions to interesting problems
> We'll let you spec your own working computer! (within reason, we want you on the best stuff though!)
> Our website gets over 100k uniques per month and 1.2m page views, you'll often receive immediate feedback from our awesome community of game developers
> Pizza on fridays
These perks are rather vague/straightforward/drab. This is your chance to show your personality as a company (reframe in casual language you would actually use). For example: Instant feedback: with 1.2mm page views, if you push shitty code you'll know in seconds! (purely an example, do not advocate the word shitty)
> How we operate
>
> We're HTML5 evangelists!
> No dress code at all (as long as you wear something!)
> Highly flexible working hours (you might prefer 12-8 instead of 9-5, we can work with just about any hours you want)
> Open to the possibility of interesting side projects if you have any ideas
> You will be our first employee working at our fast growing startup! We're looking for quality applicants and are willing to pay a competitive salary to reflect this.
Again this is your chance to be quirky. "No dress code at all" could easily be "Wear what you want. We love nudists, just not at work."
You are hiding the salary talk at the end of the ad. This could easily be put as a bullet at the end of "how we operate" like: "Salary: we want the best and we'll pay you like we mean it." By hiding it down here, it is hard to find and I might miss it.
In general the thigns that people want to know:
- What I will be doing
- Who I will be doing it with
- Am I going to get money or equity?
Those should visually be easy to pull out. Roles does the first, you need to give them the other two.
> Skills & Requirements
>
> Must Have
>
> Highly proficient with ASP.net c# development
> Highly proficient with Javascript development
> Experience with Linq
> Experience with SQL Server
> Easy to get along with and love what you do!
Again a chance for personality. The more specific the better people with filter themselves out. Do you want someone with JS MVC framework experience, JS is a pretty big language with a ton of subtlety.
> Nice to Have
>
> C++ for Windows Development
> Enjoy making and playing games
> A sense of humour!
> About Scirra Ltd
Spice this up as well. Why is C++ a nice to have "we want you to help us write the games too!"
> Scirra was established in 2011 and we've been growing fast. We develop and sell Construct 2 in house, a Windows program that lets anyone make HTML5 games. To date, it's been downloaded over 200,000 times.
>
> Since day one of selling we've been profitable and revenues are continuing to grow. We're now looking for our first full time in-house employee!
In general I think that working in an area you have experience in makes things smoother especially in the beginning. You know the pain points without having to do any research and have some initial "instinct" that points you toward potential solutions.
However, I strongly believe the most important thing for an early-stage start up is passion around the space/solving the pain points. The main reason is that working in a start-up is really hard and, at times, soul-draining. If you hit that depression phase and you aren't 100% committed to solving the problem you'll never pull out of the death spiral.
That being said, if you're passionate, you don't have to be an expert as long as you commit to becoming an expert quickly. Tons of breakthroughs happen when intelligent novices enter a space without the preconceptions of the existing leaders.
While I agree that work samples are definitely the way to go, I'm unsure how you could possibly engineer a work-sample that is time effective for 600 people. Clearly, the first pass of the screen cannot be the work sample alone or you will be administering dozens if not hundreds, since I doubt the threat of a worksample in a job ad would scare many people away (could very well be wrong about that.)
I think this is why HireArt (YC W12), exists. They pre-vet these candidates using a work sample for you, presumably they only administered and graded the work samples of those they found passed the 'resume bar.'
As for false positives, from talking to many employers the fear false positives is generally low because they figure they can "weed them out" during the interview stage. And while there may be statistical evidence showing a high false positive rate, it is surprisingly hard to convince hiring managers of this.
Here is a simple example of how to automate this for developers.
Everyone who applies is sent a link. That link contains a problem description, and a stub program. You're supposed to write the program and send it back. When you send it back, they compile your program and run a standard set of unit tests on it. If it passes the unit tests, then a human looks at it. Generally the code will be "good enough" to bring the person in for an interview.
In the interview you will ask the person enough questions about their solution to give you confidence that the person you are interviewing actually wrote the code you are reviewing. This greatly shortens the interview process.
This is not a hypothetical approach. I know of more than one company that has actually implemented this.
You might think that it takes a lot of developer time to implement, but it doesn't. What you do is have a developer come up with a reasonable project that they think can be done in a reasonable amount of time. That developer then solves the problem. You take their solution and stub it out - that gives you the initial stubs people can download. The unit tests that they developed are the unit tests that you will use. And now you're off and running.
The problem is that the people you'd most like to hire probably have little interest in taking a programming test. So you're just filtering them out and left with the dregs. For this to work you need one of the following:
* Problems that are so interesting that people would hack on them just for the fun of it, even if they have no interest in the job.
* A company that's high profile enough (and in a good way) that they can have slightly abusive hiring practices and still get an abundance of good candidates.
* You're looking for inexperienced or desperate people.
The canonical example of using programming problems as a pre-filter was ITA software, who had both of the first points covered. There's some great discussion on this in the HN archives, e.g. http://news.ycombinator.com/item?id=3429231
>The problem is that the people you'd most like to hire probably have little interest in taking a programming test. So you're just filtering them out and left with the dregs. For this to work you need one of the following:
That may be the case if you're trying to headhunt experienced developers who are currently in good jobs.
But if you're an unemployed programmer, or an employed programmer actively looking for a different job, why wouldn't you take a programming test? Programming tests and technical interviews where you have to code are normal and expected for coding jobs, at least in my experience.
There's a big difference between a programming assignment used as a filter to decide whom to interview vs an interview question.
The hiring process is very expensive. But it's expensive in a fairly symmetric way. It's in the interest of both parties to stop the process if there isn't mutual interest.
Both the company and the candidate will spend a lot of time in interviews, so it's in everyone's best interests to make sure that time isn't wasted if there no (or almost no) chance of the person being hired / accepting a job.
There might be earlier steps in the process, but those are also symmetric. It'll take a few minutes of your time to send a resume to a company, but somebody there will be tossing away 80% of them after reading through them once. There might be a phone screen or two in advance, to decide whether there's any point in having someone come in for an interview, but that is likewise costly to both parties.
But a programming test as the very first step of an interview is totally different. Now the costs are asymmetric. The company has an up-front cost (potentially substantial) but spends little time on each candidate. The candidate spends the time up-front, and only later finds out whether the company is at all interested.
The candidate isn't invested in the process yet. So why would he spend an hour, when he has no idea of whether the company is interested? Maybe it's a really fun problem to solve. Or maybe he really, really wants to work at that particular company. Or maybe he is indeed unemployed like you suggested.
But someone currently employed is likely to have a different priorities from a student or someone who is unemployed, even if they are actively looking for a new job. How large a percentage of them are you willing to weed out completely just by making it harder for them to even enter the hiring funnel? 90%? 50%?
When there are 630 resumes in the pile, the read/filter will be done by a junior HR person who probably couldn't tell XML from SQL.
I'd rather be filtered by a programming test, where my programming abilities put me ahead of the pack!
With that said, most of the programming tests I've been given in the past have been fairly interesting so perhaps that biases my opinion. I'm certainly no fan of jobs where they send you a huge MS Word application form.
And I'd rather not work at a place where my resume alone doesn't warrant at least a phone interview :-) Either I really wasn't a good fit for the job, or they have a broken hiring process. If it's the latter, chances are that a company with that bad a HR department is also dysfunctional other ways.
Programming tests can indeed be interesting. Anyone feeling bored could do worse than to attempt solving something from ITA's hiring puzzle archives. But unless you're extremely certain that your tests hit the sweet spot, it seems really dangerous to make them a mandatory first filter. A test once both parties are at least a little bit invested in the process, sure. Or if resume screening really is a problem, allow someone to "skip the queue" by sending a test solution along with the application.
One of my top concerns if I'm interviewing for a company is, "Are these people going to be sufficiently competent to be fun to work with?" If the interview doesn't provide a good enough filter for incompetence, then I am going to not want to interview there.
If my first experience demonstrates that only competent people will get through, then that is going to improve the company in my eyes.
That said, it will slow hiring down. If you want to hire a bunch of people, you can't put a restrictive filter like that up. But if you just need a few, it can work out in your favor.
This is great solution and the impetus behind Interiew Street.
And while HN is a very programmer centric culture, most jobs can't be automated in this way. Look at the OP's job description, how do you automate that? And how does someone like the OP automate that process? Believe me, I would love to live in a world where every position in every company is able to command a great developer to build a customer filtering solution, but most companies in the valley (much less out of it) won't invest this time/infrastructure. Hence the rise of BS keyword filtering systems. I'm personally very interested in solutions that can make this process better, but it's a highly non-trivial problem in most subject areas.
While the competition in these situations is not often that broad (though there will always be a few ivy leaguers in that mess), the real problem is the noise factor. The chance that your resume even gets read is slim due to the fact that it will take many hours to go through 600 applications.
The much sadder reality is what actually happens in a company that posts that ad:
1) Optimistically post the job ad.
2) Receive hundreds of responses within hours of posting it.
3) Begin going through those hundreds of responses, reading cover letters and resumes. At first you're pumped then you realize very few people here are qualified for the position/read the post.
4) After ~20 resumes, you close your email for the day. If you made the mistake of using your personal email address, I'm sorry.
5) Despair. Pick and choose random emails (maybe filter by email, are there any harvard.edu's in there?) and immediately call the first person who seems remotely OK. Iterate step 5 until you find 'the one.'
I've worked with/observed dozens of employers in this process, a tiny fraction of resumes actually get read, and frankly it's impossible to stay focused through the experience. A "fun" experiment is to print out 40 resumes in a pile, write a job description for those resumes and then try to find the most qualified one in that bunch. Free-text association with often poorly-articulated job requisitions is a nearly impossible proposition. Add in the step where you have to download and track those applicants, and it's damn near impossible to use Craigslist to find the best candidate.
This was the original inspiration for our company, Foundry Hiring (www.foundryhiring.com). We're trying to build tools to make this process as painless as possible. In this instance we will give you a free link to post in your CL ad which has an application form in front of it, so that emails don't hit your inbox, the applicant's are stored directly in our database. We then give you tracking tools on top of it to make the process better. We're still in beta, but I would love user feedback.
Adding hurdles will definitely reduce the number of applicants, but what you'll find is that if you ask for X, Y, Z in the ad most people will still send you whatever they were going to send you before (most likely a resume and coverletter). You then know they didn't read the ad and thus should probably be deleted.
This is why lots of job ads on craigslist say: "write XYZ in the email title" buried in the text to filter for those people who aren't even reading the ad.
The comments have become a firestorm of grammar-as-a-filter for programmers. While this is an interesting debate, I think there are three things about this filter that give it value:
1) Grammar serves as a cultural touchstone in the company, so using a grammar test in hiring is a strong signal to employees and future employees about what we as a company stand for. If you apply to this job and you disregard grammar freely (guilty as charged) you will not fit into this organization. It's a fast filter on both ends: I won't take the test, and if I did you would reject me immediately. Excellent.
2) It is a binary, non-complex test. You write the test once and there is a unambiguous right and wrong answer, if you get the questions right you pass, if you don't you are rejected. This has several benefits:
Applicants: They know this is coming and can prepare/not prepare for it. The test is objective, so they can't really argue with its validity. At one point they probably knew this material, meaning that an hour of time to prepare for the finer points of colons/semi-colons is probably doable if they really want the job.
Employer:
Since the answers are unambiguous this filter is easy to use: passed candidates go through. There is no subjectivity around assessing a candidate using a resume or cover letter. In my experience (CEO in hiring efficiency space) this easily-actionable filter means that the task at hand will actually get done. If you watch recruiters try to parse through 200+ resumes against a job req, they will stop after 10-15. They might come back to it on another day, or they might not. Either way the applicant pipeline stops dead on their desk. It's frustrating for the recruiter because the task becomes "analyze this free-text against a free-text requisition and then filter this list of 200 people down to 20."
The reality of this situation is that most resumes don't get read and the person who ends up getting the job is one of the first 20 that were read. Obviously this situation is non-ideal, so I generally advocate an objective, simple filter as the first step to any process (before looking at resume.) Internal recruiters, in their heart of hearts, want to find the best applicant in the bunch, if you don't give them the tools to do their job then they won't.
3) They've thought about their process and institutionalized it. When I see a company that has thought seriously about the filter stage of the process then I know: a) they care about their employees' time b) they care about quality applicant's and the culture they project in the hiring process c) they have probably thought about all stages of the hiring process so things are likely to move quickly and smoothly.
This is an excellent point. The analogy I like to use is based on prospecting: you can try to find fully-formed gold from the earth or you can smelt down ore into something useful. Right now the valley is full of prospectors stealing gold nuggets from each other, and I think there is a ton of opportunity to transform smart, hardworking people into great employees.
Of course this requires time and training, which some start-ups feel they can't afford. In the end I think it's worth it to focus on finding talent that can learn quickly rather than emerge from Zeus's brain fully-formed.
Sadly, I think this is right. I know several recruiters at a big-name recruiting agency in Silicon Valley, they try to act like an internal recruiter (thorough vetting of candidates, understanding company culture, etc) and they make much less money than if they had just adopted the pay and spray mentality of their peers.
The bright hope for me is darwinian: if enough startups refuse to use these pay and sprayers then they will die off, leaving only the higher quality recruiters. Will that happen? Not any time soon.
