In a previous article, I wrote about how to interview engineers when you're not technical. Given how popular this post was, I decided to publish a second round of questions that founders and managers can use during interviews.

Remember: The goal is to ask questions that surface an understanding of engineering culture and attitude. Given you can't assess technical ability through programming quizzes or by reviewing code, you must judge the engineer's mastery of software processes and communication.

Here are the most popular follow-ups from my own experience and those of readers.

‍

Problem-solving

How do you unblock yourself if no one is around to help?

An engineer can be stuck on what seems to be a trivial bug for days and even weeks. Key to an engineer's success is the ability to unstick oneself.

"Debugging" software is a process that varies in difficulty. How easy or hard it is to solve has nothing to do with the bug itself. In programming, complex problems can have simple solutions. But the opposite is also true. Simple problems can have horribly complex solutions.

Case in point: web styling and CSS. Ever notice a difference in how certain components look between browsers like Safari and Google Chrome? Well, there are thousands of lines of code written by engineers just to make design patterns compatible across both. They don't always work either.

For most engineers, the majority of their hours are spent debugging code, like in this browser example, rather than writing new code. They are reading Stack Overflow, pair programming, asking for code reviews, and searching for open-source tools to resolve problems they encounter.

As a leader, you might think that's crazy. How could anyone call themselves a "professional" and be paid six figures when over half their day is just googling how to fix something that doesn't work?

An engineer's ability to debug code can vary just like their ability to write code. You could argue they are the same skill (writing and debugging), but engineers think of them as separate. Reading code is very different from writing it.

The very best engineers have a methodical process they apply depending on the type of bug. Spelling mistake? Nope. Wrong file? Nope. Wrong environment? Nope. Import error? Yes. They repeat their checklist for every bug and grow their list over time. They also use tools to help them debug like ipdb for Python, Valgrind for C, and countless others for different languages and frameworks.

If an engineer has a coherent strategy or demonstrated experience for how they would unstick themselves, they deserve strong consideration to be a part of your team.

‍

Thoroughness

What does "done" mean to you as an engineer?

Regardless of the amount of time spent debugging, how else is a developer's time spent? How does a developer know when they're "done" with a problem?‍

"Done" is a nebulous word for engineers. It's an opinion to them but a "yes or no" answer to everyone who depends on them. An engineer can always write more tests, refactor and simplify their code, document their work with comments, and update the README. For some engineers, "done" means getting their code working. But does it look good? Not quite. Is it fast? Not at all. There's always more work to do.

"Done" can mean many things. So defining this is your responsibility as a manager. Finding an engineer who has an articulate description aligned with your interpretation is worth its weight in gold.

‍

Side projects

Could you talk about an app or program you built to solve a problem for yourself?

Programmers are unique. They're one of the few professions where, outside their working hours, they choose to do the same thing they do at work: programming.

Earlier in my career, I spent hours on weekends, late nights, and early mornings building things. It was all voluntary because programming is addictive. It didn't matter how silly the problem I was solving with my code was. It was fun. And many engineers build apps that solve fun problems in their free time.

There are countless ways engineers choose to spend their off hours. Some contribute to open source. Others take online classes. Some are tutors, and others work a second job as a freelancer.

Asking about side projects is the best way to learn about their enthusiasm for code, but it's also OK if an engineer doesn't have any side projects. There's a stigma I don't always agree with associated with "side hustles." Your candidate doesn't always have to be programming to be a good candidate. Having side projects is a plus, not a requirement.

But if they do, the sign of a true engineer is one who can build tools, not just one-off solutions. Software tools require a degree of flexibility and planning, and a level of abstraction not commonly found.

What's the difference between a solution and a tool? A solution is something the engineer can use for themselves. A tool is something both they and others can use. Open-sourcing homegrown projects is a sign of true mastery.

‍

Building a team

How would you find, interview, and hire other engineers to join our team?‍

If you're the sole founder of your company, you should still have the final say on hiring. But delegating is key. After your first technical hire, you should delegate the task of finding new talent to that individual. During the interview process, I'd ask how they would be hiring if your roles were reversed.

There is a lot of solid hiring advice for startups. Hire slowly—you should always feel the pain of not having enough team members before adding another. Fire fast—the one regret founders cite most is letting bad employees stick around too long. My addition to this wisdom: hire a team that builds itself.

Asking potential candidates how they would find the best talent and grow the team demonstrates trust. There's no greater responsibility than having the ability to decide who's accepted into the tribe and who's not. Communicating this early shows you're serious, and it also tests the candidate's ego. You can measure a candidate's maturity by their response if asked, "How would you hire someone for the same role if we hire you, or even a manager for a role above you not yet filled?"

This touches on a perfectly worded quote by Arthur Conan Doyle: "Mediocrity knows nothing higher than itself, but talent instantly recognizes genius."

Simply put, talent recognizes talent and is not intimidated by it. Find engineers who feed off the positive energy of others.

‍

Handling tradeoffs

What's the one thing you would not compromise on as you write code?‍

As a developer writes software, there are tradeoffs at every step. Some programs that take weeks to build can also be written in just a few hours if you know what shortcuts to take. How do you find a balance of speed and quality?

It comes down to your long-term pain tolerance. If an engineer has no regard for writing tests, documentation, or refactoring code, their work will morph into a Gordian knot of software known as "duct tape" or "band-aid" code. "I'll go back and fix this later" becomes the status quo and never actually happens.

To some engineers, this is standard. Others are more methodical, making time as they work to refactor and abstract. Some joke that reading others' code is more difficult than writing your own, so deleting and rewriting code that's not yours becomes easier than adding to it.

Ask your engineer what they are not willing to compromise on. What must be part of each sprint they complete so they don't go crazy later? It could be test coverage, code syntax, formatting, or even cleaning up merge requests and maintaining branch hygiene. Whatever it is, ask your candidate what is important to them and why. If they don't have an answer, it's a red flag.

‍

Concluding thoughts

Hiring is tricky. It's especially hard if you don't have mastery of the skill you're interviewing candidates for. Imposter syndrome sinks in. "Am I even qualified to be doing this?" Maybe not. But who cares? You have the questions to surface everything else that is important about hiring a team of engineers. And once you hire the first one, you'll have help the rest of the way.