Tim Gent

Clearing System Design interviews at the Staff+ level remains a mystery. Even if you go for best-in-class courses, like HelloInterview by my colleague Stefan, you're often left on your own to show your experience. Sys Design is hard - you need to master foundations, manage time and comms, make solution future-proof, etc. Common prep materials make it worse with overly complex examples like social platform ranking systems or Dropbox-style sync protocols. The truth is: on Staff+ interviews they ask relatively simple questions to test depth, not speed. You won't waste time drawing 20 components - they want to see how deeply you think instead. I don't know the full formula to clear Sys Design rounds at this level, but can share what was working for me personally: 1/ Learn the fundamentals: things like GFS/Dynamo/RocksDB papers, behavior of distributed systems under high load, data locality, over-provisioning, clocks, replication lag, consistency models, use scientific notation, etc. Example from Anthropic Sr Staff interview: - Me: "I don't remember the exact metric name, but we trigger provisioning when we detect this resource utilization pattern." - Interviewer: "Oh, we call it metric X, and pattern Y, and the way you're describing it is how it works in our system." Pro tip: share some anecdotes, e.g., "we don't need persisted state from the get-go, but it was a nightmare to revoke stateless sessions on my previous project". 2/ Become good at sizing the problem. Know the population of key countries/markets, understand seasonal usage patterns across days/weeks, distributed systems fundamentals - like maximum dataset size for RDBMS, DB index overhead, key latency numbers, etc. Example from Google L7 interview: - Me: "Let me quickly quantify the system. For this problem, I'm estimating the population size to be in the mid-hundreds of millions, let's say it's 500M, but I will round it up to 1B." - Interviewer: "Actually, in my reference notes I have 500M, so let's keep it like this, so it's easier for me to compare the final numbers." - In the end, the final numbers checked. Pro tip: casually drop some fundamental reference, e.g. "By Little's Law, RAM won't bottleneck this cluster given our latency and throughput targets". 3/ Start and finish simple. Most real systems avoid expensive services like Kafka, complex client/server protocols, or real-time UI updates. Example from my current role's interview: - Me: "I'd just hash the input and denormalize the schema to avoid excessive DB upserts. Not the fanciest approach, but it works". - Interviewer: "Oh, this is exactly how our system actually works". Pro tip: research the company's tech stack, and don't be shy if you're not familiar with it: "I haven't used GCP, but we solved similar problems with AWS service X".

110

5 Comments

Excited to be speaking Today at SRE Day London 🇬🇧 Production today is messy. There’s noise, complexity, and a constant stream of change. Even with modern observability, we still rely heavily on human foresight: logs, metrics, alerts… signals we had to think of ahead of time. And when we didn’t? That’s where blind spots appear. In this talk, I’ll share why we believe agents are the missing layer in production systems. Looking forward to great conversations with the SRE community in London! #SRE #ProductionEngineering #AI #AgenticAI #Observability #DevOps

46

It's that time again! I've got a talk up this year that started out as a discussion in a DigiLocal CIO session about the best ways of talking to young people about testing the code you've written and led to me writing a basic testing framework in Scratch and seeing how feasible TDD was in that environment. The talk is called "Testing from Scratch" and if that sounds in any way interesting I'd really appreciate any votes to get it into the programme, but there are loads of great talks on offer (in particular, I'm curious to see what both Lorraine Pearce and Michael Luke are talking about) so do have a scroll and see all the wonderful things on offer

8

1 Comment

We’ve built salary sacrifice schemes for pensions, bikes, and electric vehicles. Why not housing? As a Software Engineering Manager, I spend my days architecting resilient systems. But outside work, I’m navigating a mortgage landscape that feels anything but resilient, with volatile rates, rising costs, and no structural support for working families. Here’s the gap: Mortgage payments often are our largest monthly expense, which must be made from post-tax income. Yet other long-term assets benefit from salary sacrifice. Why not allow capped pre-tax contributions toward our primary residence mortgage? Imagine being able to salary-sacrifice £500–£1,000/month toward your mortgage: 🔹 Hundreds of pounds/month in tax savings 🔹 Reduced housing stress and improved retention 🔹 Fairer treatment for mid-career professionals balancing family and financial growth It’s time to rethink housing support not just through subsidies, but through structural fairness. If we can salary sacrifice for pensions, bikes, and electric vehicles, why not housing? What’s stopping us?

15

8 Comments

The early 2010's were the golden BDD days, I really enjoyed the projects I worked on back then. An astute article on the rise and fall of BDD tools, and BDD in general. Thought I do wish people would stop talking about things "dying" in tech or being "dead", it's just evolution. " ... we as an industry failed to successfully productize tools for collaboration. The world jumped on BDD because Cucumber-esque frameworks were easy to adopt. The world was less willing to adopt BDD’s collaborative techniques because they were merely processes, not products. Products are sticky; processes are not. Cucumber tests will still be running after we all retire." https://lnkd.in/ezXXbvUE

1

I’m not normally so active on here, but am just really saddened about the SBG/Flutter redundancies. I agree with so much of the sentiment already posted by friends and former colleagues - SBG was THE place to be in Leeds and the wider North region for such a long time. Obviously change is inevitable but it doesn’t make it any less sad and I feel for everyone currently affected. I thought I would follow-up on my earlier post and offer some tips to anyone now looking for work for the first time in potentially a long time - albeit still obviously happy to chat if anyone wants to reach out directly. 1. Don’t panic. You’ll be ok. I would hope Flutter will look after you which will give you some time. 2. For now, and throughout your search, look after yourself. Take time off, stretch your legs. Lean on friends and family if you can, offload! 3. Persevere and stay positive. The right thing for you is definitely out there! 4. Use AI, but use it well. - Ask it to review and critique your CV (albeit redact personal info before pasting into ChatGPT etc). - Ask it to compare your CV to a particular job description. - Ask it to act as the hiring manager for a particular role and perform a mock interview. - DO NOT use its output verbatim. Write everything in your own voice, that’s the human part. AI-generated text is so obvious. And no - this post is not that! 5. A good CV is definitely important, so make sure it’s up-to-date. Don’t just list generic skills, rather what impact you made and what value you can bring. 6. Update your LinkedIn profile and make sure it’s consistent with your CV. 7. Upload your CV to jobsite.co.uk - recruiters definitely do use this in my experience. 8. Know what you’re good at (and what you’re not); it makes recruiter calls easier. 9. Don’t rely on making applications through LinkedIn. Complete waste of time IMO, you’re much better off going direct through company career websites, recruiters, hiring managers if you can. 10. Be proactive. Use your network if you have one. LinkedIn, former colleagues, tech meet-ups, etc. And/or reach out to recruiters directly. Get lots of calls scheduled, sell yourself, be enthusiastic. 11. Be hyper-organised. Use a spreadsheet with something like task, status, date, and notes columns. Add a new row for any recruiter contact or role applied for, and update the notes after any communication and set the date for whenever a follow-up is scheduled, or when you plan to chase. 12. When you land interviews, prepare. Do all the usual stuff - research the company, practice situational interview questions (and STAR method answers), prepare your own questions for the interviewers, etc. Again, AI tools can be quite good at helping with this. Hope any of that is helpful and I’m more than happy to chat as well. DM if you want any CV sanity checking or anything like that.

100

4 Comments

Elite R&D teams have this approach towards software engineering and estimations...it's dreamland and caters for multiple types of stakeholders if you have their buy-in🎖️

5

Spoke at the London Microservices Meetup yesterday - on the topic of keeping things up to date. There always seems to be something that needs to be updated or migrated, particularly if you're a platform team. Getting good at managing these sorts of projects is well worth it. They may not be exciting but they are essential, and if you can get through a migration without everyone hating you, that's a badge of honour! I very much enjoyed Eddie's talk at the same event on Building AI Agents, a great roundup of the options available with lots of practical examples. Thanks to Oliver Short, Mark Short and the SEEKR team for inviting me and hosting the event. If this sounds interesting to you, I quite often give talks at organisations, either as a one-off or as part of a larger consultancy engagement. There's a list of recent talks on my website at https://lnkd.in/eJ9tJrwE

34

2 Comments

A couple of years ago I wrote an article on capacity, and how it is a fundamental part of team speed, alongside context and alignment. I've had thousands* of messages asking for the follow up but had been too busy doing other stuff. I've seen agentic AI exponentially increase capacity. However, not all kinds of speed are equal and speed without context or alignment is not the kind of speed we should be aiming for. It drove me to write the follow up article that everyone has been clamoring for**. AI has certainly changed team speed, though not necessarily for the better (yet). It will only improve when there is a seamless interchange of context between agents and real humans, and humans and machines are aligned to a canonical purpose. Here are my thoughts on how to cultivate speed with meaningful momentum, have a read if you'd like: https://lnkd.in/eBF9T8Mf * Nobody asked ** Nobody clamoured

21

3 Comments

I've been thinking about asynchronous systems through the lens of supply chain logistics, specifically just-in-time delivery. And the metaphor holds up surprisingly well. You have goods that need to move efficiently from point A to point B. You need transportation (trucks, trains, planes). You need standardized packaging so things don't get lost. And you need route planning so everything arrives on time. But in software, we often skip the standardization. Every team invents their own message formats. Documentation is scattered. Integration becomes guesswork. At APIdays London 2024, I mapped this metaphor to three technologies: NATS as the transportation layer, Cloud Events as standardized packaging (literally just 4 required fields), and AsyncAPI as the route planner. The talk includes a demo with an observability platform, I deliberately avoided e-commerce examples 😀. https://lnkd.in/g6Ep6g9B #NATS #CloudEvents #AsyncAPI #EventDrivenArchitecture #DistributedSystems #APIDays

13

2 Comments

A Glass Half Full In my career, I noticed some people complain a lot. In retrospect, it always spreads, weighing on others, as expected. So I began writing down my thoughts. At the end of the day, it comes down to what kind of person you aspire to be. Do you gaze at a glass half full, or do you always see it half empty? I think it is a very important choice. It is a fundamental choice. It affects you more in your life, Much more than in your work. So what does it mean to live glass half full? Like every coin, there are two sides. Do you turn toward the brighter side, smile, take comfort where you can, and find the strength to carry on? Or do you see life through misery? Complaining feels easy, but it never solves a problem. And problems tend to grow larger, when you lack the will to face them. It’s probably also about maturity, About how you deal with life’s problems. Once upon a time, when we were young, we complained. And our parents were the guarantors of our happiness. Being spoon-fed happiness this way, Maybe we never learned how to solve problems ourselves? Think about it. I think it is a very important choice. It is a fundamental choice. It affects your whole life, Much more than you know. ~ https://lnkd.in/gHuHk2jC

33

1 Comment

The wonderful Oliver Whitwam has written a short blog about how we're practicing type-driven development and domain-modelling to create software that is both correct and is communicable via ubiquitous language. We're really making good usage of the Rust newtype and Haskell-esque smart-constructor patterns to leverage types to encode business rules and invariants (until Rust adds refinement types via pattern-types!). If you love #types, #correctness, #domainmodelling, you'll like this blog I'm sure! https://lnkd.in/eqKWXtqS

16

1 Comment

Over the past week, many of us at Envato have been processing the news of recent redundancies. Seeing colleagues and friends impacted so suddenly is difficult. If you were affected, I’m really sorry you’re going through this. Redundancy can be disorienting and heavy, even when we understand the business reasons behind it. If it would help to talk, my inbox is open. I’ve been through redundancy myself more than once before this, and I’m always happy to be a sounding board. It's also hard on the people who remain. Moments like this ripple through an organisation. There’s often a strange mix of relief and survivor's guilt, along with uncertainty about what might come next. When companies go through changes like this, that uncertainty can feel like chaos, and no one does their best work in a chaotic environment. That should be OK to acknowledge. For leaders, the instinct can be to move quickly and push forward - especially with all the pressures this industry is currently facing. In my experience, what people need first is steadiness. Acknowledge what’s happened. Don’t minimise it. Answer questions honestly, even when the answer is simply “I don’t know yet.” Take time to rebuild psychological safety. Looking after people in moments like this is the essence of leadership - and Envato are fortunate to have some very people-focused leaders who I know get this. Leading with compassion is the best way to rebuild trust and stability in difficult times.

117

4 Comments

🚀 Go 1.25 is here! Just dove into the release notes and I'm genuinely excited about what the team has delivered this time around. The standout for me? - The new testing/synctest package runs a test function in an isolated “bubble”. Within the bubble, time is virtualized: time package functions operate on a fake clock and the clock moves forward instantaneously if all goroutines in the bubble are blocked. Finally, testing concurrent code without the usual timing headaches! This "isolated bubble" approach is brilliant - your tests run in their own time dimension. No more flaky tests due to race conditions. Testing time-dependent logic (like timeouts or scheduled tasks) is deterministic now. - Performance improvements are solid too. The compiler can now allocate the backing store for slices on the stack in more situations, which improves performance. Plus, GOMAXPROCS defaults to the number of logical CPUs available at startup with smarter cgroup awareness for containerized environments. Your Kubernetes deployments will thank you. The container improvements alone make this worth the upgrade. No more CPU throttling because Go finally respects your resource limits properly. Full release notes: https://go.dev/doc/go1.25 #go #golang #programming #development #backend #performance #testing

15

I really enjoy end of year appraisals. Having that opportunity to sit down with software engineers of all levels and discuss the highlights and the challenges from the previous year is a huge privilege, but also a huge responsibility. These conversations are designed to advise engineers on future behaviours and possible opportunities for growth, not just in the job they are doing but in their career as a whole. This year however I felt I had to also deliver a warning, software engineering is changing - for better or for worse - and you need to make yourself aware of it. It can be easy in a large enterprise organisation to fail to notice the rapid pace of change in the wider industry, but that doesn’t mean it isn’t happening. Boris Cherny, creator and head of Claude Code at Anthropic recently stated “Coding is largely solved” in an interview, and there are an increasing number of industry experts out there saying similar things every month. This makes career discussions very interesting indeed. No-one can be certain or predict what our roles will look like in 1-2 years, all we really know is that it’ll be different to what we do today. My advice is really simple, stay aware and embrace the tools and technology as they appear. Invest in your career, take the time to keep on top of the latest models and applications both in work (if you can), but in your own time too. Learn to use them and understand how to get the most benefit from them. Secondly, remember that as an engineer you’re in a strong position to pick up and hone the most important fundamental skills in software development: Product knowledge - you may already be a “product engineer” or work closely with the product teams designing the software for your users. This means you’re involved in both implementation and the refinement of the customer experience. Build on this knowledge, know your customers and how best to serve their needs. Know how to measure, test and adapt. Architecture and Security - until AI-coding is advanced enough, this is a real focal point and realistic worry for many. Does it scale? Can it be hacked? Is my data secure? Only technical experts know the answer to these questions, stay technical. Monitoring, observation and testing - if you didn’t write the code, how can you be sure it works in the way it’s intended? Both before and after releasing it to production. Know the tools and techniques to best evaluate what your software is doing at any given moment in time. Creativity - as a software engineer 99% of your role is to use your knowledge and skills to creatively solve problems. In a world of automation and lighting-fast prototyping and iteration, being creative is now more essential than ever. Once a year probably isn’t frequent enough to have these types of conversations. Given the rate of acceleration in the tech industry this advice may be outdated in 6 months. But I’ll continue to try to learn, adapt and focus on the fundamentals.

39

2 Comments

The amount of utter nonsense I see posted here which masquerades as 'advice' for young developers blows my mind. Yes linked in is the worst site on the internet which we all feel strangely compelled to exist on anyway, but even so... My advice to young developers is: a. Try to find something you genuinely enjoy b. Work on getting better at it c. Ignore linked in posts That's it.

183

8 Comments

Accessibility is good design. It’s also good business. In 2025, if you’re not building inclusively, you’re falling behind. #GeniusFinder #Accessibility #Inclusion #AssistiveTechnology

10

2 Comments

Setting up a Kafka stream end-to-end can be a tedious task with setting up cert or SASL, schema registry, configuring producer and consumer and so on. We made this journey a guide, coherent experience which gets you to actually streaming way faster.

7