Tell me about a time documents

During my latest job search, I’ve found myself wishing I’d kept more detailed notes on situations encountered in previous roles. It’s led me to put together something I’m calling my ‘Tell me about a time’ document.

I’ve been interviewing with a small number of companies lately, trying to see if I can find a role that better fits what I want from my life and career going forward now that I have a kid.

In these processes I’ve ended up being asked a lot of similar questions, particularly on the behavioural interview front. People usually want to know exactly what you did, over what timescale, and what the results were. Due to the type of companies and roles I’ve been looking into, a lot of the time the interviewers have been specifically interested in hearing about things I was responsible for in the larger business of my role-before-last. As this was quite some time ago now I’ve had to put in quite a bit of work to look for details and piece together my memories – thankfully there’s a decent amount of information out there in blog posts and company reports, but it’s not always possibly to find everything you’re after! It’s much better to be able to confidently state “I took my org’s overall satisfaction score from 60% to 90% after two quarters” or “My changes reduced our build time by 20%" than to say “I increased my org’s level of satisfaction” or “I optimised our app”.

Even outside of the passage of time, I’ve also found that a combination of the sheer detachment of being off on maternity leave, plus some covid-related mental side effects have made me somewhat hazy memory-wise on certain details from even my most recent job, and less able to easily pull specifics of certain projects and timelines out of my short term memory.

I’m a big fan of companies giving a heads up of the topics that they’ll cover in interviews, simply because it gives me a chance to think of the best example rather than whatever pops into my head on the fly. In this situation, it saves a lot of time by using a centralised resource kept updated with your strongest examples, but if you’re pushed to come up with something on the spot in an interview you can also use this kind of doc as a swift memory nudge.

It’s made me realise that keeping better records on an ongoing basis will definitely help me into the future, so I’m committing to updating my document with stories from future roles.

I’m using this slightly different to brag docs

For a long time I’ve been using tools like Julia Evans’ Brag Document to keep track of wins, whether for me personally, to share with my manager, or to help reports celebrate their wins. However, whilst brag docs can absolutely be useful to help you remember some things, not all interview questions are around the shiny version of success that we often tend to put in these. Some of the stories you’re asked to tell in interviews are around times you’ve made mistakes, failed, things you wish you’d done differently, difficult interpersonal situations, or other scenarios that may not fall into the “brag” category.

In addition to this, other information I’ve found helpful to capture has been purely factual recollections of details like how my teams have grown and changed – for example the number of people when I took over vs when I left, the breakdown of different disciplines of engineers, diversity stats, or what products and technologies we were responsible for. A lot of this seems obvious when you work on it day-in, day-out, but I personally find the details get a lot more blurry over time. Again, some of this will be in your CV, but there are also aspects that won’t always be practical or appropriate to go in there.

I’ve ended up using a template that looks a little bit like this:

I’m currently using Notion, which lets me use the Toggle List feature to hide the full details and makes it easier for me to skim over the headings. You could also use a document with headings in a table of contents, or any other mechanism that you find easy to quickly parse (for those occasions where you may need ideas for stories on the fly!). You may also want to include certain keywords or use a searchable shortcut term to help you jump to specific content you have in mind to pull out facts and figures.

Prompts for managers and engineers

But what stories should you populate the document with? With the toggles not being unfurled, the image above isn’t super explanatory, and even the headings won’t be right for everyone depending on your role or the experiences you’ve had. Here’s how I’d suggest populating your doc:

You should ideally tailor your notes to the type of questions you’ve been asked or are likely to be asked in your future interview processes, where you know you’ll get something out of keeping track of specifics. However, to act as a starting point, here are some prompts that may be useful for engineering roles (mostly for managers and leadership, but some for engineers too):

• Times you’ve dealt with conflict or difficult interpersonal situations
• How you’ve approached managing underperformance
• Examples of helping others with their career development
• As a manager, supporting other managers with challenging situations
• How you’ve approached differences between managing ICs and managers
• Examples of successfully changing culture
• Times you’ve contributed to org design
• How you keep in touch with technology as a manager
• Balancing technical improvements vs product work/business strategy
• Leading technology strategy
• Approach to local/global engineering standards
• Build vs buy decisions
• How you approach prioritisation
• Managing improvement projects
• Breaking down large, ambiguous pieces of work
• Impact outside of your team
• How you approach measurement and metrics
• A time where it was difficult to meet a goal
• Team performance and delivery
• A time when you had to turn something around
• Managing remotely
• Collaborating and working with other disciplines
• How you define engineering culture
• Strengths and weaknesses
• Passions and motivations in terms of your career
• What makes your life difficult as a leader?
• How you influence without authority
• Times you’ve had (to manage) a difference of opinion about a technical approach
• Times you’ve broken something in production
• Proposing, getting buy-in, and delivering something
• Coordinating complex comms

Decide on your level of detail

As you can see, if you start to capture examples for lots of different topics, your document can quickly get a lot chunkier and less easy to parse!

It may be that you want to keep it small or even just focus on one area, such as details about projects you’ve successfully delivered. Other people may want to keep more extensive notes or write out a full narrative to keep your own memory fresh into the future. I’m somewhere in the middle in that there’s a lot I feel very comfortable talking about on the fly (e.g. I was recently asked about my preferred approach and experiences with QA testing, plus how I like to make technology decisions without consensus), but I prefer to have notes on specific outcomes and figures if I can. I also find short bullets with the basic heading of a story (e.g. “starting a Platform team”, “defining hiring processes”, or “progression frameworks”) helpful to help spark ideas if I’m reaching for a relevant example and coming up blank on the spot.

If you go down a slightly more detailed route, it could be useful for you to use a structure like the STAR(L) method (or similar, there are variants) to structure your thoughts. STAR, or STARL stands for Situation, Task, Action, Result (, Learnings), and in the context of your Tell Me About a Time doc you may want to use it like the following. Note that this is a purely hypothetical example!

Tell me about a time when you had to solve a problem in your team

• Situation: Some engineers were leaving, and the team would be under-staffed for the quarter ahead
• Task: As engineering manager for the team I was responsible for making sure that we had enough people to deliver our commitments well, and that we weren’t putting people at risk of burnout
• Actions:
  • I gave my manager a heads up that I was working on this
  • We looked at budgets for whether to make new hires but decided against this because time to hire + onboarding would be too risky
  • We spoke to the team and wider guild to explain the problem and what we were looking to optimise for
  • Volunteers self selected to move into the team, and I worked with the EMs for their teams to make the move go smoothly
  • We dialled down our commitments for a few weeks to give us more breathing room with onboarding and the new team settling in.
• Result:
  • The team managed to meet our delivery commitments, which ultimately resulted in a 10% improvement to revenue for that quarter.
  • Team satisfaction scores around autonomy and trust increased from 70-80%, specifically citing being involved in the move decision.

Thanks to Sigmund on Unsplash for the header image