For reference, the current job ad is the industry standard laundry list of tech used, tech expected and a pretty tame sales pitch about the company.
For reference, the current job ad is the industry standard laundry list of tech used, tech expected and a pretty tame sales pitch about the company.
21 comments
Imagine you are talking to a friend about joining this company.
Tell me a little bit about the role, what needs to get done.
Tell me a little bit about the team, company culture.
What’s the mission? What interesting problems are you trying to solve. Are there any particular priorities that really stand out?
Answer the question: why is this an attractive opportunity? Why is this a great place to work?
Hint: no BS about ping pong tables and unlimited free snacks.
Finally, deliver this message in a 2-3 minute video from the actual hiring executive (not HR). THAT would be interesting!
You first need to capture my attention with the text. Once I'm interested, I might click on the video, but if it's just a video, the only chance I'll watch it if it's the video ad I need to watch before the video I actually want to see on Youtube, and you manage to capture my attention in the first few seconds before I get the opportunity to skip the ad. That can be done, but you really need to lead with something extraordinarily cool.
List the tech stack, that is important.
List a real salary range. A lot of places won't do this because they feel like they might be missing out on a deal, but listing the range lets candidates filter themselves in or out of the job immediately (and good ones will try to find out the range anyway from external sites such as Glassdoor or Paysa, which might be inaccurate and thus result in a lot of wasted time).
Tell me that you're hiring for a direct, full time employee position. (Otherwise, I'm just not interested at all. Contract-to-hire is an immediate fail.)
List benefits.
Tell me the day to day of one of the people on the team, written by that person.
List requirements but be open-minded. An experienced-enough engineer can learn a lot very quickly.
Local only? If not, is there a relocation package? Is there travel involved? Is the position open to remote? (If so, list this early in the ad as it will attract a lot more attention.)
Tell me what your interview process will look like.
Highlight what you believe differentiates your company from others, especially as relates to the potential hire's day-to-day.
> List requirements but be open-minded. An experienced-enough engineer can learn a lot very quickly.
Be thoughtful and explicit about which requirements are firm and which aren't. I think of a firm requirement as one for which any resumes lacking it are automatically thrown in the trash, full stop. Or, equivalently, any requirement for which you can say f'I wouldn't hire {best_hacker_you_know} for this position if they didn't have {requirement}.' With this in mind, it may be reasonable to have 0 firm requirements for a position if you trust your interview process, and it's probably suboptimal to have more than a handful of them.
Assume that there are good candidates who will treat every requirement as a firm one unless you explicitly state otherwise, and who will only apply if they meet all of them. Because there are. Chances are, you don't want to miss out on good candidates who know most of your stack like the back of their hand but decide not to apply because you "require" MySQL experience and they only know Postgres.
Some applicants are naturally more haggle-friendly and intuitively "know" they should apply to jobs for which they don't technically have all the listed requirements. Other applicants are more self-doubtful and will not apply, even if given their experience they would be well-suited for the job. Minimize the amount of white-lying both the applicant and the company have to do.
- What does the company do and why is it important, interesting or impactful?
- What do you want the new person to achieve? (Impact)
- What's the context of the role (team size and mix of roles, company size and mix of departments)
- What state is the existing stuff (e.g. for an engineering role, how mature is the tech stack, for a product role is the product released and how good is it)
- (If applicable) links to the product or screenshots or video
- Working environment and style (how often do you ship? What does a new hire do in their first few weeks, by the end of 3 months, by the end of 6 months)
- why hiring now?
- 2-4 minimum requirements for the role (e.g. if there are hard technical requirements like specific language, or if someone needs to be able to do financial modeling or whatever)
A job application that goes at the top of the list, one that I apply to with enthusiasm, needs one other thing: It answers why I want to work there. It says something to show me that human beings work there, not just robots. In some way, it has some personality, some human touch, some flash of humor.
How should you do that? I can't tell you. If I tell you, people will use it as a formula, and they'll just come off as robotically following a rule, rather than showing a genuinely human touch.
Most important thing is accuracy/honesty. Nothing worse than overselling a backwater tech or a bureaucratic mess as a dream job.
PS: Avoid boilerplate phrases that constitute 'sweatshop-smells' like "passionate developer".
The phrase "work hard, play hard" is one of those phrases that raises alarm bells for me. I get an image of people working 12 hour days until they're burnt out and then having wild, beer-chugging parties. No thank you.
I completely agree on the laundry list thing. More often than not, it's more of a turn off. I find it particularly funny when I see $CurrentDotNetTech...jquery, javascript, css or similar. They'd be better off just mentioning "C#/.Net web development" and leave it at that. Over-specificity or too long of a list just leads me to believe the decision makers settled on their tech a decade and a half ago, and never grew from there.
Applicants excited about your company or role will apply immediately and put much more effort into the process. Applicants opting out probably weren't great hires for you anyway. By triggering a strong in/out, you only spend your time vetting the very best applicants.
Example: Company X has a strong "dogs in the office" culture. It's a big part of who they are! People who love dogs absolutely want to work there, and may be willing to select Company X over other equivalent positions. People who don't love dogs, are alergic, or just prefer animal-free offices would never really be happy there, and the hiring manager doesn't even need to look at those resumes.
That said, there's nothing wrong with a list of skills and technologies, but keep it relevant. In fact, maybe describe the technologies used as just that, rather than a list of requirements. I'm interested in the environment I'll be working in, both technical and social. But lists go at the end. Start with why I should even want to read this job ad: what makes this job interesting, and different from all the other identical jobs? What kind of problems will I be solving? What kind of value will I be contributing to society? What kind of company are you, and what kind of clients will I be working for?
Avoid the usual checklist of meaningless buzzwords. I know that I need to be a team player when I'll be working in a team, or that I need to be independent when I won't be working in a team. Just tell me I'll be working in a team, but tell me a bit more about the team.
Focus on what makes this job different from all those other hip agile casual tech companies.
Then it should go into the list of BFOQs and job requirements. This should include education, experience (with years and/or other KPIs listed), transportation, relocation, etc. If the role is client-facing, it should include that here - specify that the client needs negotiation and communication skills.
After that it should list the basic job responsibilities. Again we're not going deep here, just a brief three or four lines. What will this person's everyday look like? Will they need to attend meetings? Will they need to turn out a specific number of lines of code daily? Etc. I'd also put in the management review cycle here, but some companies like to be cagey.
After that, list the 'nice-to-have' points. For instance, being bilingual, living in walking distance, etc. Just make sure they're quantifiable. We're not looking for wishy-washy 'cultural fit' here, but rather real success drivers that simply aren't part of the job's requirements.
Then, end with a CTA talking again about the company and how this person's growth opportunities would be. Might they be management in a year? 5? Etc.
Notice that I don't have much in the way of soft or flexible points, and I don't list the salary in the ad. Let the person come to you based on the job, but have a number in mind. Always set your anchor 5% below that when the person asks in the first call. Try to keep each section to either 3 or five one-sentence bullets. Make sure anyone involved with the recruiting cycle knows everything about that ad - even if they don't know the job's specifics.
The fact is that any mid-level or higher developer should have learned at least a couple tool-sets/languages for development and can likely come up to speed regardless. We all have our preferences, and would prefer to be able to have hope of seeing things adapt based on fit/need not be dogmatically locked into a single vendor/language/solution.
Hire people that can grow in the environment through domain knowledge, practical skills and some new technology initiatives and not just a management path. There's a real reason why there is high turnover, and I would guess that less than half of it is the salary.
- Tech Stack
- What you do in AS FEW WORDS AS POSSIBLE. I don't really care about how you are "changing the world" or other flowery language that tells me nothing about what you actually do.
- Location and/or remote possibilities
Stretch goals:
- Day in the life or list of duties performed by or expected to be performed by this hire
- Break out needs/wants in the technical section. I want to know if you NEED someone who has used React or if my Angular knowledge and my ability to learn are going to be enough. I've seen some postings put this under a "nice to have" section and I can tell you, that section sure is..... nice to have.
Everyone wants to know a little about the company and culture, general details about the job role and some specifics about technologies, company maturity, location/hours/compensation.
The rest is presentation.
- real salary range
- list of benefits (how many vacations per year, sick leave, healthcare, dental etc)
- real tech stack (not what you aspire to in the long run but what is currently running in prod and what I will have to work with)
- typical day of an engineer
- mission of the company, why is your product useful? who does it help and how?
- reasonable requirements list vetted by technical person (seeing stuff like 5 years experience with language tool that is few years old is a red flag)
Don't write anything that you wouldn't be able to defend when put under pressure by an interviewee during his/her side of the interview.
Are you looking for an expert in specifically X language/tech ?
Are you looking for someone with X years of development Experience?
Are you looking for a generalist?
Please clarify