People: How do you determine which attributes to hire for, in software engineering?

Tips on considerations before hiring into your engineering team – from the 2020 series of Threads discussions.

Discussion host: Adam Dangoor, senior engineer, technical interviewer and interview coach.

Context

Software engineering functions follow natural phases of maturation that largely reflect the status and sophistication of the product being developed, often along the lines of;

• Startup: getting something from nothing
• Scaleup: making something maintainable, of higher quality, and more featureful
• Maturing: keeping something running that’s now much bigger

The company, its engineering function and its products/projects can each be at different stages, and each have its own sub-culture and approach – provided the mission is well understood and bought into.

Identifying hiring needs

Think about the nature of the product features that you need to deliver, e.g. MVP vs high quality, this may depend on your product requirements, domain and customers.

Ideally, your hire should be naturally enthusiastic about the stage of the product and its upcoming milestones. You don’t want someone who ‘can’ do it but who *wants* to do something else, or they’ll become unfocused – or may leave.

A team as a whole may need people with qualities that are both ‘fast and fluid’ and ‘careful and steady’. Hiring managers may settle for a ‘manageable’ middle ground in each incremental hire but, with healthy team dynamics (e.g. trust, good process for compromise) everyone should see better outcomes overall from more diverse hires.

Hiring the right software engineering attributes

At times you may need to attract someone who can take a rough concept and turn it into something. This person won’t likely be as motivated by long cycles of implementation, support and maintenance, but they’ll likely be keen to innovate further or to begin other new work – as part or most of their ongoing remit.

It’s entirely possible some of your best people are doing the ‘wrong’ kind of engineering work and may leave as a result. Much better is to understand each as an individual; try asking “tell me about your favourite type of work or hobby projects” and listen for clues.

Also consider which professional skills are most important and be explicit with your assessment of these highly useful abilities: e.g. listening to customers, or making decisions as a team, or communicating concepts with less-technical people from other functions.

Founders of fast-growing business may have become too removed from the reality of the day-to-day engineering needs to make hiring decisions alone. Whereas if the team does it alone, maybe they are fighting for today’s problem when the founder better understands the future vision. Ensure you’re all on the same page and unify the approach.

Validating hiring needs

Interviewing isn’t the place to validate the thinking; it’s wasteful of engineering time and the candidate’s time e.g. a junior gets to the end of the process and the company says “we don’t want juniors right now”. This also gives a poor candidate experience and word spreads.

It can be a good idea to consider what weaknesses/gaps the current team has and consider: was this attribute ever assessed? E.g. “Do we have problems shipping software?” if yes then “why is our hiring process assessing whether someone can begin from scratch, and not whether someone can deliver in the end?”.

Consider whether a potential addition to the team blocks or releases an existing team member to progress at the pace they’re ready for. It’s more attractive to offer someone a doable ‘step up’ than a ‘sideways move’ – unless there’s another good reason for the change. You may want to re-jig the team in readiness for its new member.

Preparing for interviews and technical assessment

Interviewing time flies, so each interviewer must plan to assess each attribute weighted by priority with minimal overlap to avoid duplication. Failing to do so risks missing an important attribute and makes it hard to draw conclusive comparisons.

In a services firm delivering software projects or which don’t own the product IP, don’t underestimate the value of a representative ‘trial day’ to allow an authentic try-before-you-buy experience for both parties. This should be paid as if work.

Once all parties are aligned, get someone to independently verify whether the dimensions of the now role are realistic – in balance with the pay, nature of work offered and the personal progression available.