Answering the "Hands-on" question

When I interviewed for leadership positions I heard this one a lot: Our team leaders are hands-on. Do you mind coding X% of your time?

The answer is, always YES. There you go, problem solved. Move on to some other article. Don't overthink this.

Still here? You must be wondering; did I just answer Yes in all my interviews? I'm glad you asked, because I didn't. I gave the wrong answer <gasp>. Put on your thinking shoes, we're going for a walk.

... the hands-on requirement cannot be taken "as-is". It is unlikely to reflect the job's day to day and it requires [much] context-switching

Think about it like an engineer (show me you can hands-on):

1. If I answer "No", I will be disqualified (I mean, c'mon, this question is not an optional skill). This is not an option, I want as many offers as possible!
2. If I answer "Yes", when I cannot really hands-on, I may get a job, or not. In the future I may need to hands-on, or not. The future is a while away - even if I cannot hands-on to save my life, I can learn how in a weekend or two ... right?
3. If I answer "Yes", when I can do it, then I'm right as rain, right?

So why-ever answer No?

This question is asked when an offer is a long way away

This question basically asks the candidate: Do you know how to code? Will you code to achieve our company goals? This company wants to verify you can serve in both an engineering and a leadership capacity. The question does this in a strange way, as if declaring intent so that later someone can say "but we told you it's hands-on!".

I’ve observed that regardless of what is said in interviews, the amount of hands-on work a team leader does varies wildly. Consider a few scenarios:

• An existing team maintains several projects, I'm the new team leader, so my first order of business is to establish trust in my capabilities, trust in my intentions and learn the new codebase I'm responsible for. I will fold back my sleeves, pick up my two-handed great-board (that’s a kind of keyboard you get from playing d&d) and start swinging at the code. When I've gained some context and established the priorities of the team's operation I can dial it back; reduce my hands-on-ism and start the real work of managing the team.
• A team that is drowning in damage-control and fire-extinguishing, one more bug-smasher won’t do us much good. Better use my time to work with Product on reducing all the flames at once; speak with clients and tech-leaders to understand the weirder eisen-bugs; pair with my developers to understand their pains and the bottlenecks holding us back; dedicate a chunk of time to plan and get the resources we need to build the automation we’re obviously missing.
• A large team is breaking apart, deteriorating in morale and purpose. I cannot focus on the code here, I barely have time to get to know it. My top priority are the people, their cohesion and the team's goals. The overhead of executing with a large team means that ignoring the management responsibilities will drive the team to the ground. The code is just a conversation starter here.

In a management position, the hands-on aspect will constantly change, the average is useless here. It may go up or down or stay for a while; expectations must be clarified before I accept an offer. But this question is asked when an offer is a long way away. The screening call is not going to get me the details I need to make a choice here.

So this is a trap.

I think this trap exists because our industry has an incredible variety of ways of doing what we do. This is the same reason for the many (sometimes contradictory) definitions of what a Senior developer is, or what Tech leads' responsibilities are.

The "hands-on" question is a product of job descriptions that try to find someone to do everything: senior engineer, leader, manager, administrator and best buddy for the team that has the opening. It was modeled after a specific person who did amazing work, or some kind of imagined ultimate team-leader checklist, like "all team leaders must have these six qualities" posts.

I realized the hands-on requirement cannot be taken "as-is". It is unlikely to truly reflect the job's day to day and it requires an unusually high degree of context-switching and stamina. I found that ignoring the requirement sets me up for failure. Having observed the requirements of a position I could just say "no" to any hands-on position but I was looking to maximize offers.

So, I did not say "No". On the other hand, I avoided a blanket "yes, sure". I chose to set expectations during an interview, which is the wrong answer.

Dear reader: I took an awful risk. The answer below is wrong for many reasons. I do NOT recommend you follow my example in this.

Why is this the wrong answer? Setting expectations during an interview disrupts the engagement, invites more scrutiny into what should be an obvious answer and confuses the interviewer - not the place you want to be. If you remember my past post about it, you want to give the interviewer an easy time to say "Yes" - obviously I am the right candidate because I gave simple, straightforward answers to all questions. By discussing expectations before having Edge and giving a clever answer I am going against my own advice. Be warned, these lines may be written by a mad-man.

My level of hands-on changes, depending on what we’re doing

This answer had to be cohesive, adaptable and present as simple a solution as possible… I prepared and rehearsed the following answer:

"I know how to program. In my day-to-day as a team leader I will use all of my skills to achieve the most effective results. If the best use of my time is to program, I will do so. As long as we agree on the goals, the tools I use will fit what we want to achieve."

If I was asked to explain, I had a follow up prepared next:

"My level of hands-on changes, depending on what we’re doing. Early in a project my involvement with technical choices is relatively high. As we make progress I slowly delegate the technical choices and step back. I switch to coaching the project owner and the team. I use my time to monitor and review results. If my direct involvement is required, I can dive right back in."

Take a moment to read that again, I'll wait.

I believe this is a professional answer; it answers the question upfront, presents options and discusses my effectiveness in different situations. It focuses on results. It shows adaptability, awareness and initiative; my strengths. It discusses the skills I use and how effective those are in achieving company goals.

In a way, it's a tiny summary of the entire interview. It's the wrong answer, but it's also the best answer I can give to such a difficult question.

[... be] aligned on this critical, dynamic, delicate balance [in your future job]

Some interviewers were surprised by this answer and asked more clarifying questions but in the end I didn’t get any complaints from them. But then, some sent me a rejection email, so maybe we were not quite aligned.

I had one CTO dig into this for 30 minutes, astounded that I consider this a well-thought-out position. I did not get a detailed thesis from him but got the impression he felt that all that "management stuff" is a waste of time. Better I was coding and "showing the kids how it's done". I think I'm overpriced for that position, and they did not extend an offer, so I guess we were in agreement on that.

The hands-on question is important for Team Leader positions. Regardless of what we think about it, this is a sought-after quality.?The problems start later, when the different ways of interpreting "hands-on" become apparent.

Make sure you and the interviewers are aligned on expectations for this critical, dynamic, delicate balance in your day to day work. Pay close attention to what you're asked as follow-up. Note the sticking points; the questions that are asked in a few different ways; the answers that get a non committal "hmmm". When you have gained your Edge, verify you and the management see eye to eye beyond the formal requirements.