editione1.0.8Updated August 24, 2022
You’re reading an excerpt of The Holloway Guide to Technical Recruiting and Hiring, a book by Osman (Ozzie) Osman and over 45 other contributors. It is the most authoritative resource on growing software engineering teams effectively, written by and for hiring managers, recruiters, interviewers, and candidates. Purchase the book to support the author and the ad-free Holloway reading experience. You get instant digital access, over 800 links and references, commentary and future updates, and a high-quality PDF download.
When defining a role, it’s crucial to consider its level—that is, what degree of experience and impact you need and expect from a candidate. Are you hiring a junior engineer, where they may require a significant amount of time to ramp up, or should they have enough experience to be able to hit the ground running? How independently can they operate? Are they going to be given well-defined tasks to execute, or will they have to proactively identify problems and break them down into solutions? How much of their role is individual work versus influencing and leading others?
In general, for higher job levels, less guidance is needed to achieve an outcome, and greater impact is expected of candidates. In a more senior candidate, this represents a mix of technical skills, soft skills, and experience or talent in technical leadership or management. Such candidates typically have more overall experience than junior employees, or have been at the company longer. A senior employee may be more involved in high-level planning and directing junior employees in the day-to-day work needed to meet an outcome, deadline, or goal.
GitLab distinguishes between increasing degrees of values alignment, technical competencies, and leadership competencies across their seniority levels, which they present in a career matrix. As an engineer progresses through levels of experience, they are expected to take on more capacity in each of those three domains. In particular, as the engineer’s level of seniority increases, they must handle a higher degree of ambiguity along with a greater scope of responsibility (The discussion on levels in the next section goes into further detail). GitLab captures this succinctly: “The most senior engineers may even be in a position where they know that something is wrong, but they are not exactly sure what it is—and they work to define the problem.”
When writing a role or job description, some translate skills or seniority into strict experience requirements, designating minimum amounts of time that candidates must have spent working on particular types of problems. For example, the requirement could be that a candidate should have “at least five years of experience developing Android applications.” After all, if someone has spent five years developing Android applications, a company can have some confidence that they have skill and interest in that area—enough confidence, at least, to interview and assess them.
confusionSeniority in a candidate is difficult to specify quantitatively. Concrete durations of experience, such as “five years in a systems engineering role” may be used, but durations are widely acknowledged to be poor and highly approximate proxies for actual seniority.
Your team will most likely be involved in the interview process, they may bring in referral candidates, and they will be working with the new hire day in and day out. The team is a resource for defining and refining the role, at any stage.
The process of defining a role may end up being iterative. A hiring manager may have an initial set of criteria, but as you share them with your team, and as you test them out in practice, it’s best to incorporate what you learn back into your criteria. For instance, maybe a certain set of skills is rare and extremely difficult to find; or maybe that set doesn’t really correlate with what you discover you need to hire for. Listening to your team along the way will help you iterate.