When I started out as a developer in the last millennium (yeah ok in 1999…) – my first few jobs were landed just based on interviews. We sat down and conversed about who I was, what the company was looking for and how I might fit into that. That does not seem to be the norm for people starting out today. You go through technical interviews, coding tests or home assignments and maybe even different types of personality and/or logic tests. As you grow as a developer (sorry, engineer seems to be the trendy title), those might shift in complexity but maybe more importantly – they move into things like system design interviews where you might have to design a whole architecture and reflect on difficult choices and powers pulling in different directions. You need to show you can adjust your solution to the problem, the context and the constraints instead of applying a one-size-fits all solution to every problem.
If you are a tester, instead of architectural diagrams and leet code exercises, you might be asked to do a case study or a home assignment more aimed at test automation frameworks or maybe do a pair testing session with someone. Depending on seniority and niche, the shape might differ but the shift is likely the same – you go from showing you can execute to showing you understand the bigger picture, showcase you understand how to have a bigger impact, and balance between several possible solutions.
There are numerous guides, books, articles and even training to learn how to do well on these kinds of assignments. Even I myself have written about the case studies we used when recruiting testers before, as well as done several talks on the subject.
But what does this look like once you move into management?
I did my first management interview process in 2017. It was absolutely terrifying! I had little to no people to help me and I found very little – and very very scattered – information online on what I could expect. I read about email challenges, where you basically get to handle a swarm of incoming messages during a limited time. How do you reply? Which do you prioritise? How do you deal with conflicting instructions? I didn’t have to do that one but I got to do a case study. I felt completely out of my league, felt the instructions were very loose and vague and it was nerve wracking to present. But I got the job!
Since then I have lost count of how many different processes I’ve been part of. I have seen so many different types and styles of challenges meant to solve the same problem: How do we figure out who this person is and what they can actually do? Because you can’t do much more than scratch the surface during 60-90 minutes of talking.
I thought we could look at a few of them together, dig into some different types I’ve come across, and how I solved them. We will look into three different types split into two separate posts: This post will focus on Case studies and Dilemmas/Scenarios and in part two we will look into Assessment Questionnaires.
Just be warned – my results have been ranging from excellent to terrible so don’t trust me too much. 😅
Case Studies
I have done a lot of case studies. They seem popular when recruiting managers and while they have differed in exact scope – they have had a lot of similarities. The general idea is usually that you get a short description of a problem, a few (or many) questions relating to that problem, and constraints like limitations on presentation format, if you will get to present it yourself and when they need you to send it in.
The case studies have often revolved around the same type of scene: The organisation is facing a challenge (skill gap, hyper-growth, aggressive cutdowns, internal conflicts) – how would you approach the problem? (short term, medium term, long term). What resources do you need to do that and do you foresee any potential problems we need to keep an eye out for?
To show what this could look like, I’ve created an example case.
One case I’ve had to do described a group facing the need to up- or re-skill sharply. The group was lacking a lot of the skills needed in the future and there were internal forces trying to push testing out the door and replace them with ”more technical people” (read: developers or automation engineers). A lot of the staff had been employed for many many years and didn’t seem enthusiastic to make the shift. Unfortunately I did not save my presentation so I will just say that I chose a very lightweight approach and showed up with no slides, no presentation – just a notebook with a lot of comments and just as many questions and we had a great discussions about digging into the reasons why people were not moving into automation fast enough (fear, lack of time, no proper support and in some cases lack of ability) but also a lot of time on why the company wanted this change (a few strong voices pushing this agenda), the fact that I didn’t agree with it, and how likely it was that I could influence that (high, since my manager had the same thoughts). So – with that said: Don’t be afraid to disagree. As a manager, you are expected to speak up when you disagree, and be able to reason about it.
Another example was an organisation in aggressive hyper growth, with a strong desire to keep the culture intact, increase diversity and scale how we do recruitment. The questions were things like ”What culture makes a tech company an attractive employer? How would you help us achieve that culture?”, ”How would you plan the recruitment and onboarding?”, ”What resources do you need to succeed” and ”What anti-patterns do you see that we should avoid?”
Big questions to cover in as clear and condensed a way as possible – my presentation time was around 15 min if I remember correctly. Meaning you have to be careful which parts you focus on and stay abstract enough to be able to cover all ground, while detailed enough to show you know what you are talking about. I was lucky enough to have a lot of this covered in talks and articles already and I chose to focus on my strengths – which at this point was diversity in recruitment.
I’ve created an anonymized version of the actual case study for this. The approach I take to solving these is:
- Summarise my understanding of the task on a piece of paper in one sentence.
- Pick one aspect that I can use to show off my strengths and make some notes of previous experience (work, articles, talks) that I can use to showcase that.
- A high-level list of areas I want to cover.
- A list of any constraints or hints I can find in the case.
- Flesh this out on a slide deck with as little detail as possible in the slide design. If I need to – I add speaker notes with details and any links.
- Practice presenting this until it feels comfortable and fits into 75% of the time allowed for the presentation.
I don’t try to cover everything, I don’t try to justify every decision, I don’t try to explain every detail. Just enough to show that I know what I am doing and make them want to hear more.
As a hiring manager, I’ve used this type of case myself in a lot of my recruitments and when reviewing In the written case look for things like:
- Have they understood the assignment and are they sticking to that?
- Do they showcase previous experience or an ability to reason around and solve the problem?
- Are they able to pick a relevant level of abstraction or are they either not saying anything or getting into way too much details?
And in the presentation I look for other things, like:
- Time management. If you have 20 min, you can’t spend 45 out of a 60 min interview.
- Can they expand on things when asked clarifying questions?
- If challenged, do they reflect on it? Do they ask questions to clarify things? Are they able to argue their viewpoint but also understand other opinions?
Dilemmas
A couple of times I’ve had to reflect and discuss a few difficult scenarios. Sometimes I got them sent to me ahead of time, sometimes they were just asked on site.
The scenarios have often centered around how to deal with conflict, underperforming staff, balancing technical debt vs delivering new features, collaboration with product counterparts and similar areas. The difference to scenario based interviews (”Tell me about a time you had to give someone difficult feedback”) is that these are phrased as small scenarios that you need to reflect on how you would approach it rather than how you have approached it, leaving it more free to choose if you use examples from real life or not.
I remember one particularly: A person in your team had been behaving badly for a long time, without anyone taking any action. People were really badly affected by the situation and some had started leaving. I remember it so strongly because it focused a lot on the ”this has been going on for a long time” and ”this is affecting many people”. My reaction to it was pretty strong and I was quite firm in the need to take action, some action, and make sure this did not continue. I strongly emphasized the need to make sure the other people saw and understood that someone was trying to change it. Unfortunately the interviewers felt I was too harsh and wanted a softer, more coaching leadership – which I felt the scenario clearly described was too little too late. You can’t win every time! I clearly did not show that I of course would not jump straight to firing the person in my urgency to show that it is crucial to stop bad behaviour.
Another time I was asked how I would help solve a situation where a particular role was no longer needed and how I would go about helping the organisation re-skill the individuals, or coach them to leave. (This seems to be a recurring theme – which I honestly did not notice before writing this…) In this case my response was that I would focus on helping the individuals find companies that valued their skills – unless they themselves were eager to find a new profession. I am not the smoothest person alive it seems, but I am honest.
While I haven’t used them personally for this kind of thing – ethical dilemmas is something I use in other situations. They are typically written in a way where
- There is no universal right or wrong
- There is something not great going on, but it is not bad enough to warrant anything like instant firing
- There are multiple layers to the problem that you have to consider, and the interviewer can point those out if the candidate’s reply is very black and white
How I see it, the idea is mainly to show how you solve problems and which values are important to you. Can you reason around your choices, do your values align with the company, are you able to adapt and adjust to new information.
Takeaways
One big challenge when moving from IC into management is that our perspective changes and the problems we need to solve shift. It can be really jarring and I remember that trying to figure out how to map my experience to the questions asked in manager interviews was really hard, to be honest I still feel that way.. Sometimes it’s simple: “I grew my team from 3 people to four teams with 25 people in total”, “I increased our speed of delivery tenfold”, “I reduced our tooling cost by 50%”. But a lot of times it’s a bit vague and fluffy. You might no longer have impact directly, but through your people or over a long period of time – how do you measure that? Do you measure and track that?
I know I would have needed something like this to help me a few years ago and I hope you found something in this first half to help you be more confident and shine brighter in your next interview.
In the second part we will dive into Candidate Assessment Questionnaires, which is a fancy name for a hecking extensive list of questions that you get to answer before the interview, to be able to get more in depth in the actual interview.
See you soon!
