I was recently reflecting on hiring and team management decisions. Particularly, how can you tell that a developer would make a good lead?
My current thinking on this is following. The most important differentiator of whether a developer is a good lead is the ability to see the project end state. While junior and intermediate developers are sort of coasting along, senior and lead developers are the ones who can formulate what exactly they are building.
Tricky part in this is understanding what bells and whistles will actually make it near future and which ones will not. In other words, key is to formulate what is the bare minimum for the project that more-or-less fits business requirements and is at the same time achievable by the team. Developers who get a good sense of this would likely make good leads.
It is interesting that lead developers may not be the best in terms of actual coding or technology expertise. So it is quite normal for teams to have management path for developers (to be a lead) and what I call architect path (to become technology expert). I know terminology may be confusing, as lead and architect terms are frequently mixed up in the industry.
Essentially, lead developers are the ones who envisions the end state and can schedule work from the prospective of end state. Therefore, lead developers are good at prioritizing work – simply because they know what they are building.
So how can we interview lead developer candidates? I would say, describe a hypothetical project (based on some specific project that you know really well) and ask what absolutely needs to be done to launch it. Ask about everything from recommended technology to desired team size and expected time frame. An answer you are looking for is a very concise description of specific steps needed. Certain questions posed by a candidate would also be a good indicator – i.e. trying to gauge performance characteristics or friendliness of early stage users.
Analyzing the candidate’s answer you need to try to match steps and technologies proposed to actual requirements as they were stated. Potential red flags for me would be something like proposing heavy stacks for early stage startup projects at prototyping phase (think Kafka for a blog platform). Similarly proposing light stacks for difficult problems (think WordPress for ML solution). Similarly mismatches in team sizes and time needed should also be considered as red flags. So what you are looking for is the answer that fits the problem and supporting questions that help candidate refine and better understand the problem. Good answer shows that candidate thinks about the end state of your project and thus would make a good lead.