In a previous article I wrote 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 understanding about engineering culture and attitude. Given you can't asses technical ability through programming quizzes or by reviewing code, you must judge the engineer's mastery of software process and communication.

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.

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

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

"Debugging" in software is a process that varies in difficulty. How easy or hard it is to solve has nothing to do with the bug itself either. 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 Google Chrome and Internet Explorer? 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 this browser example rather than writing new code. They are reading Stack Overflow, pair programming, asking for code review, and searching for open source tools to resolve problems they encounter.

As a manager 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 checklist 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 they hit 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.

‍

Regardless about the amount of time 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 their weight in gold.

Programmers are unique. They're one of the few professions where outside the boundaries of their working hours they choose to do the same exact 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 addicting. It didn't matter how silly or important the problem I was solving with my code. 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. It's OK too if an engineer doesn't have any side projects. There's a stigma I don't always agree with associated with "side hustles." Having side projects is a plus, not a requirement. Your candidate doesn't have to always be programming to be a good candidate.

But if they do, the sign of true engineer is one 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 home grown projects is the sign of true mastery.

After your first technical hire you should delegate the task of finding new talent to that individual. You should still have the final say on hiring if you're the sole founder of your company though. But delegating is key. Why not even ask in the interview process how they would be hiring if the roles were switched?

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 their ego. You can measure a candidate's maturity by how they respond 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."

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

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 "bandaid" 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 software 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 as to not 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 warning.