On building a great engineering team

What I Look For, When Hiring A Software Developer 🕵

Refined over more than a decade, the process works pretty well for me 👍

7 min readMay 7, 2024

TL;DR:

I’ve interviewed my share of dozens of developers, as a senior member of a number of mobile software engineering teams.

And a recent discussion about effective (and ineffective) ways to screen developer candidates … provided an opportunity to articulate my own thoughts on the process.

I hope you find it helpful as well.

But, sssh! (Don’t share this with the candidates.) 🤓

First Things First

Before anyone on the team even talks with the candidate … I ask H.R. / Recruiting for both (1) a resume, and (2) some sample code.

I’ll glance through the developer’s history to get a general idea of what they’ve done, and jot down some questions to ask.

But, Spoiler Alert:

Overall, I DON’T really care that much about their resume.

Because I’ve found that education and job history often do NOT correlate well with the quality of the actual work the person does.

One thing I do notice (though perhaps it’s non-intuitive):
Too many years in too few places can actually be a yellow flag.

It’s true — as the old adage says, “ten years’ experience” might indeed equate to “the same one year’s experience, repeated over & over again.”

So while that may or may not be a concern, ideally I’m looking for someone who’s shown themselves to be adaptable, with grounding in a variety of codebases (and even companies). Because I know from my own experience that there’s different learning to be had in each unique situation.

And if they’ve been in the same routine for a long time, they could be more set in their ways, and less adaptable.

Next, What Actually Matters 👋🏻

More importantly, I’d asked for “some sample code.”

And I deliberately worded the request just that way, to be very open-ended — a Rorschach test of sorts — with no stated requirements at all.

As a result, I’m pretty flexible in terms of what I see. And because of the vague description, I’m not expecting a full-blown application architecture.

I do want to see good engineering practices … including decent sensibilities around single responsibility; loose-coupling and separation of concerns; good readability and naming conventions [cryptic function and variable names are a red flag]; D.R.Y. (and avoiding hard-coded constants); and more.

Automated tests (if provided, unsolicited) are a plus. So are comment blocks for classes and function interfaces.

I assume that the candidate wants to make a good impression, and thus, that they consider theirs an example of reasonably-good work.

So I’m looking out for obvious anti-patterns and other kinds of sloppiness.

And I don’t want to waste the team’s or the candidate’s time with any meetings, if the work itself isn’t up to some meaningful level of quality. (It is, after all, the ultimate deliverable of the job.)

Therefore, if anything falls especially short, then it’s a thumbs-down. 👎

Let’s Get Technical

If they’ve gotten this far, I’ll typically have another (mid or senior) team member whose sensibilities I trust do a basic tech screen, however they deem it appropriate for the specific role. Then we discuss their impressions. And I support their assessment: if they think it’s not a good fit — either technically OR in terms of personality — then I’ll pass.

There’s too much at stake, both in terms of onboarding effort, and potential disruption to the dynamics of the existing team, to bring someone on whom the team isn’t uniformly positive or enthusiastic about.

And yes, personality and attitude is a potential deal-breaker. We have to feel comfortable with the candidate as a person we’d enjoy working and collaborating with, on a daily basis.

So, obvious ego (or ill temper) is generally a bad sign.

Because, while a reasonably-smart person should be able to pick up domain knowledge as needed — we can’t change basic personality traits. So there’s not much use trying there.

We’re Going In, Full-Throttle

If they pass the initial tech screen, then I’ll do my own screening, either alone or with another trusted mid- or senior-level team member. If it’s the two of us, we’ll tag-team different types of questions over the course of an hour.

For my part, I use a “broad-spectrum” approach, covering a number of different (even seemingly-random) topics, at differing levels of depth, to help me paint a picture of the candidate’s overall knowledge and experience.

I also let them know that’s what I’ll be doing, up front — and assure them not to be concerned if they don’t know an answer: just to be honest about it, and we’ll move on. (And that, yes, the approach can be a bit unconventional.)

I certainly don’t expect anyone to be able to answer everything. And I adapt the questioning as needed, as we go along. (We’ll likely ask about their sample code as well.)

I also want to provide a good 10 minutes at the end for the candidate to ask their own questions. (It’s only fair — after all, they have their own potential decision to make — and it can also be revealing, in showing some of their own thought process.)

Checkpoint

Next, the team shares their immediate feedback (possibly in conversation, or just in email). One of us will compile the results, along with a yes/no or stack ranking (relative to other candidates), and our recommended next steps. We’ll send that back to H.R. / Recruiting (who generally want some kind of written record anyway).

To Code, or Not to Code 🤔

If we’ve seen code they’ve written, and like what we’ve seen — and it covered sufficient ground — this step may not be necessary.

But I still reserve the right to run the candidate through a coding exercise.

If we do opt for this, it’d be a simple, real-time, practical exercise — like a mini-app that can be built in 30 ~ 60 minutes.

This would be multi-faceted enough (business logic, data layer, possibly service-layer, and certainly user interface) to get a feel for how they approach different aspects of a codebase.

As we go along, I want to hear them talk about their thinking and process. And if we run out of time, that’s OK. It’s not essential to get a working app.

What I am looking for is a sampling of the skills they’d really need on a daily basis — including being able to follow, discuss (and even appropriately question) the stated requirements. And that the code we were sent originally was, in fact, a representative example of their coding style & ability.

And importantly, I want to get a sense of what that person is actually like to work with in the trenches together.

Worth noting:
The exercise would NOT involve C.S.-style brain-teaser questions. That is NOT the work we’re hiring them to do.

And Finally …

Depending on the org, other steps may include meeting(s) with one or more stakeholders.

And every one of the above steps is a gating mechanism. Any thumbs-down ends the process for that candidate. ✋🛑

Then, if we’ve gotten this far, we meet as a team to discuss and make a final decision.

And The Winner Is …! 🏆

The team — if the process goes well.

Of course, every team (and org) is a little different. And so, I hope there are some ideas above that your team finds useful. 🎉

And special thanks to Leng Trang, Dan Bergquist, and Joseph Nash for prompting such an invigorating discussion.