How to spot a great team during interviews

I've published this article on my blog in April, and it ultimately led to teamrank.dev, an app that ranks teams based on ideas presented here. Feel free to try it out and share your results!

How?! Well, by asking the right questions! 😁
While at techpilot.dev I've had my fair share of interviews, and although I've heard the most intriguing answers to the technical questions, one thing was always the same: it seems very few really want to know more about the team they might join in the future. 😅

I think it's a wasted opportunity, so here are a few ideas on what to ask.

Workflow

• How do they manage requirements and feature specs?
• What tools do they use in the process?
• Who is writing the specs? (i.e. there should definitely be someone and the answer should be prompt)
• Is the release process well defined?

Issues and bug management

• Are bugs fixed before writing new code?
• Where and how do they track bugs and issues?
• How do they prioritize and sort bugs? Who does that?

Testing

• Who's doing the manual/integration testing? (e.g. ideally a designated tester)
• Does the project have unit tests? What's their coverage?

Release cycle and automation

• Do they use CI? If so, how's the setup?
• What tools do they use? (e.g. Jenkins, Github Actions, etc)
• Do they build a daily/nightly version?

Growth

• If hired, will you have a mentor or a person that can help you with your career path?
• Do they review code? At what point in the development lifecycle? Who does it (i.e. peer, lead, etc)
• Do they have a library or do they buy tech books for their employees?
• Will there be any opportunities for greenfield projects shortly? (starting a project can be challenging, but also a great way to learn things!)

Workspace

• Is it quiet?
• How crowded is it?
• What equipment does each dev get (in general look for companies which understand that equipment affects your productivity)

Codebase, frameworks, and tools

• How old is the project? (the older, the greater the chance it's messy)
• What stack and tools do they use? (keep in mind you want a job where you fit or one that you can easily adapt to, so even opinionated views matter)
• Did they adopt a coding style? If yes, do they enforce it with a linter?

Team

• How large is the team you're going to be part of if hired?
• Who else shares similar responsibilities? (i.e. you want to avoid 1-man teams unless you know exactly what you're doing)

And if you're feeling bold:

• Ask how did they solve a particular task or architectural problem that you have previous experience with (e.g. "How do services communicate with each other?", "How are the private keys stored securely?", etc)
• Ask about the current team members' backgrounds. Make it clear you're not looking for personal information, but you're interested in the team maturity and experience (things like years in the field, areas of expertise, etc)

Finally, here are some things to avoid:

• Don't ask about things you're not genuinely interested in. Be frank and to the point. A never-ending interview can also mean a predisposition to never-ending meetings. (on both sides)
• Generic, mindless, low-effort questions. Although HR might like it, in a technical interview is best to avoid them and be spot on instead. Things like "How does your team approach problems in general?" "Are there opportunities for professional development?" should have an answer in the more detailed questions above. Asking them directly doesn't help anybody. Is like asking "Is this job good?". "Yes!". "Ok, that's all I wanted to know!".
• Personal details. You might think it would set a more familiar and relaxed tone, however, people have different views on it, and assuming otherwise is gambling with your chances: you might win, but you might also lose.