3 ms·
Ask HN: Creating the Perfect™ Job Listing for engineers. What needs to be in it?
A few days ago, I posted “Trouble hiring senior engineers? It’s probably you - When hiring senior engineers, you’re not buying, you’re selling” and got lots of great feedback here on HN[0] and reddit[1].
I was pretty negative about the quality of most job descriptions, so naturally many people asked for examples of good job listings. I’m now writing a follow up post for which I’m trying to create The Perfect™ Job Description for engineers. Of course, “perfect” is highly subjective, so I’d love to get your input.
Here’s a few random ideas I had so far:
- Salary range (an obvious one)
- We know you value focused development time and we understand that interruptions are costly. We keep meetings rare, light and short. Average meetings take X minutes.
- We understand that time spent at the office doesn’t equate to productivity. On average, team members work X hours per week.
- Here's what the rest of our hiring process looks like: (Link with answers to: How many rounds of interviews? Coding challenges? Timeframes?)
What do you think should be in it? What should definitely NOT be in it?
[0] https://news.ycombinator.com/item?id=18955731
[1] https://www.reddit.com/r/programming/comments/agajxv/trouble_hiring_senior_engineers_its_probably_you/
- auslegung 8y agoLooks great so far. I’d like to know the company’s values, what dev practices are in place (XP, scrum, etc) and what they actually mean to the company. How difficult or easy deployment is. How much time is spent on features, bugs, and maintaining legacy code, what the stack is for legacy and for the new stuff, listed separately. Etc.
- cloogshicer 8y agoThanks for your feedback! That's all great stuff and some things I didn't think about, I really like explicitly separating the current stack from legacy code.
- towaway1138 8y ago- Distinguish carefully between requirements and "nice to have". Don't call it a requirement unless you're pretty much completely unwilling to hire anyone without it. - Note oddities of your physical environment, like open plan office, non-adjustable chairs, desks, monitors, noise like a loud restaurant, no public (non-MITM) WiFi, etc. - Note oddities of your development practices, like forced pair programming, daily meetings, Scrum/Agile/Flavor-of-the-Week, everyone must use Eclipse, everyone must use Macs, source control in Perforce. - Note actual average weekly hours, with some hint of variance. - Note actual annual turnover.
- cloogshicer 8y agoGreat points! Didn't think of turnover, which can be a really good indicator. Office environment is of course also very important.
- towaway1138 8y agoYeah. I once took a job paying FANG-level comp, but with a publicly inferrable turnover of 35% per annum. Big mistake.
- cimmanom 8y agoOne of the best job postings I’ve ever read was basically a description of “this is what your typical workday will be like”.