When I started thinking about this, I fell for the trap of semantic drift and was under the incorrect impression that "conscientiousness" was the right word for this. It turned out, though, that the dictionary definition of that is actually "wishing to do one's work or duty well and thoroughly". I don't think that's a coincidence – when you're working with other people, as most of us do, enabling your team is an important part of your job.
So what does this considerateness look like in practice? Here are some examples:
In doing these sorts of things, you exchange some of your own time, effort and scope for direct short-term impact for the sake of a smoother-running team. There's definitely a balance to be struck here – you should not be tanking progress on your own work given that that's what you're being relied upon to do. However, as part of the process of doing your own work, there are many small choices and efforts you can make every day to prevent that from causing unnecessary isssues for your colleagues while they try to do the same.
Giving yourself some slack time to deal with unplanned work instead of constantly keeping your work queue at 100% capacity is also an important strategy to learn to maintain your performance for the long term, and that's when you can practice some of these behaviours that are less directly-related to your own tasks. Combined, these efforts help to train your muscles in a plethora of areas: communication, debugging, prioritization, business thinking and self-reliance.
While practicing considerateness in your work does make you a better engineer to work with, I cannot promise you that this will definitely translate into immediate tangible benefits for your career progression, if that is something you care about. While companies often espouse prioritising the needs of the organisation and the team over your own personal to-do list as a cultural value, I've rarely seen it rewarded organisationally.
Hiring and promotion rubrics might nominally include this behaviour but greater weight is often given to experience single-handedly architecting some sort of important service at an impressive scale. After all, quantitative measures are a lot easier to grade than qualitative. Sadly, as a result, the lack of incentives can lead a lot of people not to bother making the effort who would have done if they were in a team with a different culture.
If the incentives aren't there, it can be really hard to show up and be deliberately considerate day-in, day-out. Honestly, sometimes it's hard even if they are; which one of us hasn't had an off-day? But showing a tendency to stick with it regardless of your immediate circumstances will round out your own skills and garner the respect of many of your peers throughout your career. It will enable you to build a great reputation and stronger relationships with other people detail-oriented enough to notice the difference in working with you, and help to cultivate the same perspective in other engineers who are looking to improve.
So, next time you're tempted to chuck a pull request over the wall, or are about to pick up a new task while your review pile languishes, take a minute and ask yourself: am I being the sort of engineer I'd love to work with?
]]>In 2024, FAANG-style interviews continue to dominate discourse, which might give the impression that most interview processes are carbon copies of each other. However, it's been heartening to see more diverse technical interview formats emerge in recent years, even among widely renowned companies. Personally, I've found formats are usually the greatest determinant of how enjoyable an interview process is, so here’s an opinionated overview of the ones I’ve been through as a frontend-leaning full stack engineer.
If you're an experienced interviewer who’s seen it all, you might want to jump to my closing thoughts, otherwise: buckle in!
Technical interview formats largely split into three groups:
The bread and butter of the software engineering interview process. As many software engineers progress to senior levels, they spend less time overall writing code, and this is often reflected in interview processes at that level. However, even then, some form of hands-on coding continues to feature at least once or twice.
These questions largely focus on data structures, line-level optimisation and the like. They might be plainly presented with no particular context that would tie the problem to a real-life scenario with the interviewer asking you to transcribe on a whiteboard, or you might be asked to write a script that can recursively traverse directories and list or gather stats about them for example.
It's easy to bemoan the irrelevance of these, especially when they aren't disguised at least in part to look like something you might come across at work, but there is a reason why they are so enduring.
Giuseppe Gurgone shared his take on these types of interviews on his blog:
“Their aim isn't to throw unusual and complex algorithms at candidates just for the sake of it; instead, it's to evaluate problem-solving skills using a focused and sufficiently generic problem.”
Similarly, both while undergoing interviewer training and as a candidate myself, I have often heard interviewers stress the focus is not on whether the candidate finds the answer or how long they take to do it, it’s on their approach. In my experience, this often gets lost because these interviews are easy to deliver and assess on some level, it’s not actually that easy to do these things well. The "objective" success or failure to solve the problem in time is very distracting, especially when these interviews run at scale and they’re being delivered by people with numerous other competing priorities, so this is a trap to be wary of.
There's a huge amount of variety in this category but what all these interviews share is that they involve writing code and building something beyond an isolated class or function. These interviews also tend to be open book, meaning you have access to the internet, API references and Stack Overflow. This access might even extend to ChatGPT or Claude depending on the company.
There's a number of different dimensions these can cut across:
Often both kinds will feature in a single interview process, with the take home happening prior to the live (or "in-person") interview.
In my experience, the amount of time provided as an estimate for a take-home task is almost always underestimated by the hiring team, sometimes wildly. In reality, the upper bound of time available for these is a function of how busy the candidate is outside of work, which puts some demographics at a significant disadvantage. While live interviews can give a lot of people performance anxiety, they can be preferable for people who are pressed for time or more senior candidates who simply aren’t particularly enthused by the idea of building yet another CRUD app.
There are tradeoffs and it's hard to come up with a single interview that is going to work for every candidate's strengths and circumstances. The combination of a take home task followed by an in-person follow-up is something I’m seeing more and more frequently, and it avoids a lot of pitfalls. That said, as an interviewing team, it’s important to ensure that the time set for the take home task is both reasonable (read: not 8-10 unpaid hours) and realistic by validating it in-house before giving it to candidates.
On one end of the spectrum, shorter 30-60 minute interviews have focussed on adding a feature or two to an existing codebase, often that produced in the take-home task. On the other hand, I've spent a whole day onsite with a company, building out a web application. A number of companies, like Linear, also conduct work trials, where a candidate works with the company for several days. There are tradeoffs with most durations: on the shorter end, a candidate doesn’t have much time to gain momentum, and with the days-long interview processes, these are pretty much logistically impossible for a lot of people.
Take-home tasks in particular often give you a bit of leeway in terms of your tech stack. On the other hand, in-person, or supervised interviews will often provide a starter project you are expected to work with.
One potential gotcha is that working in a codebase that features technologies you’re familiar with is very different to picking up a new set of technologies for the first time, especially if there is not a sufficient corpus of existing code to work with as there would be in a real production codebase. This is easier to deal with in a take-home project due to there being less pressure to get everything working within a certain amount of time, but doing this live on top of being watched by strangers can be incredibly stressful.
Interviewers might genuinely believe that when it comes down to it they will not penalise candidates who are not familiar with the tools at hand if they struggle to be as productive while gaining familiarity, but again, it's an easy trap to fall into and it’s frustrating to be on the receiving end of that. One way to level the playing field here, then, is to bootstrap starter projects with standard technology choices. While when they get into the role, engineers will have access to more specialised (or opinionated) tooling and libraries carefully selected to enhance productivity, having a good grasp of the underpinnings is still important and it reduces the chance that one candidate is going to be significantly hampered by a lack of experience with your tech choices compared to another.
When it comes to live interviews, there is a spectrum here. The most socially acceptable minimum when it comes to communication is for the interviewer to be responsive to questions and perhaps give you a well-timed hint if you are struggling or heading down the wrong path. (Sadly, that minimum is often not met: interviewers loudly having unrelated conversations or yawning doesn’t exactly make for a stellar candidate experience.)
On the other end, you could be repeatedly swapping pair programming roles (driver and passenger) with the interviewer, so your engineering is mostly done through discussion. While pair programming draws a range of opinions as a mandated practice, in an interview context, being able to get input from another person, especially in an unfamiliar codebase or tech stack will be more reflective of the reality of a lot of engineering teams and less pressurised.
In a more extreme version of a pair programming interview (this particular one being algorithmic), I was presented with a task and the role of driver rotated between me and two interviewers every five minutes. While I question the amount of valuable signal the interviewers could get out of this compared to me simply coding the solution myself, it was actually more fun than it sounds. I ended up pair-programming maybe twice in two years in that job.
While there is an infamous format that probably comes to mind, as an industry we are now running several very different types of interviews and calling them all "systems design", at least for frontend/fullstack engineers. This can sometimes make it difficult to know what to expect.
This is the archetypal FAANG-style interview: the one that you probably think of when you hear "system design interview". You, as a lone engineer with no access to the internet or other resources, will be tasked with designing Facebook/Youtube/TikTok or the like.
While I do think having a decent foundation of systems design knowledge is a great bonus for engineers working on product, it's not the absolute necessity it's made out to be in many interview processes. Designing Data Intensive Applications becomes a much more interesting read once you have at least a passing familiarity with the sorts of systems it talks about, and you are not necessarily guaranteed to be exposed to them given some number of years working on software.
These interviews are similar in nature to backend interviews, in terms of taking a higher-level look at building a system. Instead of focussing on handling traffic at scale, they focus on holistic knowledge of the frontend, covering topics such as:
An example would be to design a dashboard page that can display any number (potentially hundreds) of charts, that is configured by the user.
These interviews are gaining traction but are still quite rare relative to backend system design interviews. If you do happen to have one coming up, I would suggest taking a look at Medhat Dawoud’s guide.
This can take different forms: component modelling on the frontend, API design or database design. It's basically a smaller slice of a frontend or backend system interview thrown into sharper focus. These sorts of interviews tend to be strongly related to skills you'll often exercise as part of technical design processes when leading projects.
Andy Ingram has written an in-depth post on conducting an interview like this focussing on designing a GraphQL API over on his blog.
Despite the unduly non-descript label, I think these kinds of interviews are underrated and underutilised. Professional software engineering is usually a team sport and you're often tasked with extending and maintaining existing code in collaboration with other people and interview formats that focus less on individual code authoring explore those skills more effectively.
In one interview of this type, I was given snippets of code in various languages I wasn't necessarily familiar with and asked to explain what I thought they did and why. This format gives a sense of how somebody reacts to unfamiliar code and languages while eliminating the added pressure of having to work through the technical difficulties that often come along with getting started with a new technology on a given machine for the first time.
In this interview variant, you will be given a decently-sized chunk of code, perhaps about 250 lines or so, and will have a limited amount of time to provide feedback. These interviews test your ability not only to read and understand code, but also your communication skills, attention to detail and perhaps, your level of pedantry. In many teams, especially in larger companies, you will be doing a lot of code reviews and even if you work with a world class team, there’s still a lot of strategic advantages to doing it well. Sarah Vessels recently wrote in detail about this on the GitHub engineering blog.
My first graduate interview (which was for developer relations, rather than engineering) involved giving a presentation on a technical topic of my choosing: ThreeJS. Independently of that, I promptly realised developer relations is not for me and that was the last presentation I gave as part of an interview. However, I recently sat in as an interviewer on one of these being conducted with a staff-level candidate for frontend infrastructure engineering.
These interviews are fairly uncommon for software engineers, but they can definitely be useful for those operating above senior-level for certain roles. A big part of engineering at higher levels at many companies can involve influencing, advising and strategising, even as an individual contributor, so testing for this skill makes sense.
These types of interviews vary based on a candidate’s experience level but tend to dive into familiarity with concepts in the specific language(s) and tech stack used on the job.For more junior candidates, this be a “what is a closure in JavaScript?”, or a more general exploration of your approach to higher-order concepts like testing implementation and state management.
For earlier career engineers I think these questions work better embedded as part of a practical exercise where code is being written or read. Many people implicitly internalise concepts and features without learning their names or committing them to memory. However, if you’re hiring for an engineering enablement team or looking for someone to lay robust foundations in a particular area of your stack, getting a sense of their expertise and how they stay up to date with recent developments in the area can be valuable.
The interview processes in which I have performed the strongest and enjoyed the most tend to be the ones where I felt the skills they showcase match the sort of work I am used to doing, and more specifically, with constraints relatively similar to the norm. I was convinced that those sorts of interviews betrayed a lower technical bar, precisely because they felt so natural. The fallacy finally came into sharp focus when talking to an external recruiter about a process I underwent this year that was way more engaging than struggle-inducing: I was only the third person to have made it through to the offer stage (the company had multiple positions open) and it turned out every single interviewer was highly experienced and pedigreed.
On the other hand, the most frustrating interview processes I have been through have consistently been the ones that seemed completely detached from reality. If you are hiring someone to be your startup’s second frontend engineer and you are planning to task them with single-handedly scaling your backend to a billion users when you already have twenty backend engineers, you might want to reconsider.
Interviews are never going to be perfect, but we can do so much better! An integral part of that is designing processes on the basis of identifying skills that are useful and important in the context of the role, team and company. But for now, interviews are what they are, so I won’t completely discount the idea that I’ll be back to memorising how to implement a highly fault-tolerant globally-distributed rate-limiting service from scratch some time in the future just yet.
Shoutout to Giuseppe Gurgone and Alberto Morabito for reviewing the draft. I started it after a conversation on this topic with Alberto, who wrote his own too! You can read it here.
If you're used to this way of working, it requires conscious practice and effort to break out of. The alternative is to ship incrementally. Fortunately, building the ability to do this is like training your core muscles – it takes work, but once you do, day-to-day tasks mysteriously get easier and a lot of those nagging pains that sometimes come with age disappear.
Shipping a single small-scale feature is straightforward: those can often fit in a single commit or pull request, depending on the size. But what about when you take on larger challenges that take weeks, months or even years? That all starts with a plan.
Setting a project up for being delivered incrementally often occurs before a single line of code intended for production gets written, by analysing your project's goals and splitting them up into independently deliverable milestones. Making thoughtful decisions before your technical design is set in stone can transform a project that might otherwise have ended with three engineers merging a 100,000 line pull request on a Saturday into one that can be enabled with the simple flick of a switch given the right approach.
Note that this doesn't mean you can't write any code for prototyping or discovery; on the contrary, building something quick and scrappy to validate your assumptions and throw light onto your unknown unknowns can be a powerful tool, as long as you don't commit yourself, or get committed to shipping your first pass. You can read more about one way to go about this in this post on zero drafts by Justin Duke.
So what should a milestone look like? There is no One True Way to split up a project, how you do it will depend heavily on what you're trying to achieve. Milestones for net-new feature work will likely look very different to those for replacing or extending a product-wide primitive and even more so that those that involve a migration to change data models fundamental to your application. Over time as you work on more projects and gain more experience, you'll find patterns and reusable strategies start to emerge, such as:
If you are building a user-facing project, a fairly obvious strategy is to slice your project vertically and delivering an end-to-end feature that can be used standalone, so you can start getting feedback from some users as soon as possible. This is especially useful if you're using a tech stack or tools you may be unfamiliar with.
If you are introducing a change to multiple product surfaces, like different websites or an application and a companion CLI, for example, focussing on building for one at a time might be more appropriate, but be careful not to get tunnel vision. Go into the details while considering the technical design to make sure you're not over-optimising it for one platform versus another.
If you are migrating to a new data model or making database schema changes, splitting that process up into several steps that allow the old and new shapes of the data to co-exist while the project is underway can remove the need for a hard cut-over while supporting changes further up the stack that rely on them.
Here are some suggestions for what a useful milestone might look like in your team:
A lot of companies have processes around writing design documentation and tech specs. If yours doesn't, consider writing out your milestones and sharing them with your team for feedback.
While planning milestones, it's also important to consider the different tools and techniques at your disposal that you can use during the execution phase, as this will unlock new ways of working.
Getting code into production as early as possible is one of the most reliable ways to de-risk deployment. Feature flags are a popular tool since they allow you to do this without disrupting your users before your changes are ready for prime-time. Some feature flagging solutions will allow you to target different environments, so your teammates can try things out on staging. You may even be able to target individual users, meaning you can ship to alpha testers from your user base and get feedback as you build and ship.
Decoupling deployment from release with feature flags also means you can ship smaller units of code at a time which makes for easier and more effective code reviews (that will probably be completed quicker too), as well as making it easier to rollback and debug changes that aren't behaving as expected once rolled out.
While feature flagging works well for frontend-heavy projects and new features, sometimes it won't be enough. What if you need to continue to support an existing feature or service while making major changes to critical pieces of code or dependencies that affect a large area of your application?
One potential solution is to use a facade. It can provide indirect access to your existing system and you can also use it to point to your new code using a feature flag. This is a pattern often found in the world of OOP (object-oriented programming) and might sound dated, but the concept is generalisable. Perhaps in your case a facade could be as simple as a file or function that routes the flow of code or data to the old or new solution, depending on a feature flag or other logic.
When it comes to significantly reshaping your data models, there's a fair chance that you're going to want to make some changes to your database at some stage. Here's a handy tip that Jack Ellis got from Carl Sverre that can be used to support incremental development in these cases:
Well, TIL.
— Jack Ellis (@JackEllis) May 31, 2024
Me: "Everyone tells me to use feature flags in production but you can't exactly use them when you need to restructure a 30+ billion row table to make the feature work"
Carl: "Use database views for now and deal with the migration once the feature is ready to launch"
If you're not familiar with database views, they are queries that act like virtual tables. You write an initial query to create the view based on your static, existing tables, and then your database stores that query and you can query the resulting view as if it's a real table. You can use this to provide indirection that acts like, yes, a facade! They also have other uses - you can more easily test out a potential change you'd like to make to your existing tables for a new feature without making a big commitment of migrating the tables the rest of your application.
On paper (or Google doc), you will likely find that the overall estimate for final project delivery gets longer when taking the approach I've outlined here, as opposed to the one you might have given without taking this approach. While this headline of needing more time will be a hard sell in some organisations, especially ones that aren't engineering-driven, the reality is that you may end up completing the project faster. That may seem counter-intuitive given the overheads: the additional planning and extra engineering effort required to support this working. In practice, though, continually integrating the code into production increases momentum and getting feedback earlier pulls forward a lot of the fixes that otherwise would've been left until the end of the project or after it shipped, as well as avoiding a need for any project-level reverts.
Additionally, given the average level of ~in~accuracy when it comes to engineering estimates is an industry wide meme, placing so much weight on the absolutes doesn't really make sense. That doesn't mean we should abandon hope of ever doing a passable job of estimating software projects! In fact, splitting up the work actually makes giving an accurate initial estimate easier, and it is also easier to recalibrate if need be as the project progresses as Jacob Kaplan-Moss notes in this post from his series on software estimation.
So, splitting work into shorter-term discretely shippable units brings:
If by now I haven't managed to convince you, maybe Lisa Karlin Curtis can. While writing this post, I discovered a treatise she penned on the incident.io engineering blog with a more startup and product-focussed lens. If it can work for early-stage teams and public companies, it can probably work for you too.
]]>