As an individual contributor, my inbox and chat messages were manageable. Tackling them as they arrived felt productive, and context, switching away from deep work was a welcome mental break.
Moving into management changed everything.
With direct reports, broader responsibilities, and an expanding network, communication turned into a continuous flood. My instinct was to lead by example and be fully accessible, answering every message and thread immediately.
The result was a classic trap. Important strategic tasks got pushed later into the day until they weren’t getting done at all. My fallback was working late into the evening when it was quiet, which quickly eroded my personal life and personal admin.
The turnaround required two things: shifting my mindset around availability, and implementing strict time-boxing, dividing the day into dedicated blocks for Email, Meetings, Team Support, Deep Work, and essential buffer time.
Human cognitive capacity is finite. Research on context-switching demonstrates that every interruption carries a heavy recovery cost, taking an average of over 20 minutes to regain deep focus on the original task (Mark et al., 2008). Furthermore, continuously juggling unstructured inputs rapidly exhausts working memory and executive function (Sweller, 1988).
Trying to be everywhere at once doesn’t make you a responsive leader, it creates a bottleneck and triggers decision fatigue.
By applying Parkinson’s Law, the principle that work expands to fill the time allotted to it—time-boxing creates firm structural boundaries (Parkinson, 1955). It protects high-value work, prevents reactive demands from hijacking your entire calendar, and forces you to trust your team to resolve issues without your real-time input on every thread.
Segmenting your day isn’t just a scheduling hack; it’s a fundamental leadership skill.
Perfect Software doesn’t exist
Everyone thinks they’re the only good driver on the planet, yet we all still drive defensively. That’s exactly how we should approach writing software.
We are constantly interfacing with other people’s code - code that might not live up to our high standards…
At a minimum, two people work on the same code: you today, and you a few months from now. Look back at code you wrote a while ago and you’ll probably find yourself scratching your head — no one writes perfect code, not even you and I.
Test what you write. Make sure you’re as confident as possible in what you deliver.
Stick to small steps.
I can’t stress this enough, and it’s harder than it sounds: write code in small increments.
Write, test, commit, open a pull request. Rinse and repeat.
It sounds like more work, but in my experience, 10 small pull requests get reviewed and merged faster than one big one with the same changes combined.
]]>My editor of choice is Visual Studio Code and I use my favourite web browser, Firefox to preview my work.
]]>During the challenge, candidates are usually observed by one or more experienced engineers from the hiring company. This matters: it reveals not just technical ability, but also how a candidate communicates and solves problems under pressure.
The challenge should match the candidate’s background, particularly what’s on their CV. If someone claims ten years of JavaScript experience, I expect that to show in how they perform.
Nobody can memorize an entire programming language, and candidates shouldn’t feel they need to know everything or stay perfectly composed throughout. If they get stuck, I’d rather they ask questions — that shows confidence, self-awareness, and honesty, not weakness.
I expect candidates to stay engaged: asking questions, thinking out loud, and talking through their approach as they work toward a solution. A solid grasp of core programming concepts — control flow, variables, operators, and expressions — is expected too.
Having sat on both sides of the table, I’ve found the best sessions are the ones with real back-and-forth, even a bit of laughter along the way.
A live coding challenge works best when both sides approach it with honesty and empathy: it’s on the candidate to be open about what they know and don’t, and on the interviewer to make the process feel safe rather than adversarial.
If the challenge feels daunting, the problem is often not the format itself, but the atmosphere around it. And if that’s the case — maybe you don’t want to work there after all.
]]>The columns include the candidate’s name, several key areas of interest, relevant criteria, and a scoring system.
Example:
| Candidate Name | Java | Oracle | Docker | Spring Boot | Git | HTTP | Team Lead? | 3+ Years at Company? | Finance Sector Experience? | Score |
|---|---|---|---|---|---|---|---|---|---|---|
| Joe Soap | 1 | 1 | 0 | 1 | 1 | 1 | 1 | 1 | 0 | 7 |
Suppose I’m searching for a senior TypeScript software engineer with expertise in React, TailwindCSS, Jest (for testing), ESLint (for code quality), and web applications. Ideally, the candidate would also have experience with structured products in the finance sector, plus leadership experience — either leading a team or serving as a technical lead.
From that description, I can pull out the following keywords and conditions:
ESLint
A few additional conditions I like to add:
Now it’s time to set up a spreadsheet with the following columns:
Each column is worth zero or one point. Depending on how important a criterion is, you can weight its column to reflect that — for example, if TypeScript is a critical skill, multiply its score by three.
Once the spreadsheet is set up, start reviewing résumés and score each candidate by asking questions like:
At this point the candidate has two points — you get the idea for the rest.
The maximum possible score is 13 points (one per keyword or condition, more if columns are weighted). Review your resumes and focus on the candidates who score highest — say, 10 or above, or simply your top 10. Adjusting the weights lets you tailor the process toward whatever skills matter most for the role.
Some criteria are closely related — strong ReactJS skills without a solid JavaScript foundation are unlikely, for instance — so it’s worth considering related columns together rather than in isolation.
Feel free to experiment with and refine the scoring formula to suit your own hiring process.
]]>I believe engineers who switch jobs every six to twelve months miss out on valuable opportunities for growth. They rarely stick around long enough to see the long-term impact of their contributions—good or bad—and experiencing that impact is essential for professional development. By the time they’re through the initial ramp-up phase and start making real progress, they’re already moving on. That’s costly, both for the engineer and for the team left behind.
Recruiting and hiring software engineers who are a good fit for the team and company culture is both challenging and expensive—though still cheaper than hiring the wrong person. That’s a conversation for another time.
The first year is about acclimating to the company: learning the people, the processes, and how things operate over a full fiscal year. It’s about getting grounded in the role and building a solid foundation.
The second year is when an engineer starts to make their mark. The “new person” phase is over, and they take full ownership of their work. This is when they begin to shape their reputation, build trust, and contribute meaningfully to the team’s success.
By the third year, the engineer has a deep understanding of the company, its technologies, and its challenges. They’re often the go-to person for specific applications or technical problems, earning the trust of colleagues and gaining additional freedoms. This phase brings greater fulfillment, as the engineer sees the tangible results of their work and takes on more significant challenges.
This cycle of settling in, making an impact, and growing can continue without leaving the company. Engineers can switch teams, take on new projects, explore different roles, or expand their responsibilities. Staying with a company long enough to fully grow into these opportunities not only benefits the engineer but also the company, fostering deeper expertise, stronger relationships, and a more cohesive culture.
]]>