Pam Selle's blog post about burning your resume struck a chord with me. Resumes are antiquated and counter-productive; optimized for people to not read them. She goes on to say that, as a developer, your best bet to find a good job is through networking and provides some helpful tips to get you started. I couldn't agree more.
Some people think GitHub is your resume (I disagree). Others think life would be better if resumes were JSON. I think there is plenty of focus on "solving the resume problem." What's more important to me is the tragic state of hiring in our industry overall:
- Job postings are almost as useless as resumes, with a terrible signal-to-noise ratio
- Employers using byzantine HR-focused web apps for job postings and resume intake
- Tech recruiters
- Candidates who don't know how to get the information they need to make informed decisions
- Employers who don't take screening processes seriously
- Interviewers with no training or guidance
There's much room for improvement, but I don't expect tech hiring to vastly improve in the short term. Developers create so much value that any waste in the hiring process (and the occasional bad hire) has become a relatively low economic priority. That doesn't mean these problems don't do very real damage to the people involved. A bad hire can be toxic to a team. A poor screening process can contribute to burnout. You may join a team and find out they are terribly dysfunctional and find yourself stuck there.
In my 15 years-or-so of experience as a developer and manager in a wide range of companies and technology stacks, I've been on both sides of the interview table too many times to count (i.e. a three-digit number) . I've noticed some patterns I wanted to share with the rest of the class.
Tips for Employers & Interviewers
First, make sure you actually want to hire a developer. If you don't self-identify as a "software company" then it's very likely are you should bring in a contractor. This can be perilous but will save a lot of money in the long run if you do it right. That's a topic for a future post.
Assuming you really do need to hire a developer, you must invest in a screening process. Expect to spend a nontrivial part of your time focused on it. It's like a sales funnel, where leads become prospects become customers. You don't just "wing it" when it comes to managing a sales funnel do you?
A common complaint from employers is it's "hard to find good people". Since this isn't universally true, it means your screening process needs some work. If the ideas in this post seem like too much work, seriously reconsider your desire to hire a developer, for the sake of everybody.
1. Finding Qualified Candidates
The core of a screening process is identifying which traits you are looking for. Writing a job description is very subjective, but one piece of advice I can give is to avoid long lists of specific languages, tools, libraries, frameworks and so on. A tool-heavy job description says to many readers that you are looking for a cog in your machine, not a human being who is capable of (and enjoys) learning. Try to strike a balance between technology, experiences, preferences and soft skills your team needs. Explain without jargon what important problems your company solves.
Once you have a description, don't just delegate resume intake to a commissioned tech recruiter. Any time/money you think you will save will be lost on either recruiter fees or politely fending off sales tactics. Of course networking is a great way to qualify people but what else can you do to avoid getting spammed with resumes?
Remember your goal here is just to find people who can code!
DuckDuckGo is a good role model. They look for developers who contribute to their open source projects before progressively engaging with them. It demonstrates the candidates are genuinely interested in the company and yields real code to review.
If this doesn't work for your company, a simple homework assignment is probably the best screening technique. Design an exercise which would take no more than two hours to complete, is appropriately challenging and has minimal/no set-up time (e.g. just a text editor and few dependencies). Optionally, you can make the instructions a little ambiguous just to see how people handle it. Simply require that all resumes be accompanied by the homework assignment and a list of whatever questions/assumptions the candidate had along the way and presto.
Don't worry about this tactic turning away good candidates. In my experience, good candidates view it as an encouraging sign.
Some homework examples I've encountered in the past (these can be very fun to design, by the way):
- Create a database schema from a sample excel file
- Model a shopping cart, blog, to-do list or time tracking app
- Fix some buggy code
- Create a "memory" card game
- A data visualization
- Refactor some code to handle changing requirements (e.g.
ifstatement to strategy pattern)
- Give an open-ended business problem and let them use their imagination
2. Initial Phone Screen
Your next goal is to ensure no time is wasted on pointless in-person interviews. Have a 15-30 minute casual phone call with them to ask the important questions (e.g. their motivations) and confirm they can communicate. Do not grill them with technology questions. You cannot reliably assess technical depth on the phone. Allow time for them to ask questions about the position to make sure their time is also not wasted.
3. In-Person Interviews
There is a lot to be said about specific interviewing techniques, but overall, the most important thing is to simply prepare for them.
Make sure the candidate is comfortable by explaining the dress code, where to park, who they will meet with, etc. Put yourself in their shoes. Do it as a courtesy and to avoid their stress reactions from clouding the assessment.
Make sure the interviewers understand and agree on what traits they are looking for. Since you will need to make a group decision afterwards, try to keep the total number of interviewers to a maximum of seven people (think dinner party). Don't worry about people asking the same questions of the candidate, it's not really possible to avoid overlap.
Do not engage in any of these practices:
- Having more than two interviewers at a time. This is not a jury trial.
- No trick questions, "gotcha" questions, or opportunities for the interviewers to show off their skills.
- No brain teasers / puzzles. If you want to "see how they solve problems" then give them homework.
- Live coding (on a whiteboard or at a computer). It's just too awkward and stressful. If it's important that you developers can thrive under such conditions, you need help.
- Ask any sort of demographic questions (even simply where they live). It's inappropriate and can get you in legal trouble.
Try asking questions which focus on the important stuff: how they learn things and apply them to achieve goals in a team environment.
- Ask open-ended questions followed up with deeper follow-ups. For example, "explain a recent tough problem you solved" then "tell me more about that choice you made".
- Ask for tales of shipping real software to customers and what they learned in the process
- Ask about how they like to learn new technology and what they are keen on learning next
- Ask about a specific technology they used and what the liked/disliked about it. Don't hire anybody who likes something unconditionally. Everything is a trade-off.
- Make sure the candidate is capable of admitting that they don't know something.
This is probably the hardest thing to get right. The root causes for failure at this stage I've seen are:
- Lack of consensus on which traits the team is looking for
- Valuing technical skill in spite of glaring personality disorders
- Forgetting that diversity in a team is a good thing
- External pressures forcing bad decisions
- Too many/few people involved in the decision
How you make this decision is entirely dependent on your team's needs and culture. I think the most important thing is to reject any candidates you are unsure of. Everybody should be unanimously excited about this person joining the group and ready to "step up for them". Anything less is almost always results in a bad outcome.
Take time to do a short retrospective on the hiring process each time you reach this stage, regardless of the decision, to make any course corrections. Don't be surprised if you reject the first batch of people who make it through to the interview since you are still refining your process.
Tips for Job Seekers
If you're having trouble finding opportunities then you probably need to do the usual stuff: re-train, network, contribute to open source, etc. If you are inside the hiring funnel, here are some bits of wisdom I've acquired the hard way:
- Be true to yourself no matter what.
- Trust your instincts. If you think somebody who interviewed you is a jerk or the company is the least bit shady, you're probably right.
- Keep your guard up. If somebody you interviewed with seems cool because they play the same video games you are into, try to ignore it.
- Ask lots of questions. Follow up if you don't get answers. Invite your interviewers out to lunch to see how they behave outside of the office. Ask to meet with anybody up the org chart until you get the info you think you need.
- Don't be lazy: avoid recruiters and don't expect technology to handle this for you.
- Realize the business value you bring to the table.
- Study the market to understand salaries. Decide what forms of compensation are important to you long before you enter any negotiations.
Do It For the Kids
Computer Science and Business degrees are all the rage. Let's do our best as an industry to improve hiring if not for us then for the next generation. If you are in a position to influence a hiring process, reject the status quo if it doesn't make sense to you. If you are a job seeker, don't tolerate any shenanigans.