Ask HN: What makes a job posting attractive? | Hacker News Reader

Ask HN: What makes a job posting attractive?

53 pointsbkrausz65 comments

While writing the job description for GazeHawk (P.S.-we're hiring PHP/Python/UX hackers - brian AT gazehawk.com) I realized that most job descriptions are generic and boring.

I'm wondering what attracts you guys to a particular job posting?

Do job postings even matter beyond that fact that company X is hiring? Does a posting with descriptions of the company culture, future plans, values, etc actually mean more than "PHP/Python hacker for YC startup"?

Looking forward to your feedback!

View on HN

It's not just what makes them attractive, but also what doesn't make them suck.

The biggest turnoff is the sight of stringent, fascist language for benign requirements that can be met by anyone who bothers to do a basic preparation. "MUST be able to come to an in-person interview. Do NOT apply if you can't come in" -- why is that even a requirement for an on-site job?

Other gems are:

Equating completely unrelated qualifications "Minimum: masters in computer science, or Red Hat certification".

Being sticklers for dipshit, minor-celebrity tools that anyone with half a brain can pickup on their taxi ride to the interview: "MUST be able to use JIRA/Trac/Redmine/Bugzilla; MINIMUM 10 years".

Offering me $30/hr, with no other benefits, while enticing me with the usual fare of juvenile delights: pop soda and foosball. Specially when you're the 40 y.o subsidiary of a Fortune 500 conglomerate.

Hiring for systems design or knowledge transfer, while insisting on specific tools to be used: "we need a consultant to advice us on global on-demand video advertising delivery, and recommend architecture and design insights .. MINIMUM 10 years Oracle. 10 Years Java. 10 years Perl. 10 years C++. 10 years Sybase. MS Office. Photoshop. Batchfiles" .. you can just tell whoever wrote this has no clue what the solution might entail, so he adds everything he remembers from MIS 101, and requires it all from the guy who will be most likely working with biz analysts and delivering nothing more requirement documents, and possible the first few job ads for the future team lead and project manager.

* No time for bullshit, please just put the salary there. A range that is open to bargain is fine too. Prorated is fine too. We just want some idea as to how much you want us and how much we'll be making. No point beating around the bush. The 5k or so that you might lose from not having bargain space might actually turn a great investment if you end up hiring a better candidate.

* Don't list every technology you may or may not use as required in the job posting. Either post for a specific job or spell it out that you want a fast learner and wearer of many hats, and say "these might be useful".

* Don't require X years of experience. This is as stupid as the drinking age limit: You aren't suddenly much more mature the day you turn 21. What does "experience" mean anyway? Experience in what? Spell out what sort of skills you need.

* What are we going to be working on? What is interesting about it? Hopefully it's something more intriguing than "building a blog engine" for the billionth time. It doesn't have to be cutting edge, but even the most seemingly mundane tasks can have interesting technical aspects if they are nontrivial.

* What sort of environment is it? Can I show up in my jeans and take a break during the day? Do you care what days / hours I work as long as I put in my 40h / week? What are my peers like? Are they young up and comers or grizzled bearded veterans of the unices? What sort of development process do you have? What points of the Joel Test (look it up) does your place pass?

Upvoted for the upfront salary listing. I've ignored many a job posting due to this. Let me know if it's going to be worth my time up front.

Realism. Nothing is more bothersome than buzzwords and bulleted lists of cross-disciplinary requirements that no person you would actually want on your team could fill.

Speak Human.

attractive to whom? know your audience. even among HN members, there's a huge range of what "attractive" means.

figure out who you want to target, very specifically, then figure out exactly what they want out of a job.

The following is my paraphrase of dotBen's comment, with "if statements" instead of "dont's":

if you want people who care about degrees, require a degree.

if you want people who care about the exact number of years they worked at some job or with a language, add it to your requirements.

if you want honest down to earth people, then be honest and down to earth.

if you want people who are cocky enough to label themselves as "rockstars" or "ninjas", then ask for it.

... list goes on

I personally think this is common sense, but as they say, common sense isn't common.

The most important thing? Hiring is a two-way street. You're shopping for employees, we're shopping for employers. Your job description is like an employers resume. If you want honest applications, then give us an honest description of what you want. It would seriously MAKE MY DAY, if there was a job listing that said straight up what you were going to do, i.e.:

"we need someone to work with us on a team of 5 to implement our new web API within 3 months and provide support afterwards. If you suck, we'll fire you. If you're good, we'll move you on to whatever new stuff we might need help on like a potential mobile platform..."

at which point it would be very easy for me to say "yeah that sounds awesome! i can do that for you!" or "fuck that i got better shit to do." either way, we'll both get exactly what we want, and I won't be trying to fake my way into a job I don't deserve, and you won't be questioning whether I'm actually good enough.

The top-rated comments have a lot of good info, but I'm going to boil it down for what I look for:

40 hour workweek. Overtime only happens during an emergency. That means you NEVER schedule overtime.

Accurate requirements and bonus skills. Don't ask for 7 years in a language that has existed for 4 years. Make it clear if experience in other languages is acceptable, and the candidate can get up to speed on a relatively new language on the job. For a good programmer, this isn't hard.

No fancy language. No 'rockstar' or 'code ninja' talk. Anyone who is realistic about their skillset will not call themselves that.

Flexibility in interviewing. Good programmers already have a busy life. If you want them, you have to work with them. Especially if they live any distance from your office. Be willing to interview via internet/telephone first, and have them travel only if necessary. (I once had a guy 3 hours from me ask me to a lunch interview. I declined because I figured he was just milking the company for lunch and had no intention of hiring me.)

Adequate pay. Benefits are nice, but they don't put food on the table. And with enough pay, employees can buy all the benefits I want. As someone said earlier, your foosball table isn't on my list of requirements.

Unit testing. Without unit testing, life is a LOT harder.

Don't play games. If you say you'll call someone back, do it. Don't wait for the candidate to call and 'ask for the job'. That means they're desperate, not that they're good or loyal. If an interviewer tells me that they'll call me, I hold them to their word.

The above are the absolute necessities. Below are things I like to see:

Languages/environments that I enjoy. If you deploy on Linux and run Ruby, those things interest me. Showing that you are on top of the newest technologies or methodologies means you are open to improvement. This is also good.

"Challenging". I hate boredom. I never want to be bored. I would much rather go home exhausted from all the thinking than have enough energy that I feel like coding at home. And I do code at home when I'm bored at work.

Telecommuting. I find that I don't choose to do this, but companies that trust their employees enough to do this are better to work for. It also probably means they have a way to measure whether someone is working or not that doesn't involve a rat. That means things are a little more fair.

Unit testing. Without unit testing, life is a LOT harder. Why don't people truly subscribe to this practice? It makes so much sense to put "bracers" around your work to insure its integrity. Check out this white paper if you want more information, I found it useful: http://www.parasoft.com/jsp/products/article.jsp?articleId=2...

A job posting is attractive if a friend who works at the company IMs you about the job, tells you how great it would be to work together, and then casually includes the link so that you can get some background information and feel prepared when you go in for your interview.

I always have trouble writing job descriptions because I feel like the default approach boils down to writing marketing copy for people who think job postings are full of shit. I bet, it'd be easier if I just put myself in the frame of mind of answering, "what information do I want the candidate to be prepared for when they come in for an interview?"

A good start: show that you pass as many Joel tests as possible

http://www.joelonsoftware.com/articles/fog0000000043.html

Actual salary range. Important. A "competitive salary" in 2010 for an embedded systems designer is not the 50th percentile for HTML coders from a 1996 salary survey. If you have incredibly specialized skills that you've been unable to hire for, competitive is going to be 6 figures and not the low end.

No long lists of very narrow technologies each which really only require a few days to get up to speed.

Brief description of work environment such as offices with doors that close, book account or some sort of library, reasonably modern computers with dual monitors each at least 1920x1080 plus a laptop, and no complaints about getting whatever text editor and tools the developer prefers to work with.

Relocation paid. If you are looking to hire someone who is good and with specific skills, he is not in your weird city nor does he wish to subsidize your cost of hiring.

Pay for cost of interviewing for final candidates that you need to come to site interviews. For those ones you'll want to sell the area as well since they have no idea why anyone would want to live there, wherever 'there' is.

Not paying the above two tells the candidate you probably won't be able to make payroll either.

Be very willing to receive screening calls that ask lots of personal specific questions and answer them enthusiastically, just like you are trying to sell an expensive item to a very important customer.

And finally, don't rely only on ads. For specialized skills you need recruitment, and there's no way to figure out who you want to woo unless the recruiting is done by someone who knows development, not some know-nothing recruiter from an agency, nor some HR drone. Again, recruitment has nothing to do with recruiters. Recruitment is saying you need someone with the ability to build System X, then you find someone who is already doing that and pay him $20 million to buy his company as a talent acquisition.

I am no longer an employee but an owner. When I was an employee I looked at ads but found them useless for many of the above reasons. As an owner I write ads and do recruitment and we have little difficulty hiring exactly the talent we need. Pretty much all companies that have problems finding talent aren't offering enough money and are not good places to work in many ways. Places that pay competitive and are good places to work have no shortage of highly qualified applicants. Yes, you'll also get a lot of unqualified applicants, but how to tell the difference is a topic for another day. (In short, if you can't tell the difference you're doomed since you'll hire a bunch of duds and then the few with actual talent will leave because of the clustering effect: very talented people hate to work with idiots.)

It's actually a huge plus for me if the company takes the time to put a novel programming puzzle in the post. It says a few things:

1. this wasn't posted by a recruiter or somebody clueless in h.r.

2. engineers at this company still care about hiring

3. a lot of buzzword bombing b.s. artists aren't going to be applying

4. the company recognizes that raw aptitude is more important than bullet list bingo

In other words, it's a sign that the engineering culture is probably still healthy at this company.

One of the things I learned nearly 20 years ago is that it sucks to work in shops where the engineers are arrogant, because the more arrogant the less likely any good engineering is tolerated.

These kinds of puzzles communicate arrogance to me. They say "We're more interested in excluding you based on a trick question than in getting to know you".

I guess it depends on the question. If it requires previous knowledge of some kind of gimmick then I agree it's a turnoff. A good puzzle that challenges your thinking and tests some basic algorithmic chops is a good sign though, I think.

For example, the puzzle in this ad is a good one: http://newyork.craigslist.org/mnh/sof/1927765905.html

A bonus question requiring previous knowledge can be fantastic as a shibboleth if crafted well — it reinforces to the potential applicant that there is a clever compatriot on the other side, and makes the job of screening resumes easier.

What would be an example of this?

This brilliant job ad with bonus shibboleth was linked in #startups months ago: http://bnjmnhggns.org/jobs.html

Yeah, I knew that was a group of arrogant douche bags who are probably incompetent before I even got to the puzzle. I didn't bother to look at the puzzle, it oddest matter how difficult it is, it's presence is just icing on the douchcake.

I think you've got the sensitivity on your douche detector cranked up way too high.

I'm not sure that he does, I thought the same of the ad and didn't say anything but I was glad someone did.

Reading in the graph and putting it in a tree structure is a reasonable problem, but not a 10 minute interview one.

Traversing the graph to find the optimal path? Wow, that's known to be a tricky problem. Brute force search will work but will take a while. Now, undoubtedly there must be some very clever proof that discards most of the searches for the special case of a triangle structure. And if you've seen that you're all set. If not, hopefully you have your copy of AoCP at hand to start looking for it. If you are in an interview and haven't seen it, you just need to recreate the conditions from 1 million BC to 1950 or whenever someone had the right insight to come up with a proof. Not really a reasonable assumption. In those circumstances it's only a test of if you've run into this issue before.

And figuring out the answer is necessary to determine the email to submit a resume? How foolish that hiring manager is. If he was Google, yeah, you can put the question on a giant billboard ad as a challenge and get some responses. He's not Google.

Reasonable question is if someone can parse some data and put it in a tree or graph.

Reasonable interview question is to bring this up and talk about approaches. Person mention's Djikstra's algorithm, well he's heard of Djikstra and knew he was big on optimal path searches. Mentions AoCP, he knows a good place to look for clever algorithms. Knows how to solve it on the spot? Probably pretty clever. Finding the optimal 100 node long path in a graph as a screening method to send in a resume? Funny stuff there.

Being a bit clever myself though I'll go a bit further here. I'd say you might be the person who posted that ad. But I think more likely is you want to apply for the job and have no idea at all how to solve that problem and are hoping by coming here and pretending it is trivial someone like me will give you some hints. Because if you really knew your stuff, you wouldn't be claiming it was trivial for any competent practitioner to solve and a reasonable screening question.

Sure, there is an easy answer out there for doing this search, that's almost certain. That everyone competent would figure it out easily? Nah.

Reading in the graph and putting it in a tree structure is a reasonable problem, but not a 10 minute interview one.

Traversing the graph to find the optimal path? Wow, that's known to be a tricky problem.

This question wouldn't be appropriate for an interview, but I think it's just right for a pre-screen. It's not hard if you realize they're not asking for the optimal path, just the biggest total.

It's not my question, but I did take a second look at this company and I probably wouldn't have based on the rest of the posting.

The Quora challenge problem, on the other hand, seems like very hard one: http://www.quora.com/challenges

The biggest total requires the optimal path for the stated constraints, those being the path must yield that biggest total.

They aren't asking for a good enough path, but for the best possible path, the one that gives the biggest total. That's the optimal path for this problem.

Probably a brute force search is the way to go, I certainly can't think of any way to thin this problem out without doing research, especially given the requirement that the optimal (maximum value) solution is required.

99 levels below the top, each time a binary decision, there's 2^99 = 6.34 * 10^29 paths only, won't take too long relative to the life of the universe since 2^99 nanoseconds is only 20 trillion years. That's the answer, might have a little problem with the sun burning out before the computation completes, but by that time you should be able to relocate using a warp drive. Good luck on the interview.

edit: Ah I just figured out the pruning algorithm that will solve it. And that's the answer too, I just gave it to you in the previous sentence if you read carefully. Obvious once you think of it, not until then. I doubt many people would figure it out without a hint. And with a hint only clever ones could get it. As a screening to send in resumes? Pretty useless. If you do get a response who's to say they didn't ask for hints on a message board or pay someone to solve it on rentacoder.

I had this one solved already, but thanks. See, think about it for 10 minutes and it's not hard.

I don't agree with that at all. Thinking for 10 minutes is not sufficient. There's two insights and neither are obvious until you get them. Assuming candidates will get them is like assuming quick sort will occur to them if they've never seen it before.

The minute you actually sat down and thought about it you got it, as did I, as would any of the better programmers I've worked with in my career. Walk halfway into an algorithm and it's clear. I wouldn't expect the average code schlepper to get this but that's the entire point. This ad suggests to me that's not what they're after.

Ended up being 5 lines of code in C.

(Cue: reactions from others that it's a one liner in Haskell, or that it's obviously simple and easy since the solution was so short.)

(The five lines didn't include the data, but a sixth very long line takes care of that if really felt to be part of the count.)

This puzzle has a couple of problems: The problem description claims there are 100 rows, but the data only has 99 rows. The example solution shows an "isosceles" triangle, but the data set represents a "right" triangle and the given example solution is impossible with a right triangle (because the left border is a constraint). In order to properly solve the puzzle, one much make assumptions that may turn out to be untrue.

Resolving such ambiguities and unspecified detail is something we deal with every day; however, it's less than helpful so early in the process. As others have mentioned, hiring is a two way street.

It's actually completely specified. Note that I don't think it's a great test at this position in the hiring process, but it is completely specified and solvable.

The puzzle question is an interesting one. I like solving puzzles, that's why I am an engineer. Based on this I used to think that puzzles are a good thing for posts and interviews.

In practice, it almost never works out very well. Puzzles are incompletely specified, impossible to answer unless you guess at assumptions that are sure to be wrong, or they take so much time to solve it's just not worth it.

Usually companies don't need complex puzzles for screening anyway. Something rather trivial and quick to answer like the fizz buzz problem eliminates 90% of the dud applicants anyway.

I'd never heard of the FizzBuzz problem before. Just looked it up. Do people claiming to programmers really struggle with it? That's disturbing if so.

Designing a good problem is hard. Something that's difficult enough to present a challenge but easy enough to be solvable by a good programmer in ~15 minutes or so takes some thought. But this is another reason why I appreciate a good programming problem in a posting.

No, they don't struggle with it. More of a blank stare. They have absolutely no idea what to do or how to get started, unless they happened to have seen it on a "famous programming questions" board and memorized a plausible answer character by character.

If you do a decent job of publicizing an opening you'll can easily get 1000 resumes. If you narrow this down to what seem to be the top 20, 18 of those won't be able to write a simple loop in the language of their choice. Part of the reason for this phenomenon is that the best developers who applied were in the 980 resumes discarded (this is in part due to unreasonable expectations on the hiring side and outright fabrication on the applying side).

But the general idea is that the same duds apply to every job. If you post a job ad for a terrible job with unreasonable parameters, then 100% of the applicants will be the duds as everyone with any sense reasonably ignores the ad. The more reasonable and realistic the ad, the more potentially qualified candidates will apply, but this number is not going to be the majority of applicants. The majority will be the non-english speakers and DeVry Institute grads who are mass spamming every job ad they can find with bogus resumes.

There's no point to starting with a challenging programming test because the interviewer's idea of obvious common sense insights is typically some highly domain specific thing that only is known at the particular company. Or even worse, the "challenge project" which will take a week to finish and is obviously a real work project for the company that they want done for free. Furthermore, interviewers seldom have any realistic idea of what could really be solved in 10 minutes by someone who hasn't seen the problem before like the person who selected it. FizzBuzz like problems are again the answer. Ask to reverse a string without calling a library function. This is a reasonable 10 minute question. If 95% of applicants fail, then this is a very useful screen is it not.

I think these puzzles may be useful, but they do not respect the candidate's time. Candidates apply to many jobs, and it is unfair to expect them to each put half an hour into a problem they may or may not be interested in for a job that may never call them.

You can give your candidates this problem during an interview, but only if you are willing to give up time you could have otherwise spent in that interview getting to know the candidate in other ways.

Random thoughts from when I write job reqs:

Make sure there is a clear description of the job itself and what the challenges the company and the role itself are trying to solve ("Looking for Ruby on Rails devs, call us!" doesn't explain what problems you'll be solving, etc). GOOD developers don't look for a new job using X, Y and Z languages, they look for a new job tackling problems A, B, and C.

Don't include requirements that are superfluous, unless you can really justify them. "Must have 5 years experience" - why? I know devs with 2 years experience that will kick the shit out of a 10 year vet. "Must be capable to lead a small dev team" or "Experience with several discrete projects a must to be able to advise from experience on architecture choices" is better.

Ditto with CS degrees: don't mandate one unless there is a good reason.

Be clear yourself with what the role is going to be: are you looking for an engineer or a support guy, dev ops, etc? "Spray and Pray" is not a strategy and looking for that experienced engineer who is fluent with UX and design while also able to administrate the production servers and load balancers is going to net you people who know nothing about anything.

State the current stage + status of the company "pre-funded", "series a funded", "profitable". Different people are attracted to different stages (and the risk that goes with them) so be clear in the job req to pre-filter those who are not. An engineer with a wife and two young kids is unlikely to take your job at your pre-funded startup so be clear where you are.

Don't use words like "rockstar", "code-ninja" or guru. You come across looking like a dick - and far worse, that I might actually end up working with someone who really thinks and behaves like he is a "rockstar" because he was hired as one.

Be clear with your methodologies, coding practices (pair programming, peer code review, etc) and anything else that will make you look attractive. Consider getting some before you post your ad if you don't currently have any (why do I want to go work in chaos?).

State where you are located, and not just "San Francisco" (for example). Mention the neighborhood or even the building. People living in East Bay are going to want to know if they can BART in, South Bayers will want to know how bad the drive will be ONCE they get into the city/if they can CalTrain and even locals are going to turn their nose up at your Outer Sunset location if they're paying through the nose to live in SoMa. I also want to know what kind of community there is around my potential work place ("We're in Twitter's building", "we hang out in South Park most lunchtimes"). Also state if telecommute is an option.

Don't forget to mention benefits (or state if there are none yet) - even geeks in their mid-twenties want to know if you are going to cover their dental. Same for stock, you don't have to mention remuneration specifics but be clear if the remuneration will include stock, and be especially clear if you are looking to offer a package that is "equity heavy" (ie below market $ salary). Again, this will filter out people who are not suitable for that situation and manage expectation of those that enquire.

Include photos of your work place, even if you just have basic digs (which is fine if you are early stage) You can tell a lot about a startup and a job from looking a their offices.

Don't use recruiters. Do I have to explain why?

But my best tip of all:

You/your founders should be spending a large amount of your time curating your network such that you don't need to put out job reqs because you can simply hire from your network.

Also don't be afraid to simply identify developers in existing startups and reach out to them directly - they may not be actively looking but will entertain your interest (and perhaps) subsequent job offer. Even in this economy (in Bay Area, at least) good developers are seldom out of work so be prepared to poach rather than search the job seeker pool.

These are all great points; I'd most like to second "be clear with your methodologies". You've gotta be honest here. In particular, don't say Agile when you're not actually following an Agile methodolgy (the number of companies to whom 'agile' simply means "we don't do any planning"...). I've worked for companies that aren't Agile, who also never do unit testing, let alone TDD, and yet manage to be successful. I'm not necessarily put off because I don't see those things in a job posting.

Claiming these methodologies when the reality is different is just going to lead to disillusionment (and no, 'in the near future' doesn't count)

Most of this is good except for the: don't use rockstar and other terminology. I don't behave like a rockstar but I often look for that as an indicator to apply since at least I know that I would be valued there. It's not so important to use it, but if you are truly looking for a guru (and most other people have failed the technical requirements so far) then it doesn't hurt to post it.

I think it does hurt. Especially in startups when you'll be working absurd numbers of hours and spending an incredible amount of time with these people I'd prefer the slightly-less-talented-but-very-good to the absurdly-brilliant-but-completely-intolerable. I definitely glaze over the word "rockstar" at best. Besides, I would think it goes without saying that anywhere I'd seriously consider working would expect all their employees to be damn good at what they do.

Agreed, I actively avoid people who thing they are as it's synonymous with "arrogant twat" and getting things done is about team work, not prima donnas.

Good developers want to mature and evolve a process that is the right fit for the business and not the SOUP of the day. I just read a good paper about software development management and how process must fit the business objectives.

http://www.parasoft.com/jsp/products/article.jsp?articleId=3...

First, I look to see if the work interests me (not giving a description makes me unlikely to continue). Then I look to see whether it is a reasonable (not necessarily perfect) match with my skillset and availability. Any posting I see that meets the above will probably convince me to look into it further. Relocating, even temporarily, does not bother me, though it is nice to know the location in question.

Do job postings even matter beyond that fact that company X is hiring?

Yes. A single company probably has some (perhaps a lot of) variety in the positions for which they're hiring and the work they'd give to the new hires.

Does a posting with descriptions of the company culture, future plans, values, etc actually mean more than "PHP/Python hacker for YC startup"?

No. I've seen it in a couple postings and pretty much just skimmed over it and got frustrated that I couldn't find the information mentioned earlier, but "PHP/Python hacker for YC startup" doesn't really get my attention either.

For me, it's not what attracts me, but what turns me away.

For example, if I'm looking for a Python job, than any job regarding Python is of immediate interest. That's all that's necessary on the attraction side of it.

Things that keep me from applying for jobs are, in no particular order: using the word "Rockstar", mentioning how difficult things are or how quick they are, mandating requirements that don't really matter (college degree required! skill not important), vague details, trying to sound too cool or fun to work with.

My advice would be to sit down with someone else there and tell them about the job. Tell them what you're looking for, what you offer and any important details. Actually have a conversation with them about this. Record it. You'll have the basis for an honest job post in conversational tone that tells potential employees exactly what you want.

I personally look for a neat collection of tasks that I would be performing as well as a required skill set that I actually have. I used to really want to do telecommuting, but have since backed out of that desire since it tends to give your fellow employees license to frown at your ability to not have to be in the office. I also like posts that are not a generic list of incomprehensible gibberish. I will say that it seems even the most bland-sounding of companies have 11/12 these days on joelonsoftware. What's that all about? Has every company become "that company"? I joke of course. All tangents aside, these are the kinds of things I look for.

I wrote about this a while ago here: http://www.deserettechnology.com/journal/writing-a-good-job-...

To incent right job seekers to respond, I think it's a function of making it interesting on 2 fronts:

1. The job itself - Will the person be solving or doing interesting things? 2. The company - Does the company have a clear vision and seemingly a chance of success? Evidence of traction here can help, i.e. being a YC startup, press, etc.

I think gimmicks and attempts to make a job description "stand out" through wit, humor, etc may work, but they don't always register with everyone and can miss altogether at times. Not worth the risk (esp as as a first attempt IMO)

Some things good programmers care:

* good engineering practices (as all those described in books like "Pragmatic Programmer" and "Code Complete": code reviews, unit testing, continuous integration, coding standards)

* tools worth respect (e.g.: subversion, git or mercurial but not Visual Source Safe)

* a well defined development & project management methodology, agile or not (e.g.Scrum, RUP), instead of clueless project managers.

* a concrete problem/puzzle in the company website to filter out bad candidates

* respect for the developer private life; i.e: what to expect in overtime work

Marissa Meyer has a funny story on this:

http://ecorner.stanford.edu/authorMaterialInfo.html?mid=1526

Answer these questions:

- Who are you?

I need to research a company before I send you my work DNA (a.k.a. resume`). Are you a spammer? Are you some recruiting company building a resume`s database?

Be honest and avoid snake-oil salesmen terms like "Company in the bay area with a huge upside". If I work for you, I have to believe in your vision as much (if not more) as you do and I can't do that without doing due diligence and researching your company.

If you are not well established yet, then a brief description of what you do and what your vision is always helps (in your case, a link to your site should suffice).

- What do you need from me? / What does your technology stack look like?

Be very specific about must haves and "would be nice"es. You can discourage a lot of potential candidates by putting a laundry list of technologies that you're thinking about (or worse, toying with the idea of) implementing in the future but are in no way what you need from a candidate right now.

- What is your compensation package?

Not always feasible to write in detail, but putting a salary range is a huge plus. A phone interview + a couple of on-site interviews (taking time off of my current job) to be told that your maximum offer is worth $20k less than what I make right now is a waste of everyone's time.

Aside from that, everything else is just fluff in my opinion. Good luck!

Edit: Formatting. Where's the preview button?

1. Talk about what you'll actually be doing, both in terms of both technology and the projects. Most of the time this has to be guessed from vague technical "requirements" rather than offered up freely. If you can show genuine enthusiasm for your work that is fantastic, but don't fake it because that is also obvious.

2. Be up-front about the upsides and downsides. If programmers get full control of their workstations and get to pick what environments to use, then say so. If they are expected to work 50 hours every week, say that too. That's how you'll attract the right people to come interview.

3. Putting your answers to the "Joel Test", if you score well, is a good way to attract the right people.

I also have to self-promote a second and point out this: http://www.codeanthem.com/blog/2010/04/how-to-hire-crappy-pr... which is the anti to what you're asking for - but probably worth a read and make sure you're not doing any of the ones listed in the post or the comments.

Hiring has to be pertinent to what you are doing...

For me "equity" or "equity plus small amount of cash" generally means you are looking for volunteer labor. I've done a bit of this, but generally most postings of this nature are of the "we want you to work for free" nature.

I avoid them.

I've seen a lot of people asking for a description of the problems the position will be addressing. Discussions with clients over the past couple of years have led me to understand that in some cases, companies don't put out many specifics because what they want you to work on is a bit of a competitive advantage (in some cases this is even justified). Letting your competitors know you're hiring to build system XYZ to do ABC gives them a heads-up as to what's coming down the line.

Granted, this isn't the case in all or even most postings that are vague. But if other aspects look legit, but the posting is a bit vague, give them a little 'benefit of the doubt'.

I look for the language stack I'm prefer (because I chose it for a reason), and a business model that seems sane and interesting.

Phone interviews are pretty cheap, and a quicker way to see if cultures / values / etc. line up, imho.

Random bits:

- What company the job posting is for. There's a surprising number of job postings missing this tidbit. It might be fine in a job hungry market, but it's never been fine for me and I usually ignore these postings.

- A real description of the duties. What do you actually want me doing? Will I be working alone or within a team?

- What tools will I be using? It's alarmingly common to go into a job posting for J2EE and find out they're really migrating to .NET (or vice versa). I know a hell of a lot of programming languages, but I've truly mastered only a few.

* Set a challenge. What do you want that employee to achieve in the time that they're with you?

* Lay out the opportunity. How can they develop and what will the rewards of success be?

* Tell a story. How can a potential employee find out about the role and the company culture in an engaging way?

We included all three of the above when we wrote a recent job posting for a managerial position, "Searching for a Superhero": http://brightone.org.uk/searching-for-a-superhero/

I think it's much different for established companies vs. unestablished companies. As someone at a startup which hasn't launched yet, we have to be more descriptive. If you're YC company, or more established - maybe it's enough to say Acme Corp, PHP, email us.

We like to say:

Funded startup looking for a talented Ruby developer to be employee #1 (because that's true, and because there's something unique about being employee #1).

Some of TechCrunch's postings have been real winners. Although I probably wouldn't really want to go there, they usually seem to care more about the candidate's passions than their experience and education. I'm sure once you get into the hornet's nest for the face-to-face, the team will grill you to smithereens to see if you can hang with them or whether you're just blowing smoke.

I have to admit, I like greplin's job posting: https://www.greplin.com/jobs

40 hour work week.

With managers actively encouraging employees to go home to their families.

We recently created this job ad which you may find useful? We tried to make it sound interesting and convey that it's not all about the money, but also quality of the working environment.

http://www.engageinteractive.co.uk/recruitment.php

Cheers,

Alex

I wrote this http://use.perl.org/~Adrian/journal/33295 a few years back on how to not write job adverts. I still mostly agree with it :-)

Let people email a resume to apply. Don't make people fill out a 20 minute form that requires retyping your resume. And if you do have such a form don't make "desired salary" a required field.

My views on rock stars .......

http://www.jeremyhutchings.com/2009/12/rock-star-vs-rock-sol...

DesignModo Jobs - Freelance designers, developers, photographers, artists http://jobs.designmodo.com

what do you think?

I think it has very little to do with the original question.

What do you guys think of http://www.extrahop.com/jobs/ ?

I like it. Straightforward description, realistic requirements, an interesting but not unreasonably difficult programming problem, and an appeal at the end to lore probably not possessed by any but the genuine geek.

Best job description I've seen in ages. I especially like the semi-technical and open ended questions.

Reply on news.ycombinator.com