Ok this one is my favorite story1, and for many reasons. Personally, I aspire to mentorship stories. And these stories strongly showcase seniority and industry experience2. Some interviewers like to follow up and ask you questions like “What improvements did you notice”, “Talk to me about your mentorship style”, or “What cadence or schedule do you follow?”?
Alright, let’s begin!
Back at Capital One, I noticed a junior engineer on my team struggling. Seeing my own self in him, I hopped on a brief 5-10 minute slack huddle and I communicated that I’d help him get acquainted with our codebase’s backend.
I recognized his many positive qualities – his zealous passion, his hunger to learn, and his from-the-get-go excitement to deliver immediate pull requests and make an impact to our team’s codebase. But I also noticed his feelings of anxieties diving into new territory and tackling our application’s codebase – which was slowly transitioning from a monolith to a microservice that needed extensive refactoring to reduce code smells, bugs, and runtime errors.
I thought back deeply to what Google Technical Leads taught me. I wrote a couple of low-hanging one to two week JIRA tickets focused on refactoring our team’s codebase with ENUMS in place of constants, bolstering test coverage for our team’s microservices, and creating a new microservice to retrieve Enterprise assets. I could have done the work myself quickly, but I delegated the tickets off to him because I thought it’d make for fantastic learning experiences on his behalf. More ever, work delegation freed up my bandwidth to shift focus on more high-impact work, such as onboarding new customers, addressing automation gaps, and architecting cloud infrastructure.
I set up a cadence – on a weekly basis, over the span of three months, for approximately 15-minutes, I engaged in dedicated 1:1’s with him. We discussed a medley of topics – informal and formal – from best engineering practices to navigating organizations. In our 1:1’s, I taught coding skills such as writing clean code, introducing strong logging postures ahead of time, and thinking about bad inputs ahead of time. I also taught how to write satisfactory unit tests that stressed-tested out source code – tests that executed both succeeding paths and failing paths.
Over time, I noticed significant performance improvements manifest. His code velocity and frequency of change lists quickly increased. We spent less time in back-and-forth reviews, and the number of review comments I left for him dropped. His confidence grew too – knocking out easy tickets helped build his momentum; eventually, he started taking on more challenging tickets and feature requests.
harisrid Tech News 
Leave a comment