The first six to twelve months and the first five to ten people will make or break your new project. With so little time and so few people, every one of them counts.

Let's meet your garage team—the three engineering types that hold the potential to create something extraordinary.

NOTE: this post is directed at early stage projects and founders. If you are an engineer, however, you might find interesting learning about these types of successful startup engineers and whether you fit (or could fit) into any one of them. Read on!

The Garage

The garage - a symbol of Silicon Valley and the birthplace of groundbreaking companies like Apple.

Startups can sprout from garages, cramped apartments, small offices above Chinese restaurants, or any other unlikely space. These places may not be glamorous, but they offer affordability and a sense of resourcefulness that defines the startup spirit.

When you consider the limited resources, lack of established company reputation, and constrained physical space, it becomes clear that your team for these new projects won't necessarily consist of your typical FAANG employee.

But fear not! By doing it right, you can assemble an extraordinary garage band of misfits, rebels, and troublemakers—people who perceive the world through a different lens.

🤖 The Coding Machine

Every garage team needs at least one coding machine. These are early to mid career, no-nonsense engineers who get things done - fast. These green-loving heroes rejoice seeing green tests passing, green code reviews, and green deployments.

They're happiest when they're knee-deep in their code editors, ready to rock and roll. They don’t like endless theoretical discussions, careful planning, or anything keeping them from getting things done. PMs love them.

However, their always-be-shipping attitude can sometimes lead to an escalating technical debt, an unstable user experience, and a codebase that's hard to build upon.

Supporting them: keep the momentum rolling

Create an environment that lets them shine. Ditch those never-ending "synch" meetings, marathon standups, and red tape. Make sure they always have a good product backlog to pull from or at least a clear sense of direction.

Pro tip: Pair them up with a seasoned colleague. Without effective leadership, they may prioritize immediate tasks over critical, long term problem-solving. That's when you end up with tech debt that could kill your team’s momentum.

It's important to acknowledge that these individuals are often the unsung heroes within companies. While they may not seek the spotlight like their flashier and more ambitious counterparts, they are the reliable workhorses who consistently deliver results.

Make no mistake though - having a solid core of these individuals will ensure that you always have plenty of oomph available on tap, should you know how to use it. So find them, support them, and give them the credit they’re due. They won’t always ask for it.

❤️‍🔥 The High Potential

These are your limit breakers. They defy expectations. These individuals are bright, hardworking, and endlessly curious. They possess an incredible ability to learn and excel in almost anything they set their minds to.

Mostly younger, high potentials pack a punch beyond their years. They often outperform others in remarkable ways, fueled by their sheer effort and brilliance.

They are incredibly flexible. They will learn how to build platforms, design high throughput APIs, basic data engineering, handle payments, and so on. The team needs it, they got it covered.

High potentials love to learn. They are at their happiest when they are getting things done and learning. Too much red tape or repetitive tasks and you risk disengaging them.

Their lack of experience can lead to an escalating tech debt, even worse than coding machines. Don’t be surprised if high potentials randomly come up with a solution to a major, possibly unknown, problem that they developed over the weekend, with no input or prompting from anyone. While these solutions often work, their technical quality can be hit-or-miss.

PMs love them too.

Supporting them: push and pull

Supporting high potentials is a constant game of push and pull.

Push them hard with big challenges where they can learn new things and grow. Given them context and make sure that they know what the next big challenge is. Give them the tools they need, remove blockers, and they will impress you.

Pull them back when they are over-doing it (ex: too many all nighters). High potentials need a limiter. Otherwise, they will burn bright and fast. Next thing you know, they resigned and went on an Appalachian trail hike to “find themselves”, “connect with nature”, and “recharge”. It’s that sudden.

Create a lean environment that they can thrive in and pair them with a seasoned colleague who they can learn from.

Unlike coding machines, who find joy in shipping multiple REST APIs and gradually improving, high potentials can easily grow bored and disengage.

Supporting high potentials can be demanding as they constantly push boundaries and expect a lot from their leaders. Stay one step ahead and be ready to meet their demands. If you can manage that, their accomplishments will leave you truly impressed.

😎 The Tech Lead

Imagine this scene: your team is gathered around a whiteboard, grappling with a challenging problem for hours. They're stumped. Your high potentials have scoured Stack Overflow and devised an, um, interesting solution. Your coding machines have mostly stopped listening, fired up their laptops, and are ready to commit some half-baked code.

And then, in walks the Tech Lead. They take a glance at the whiteboard and exclaim, "Oh, that's a cool problem, I’ve seen it before!”, and proceed to thoroughly solve it while getting the buy-in of most folks in the room. In 20 minutes.

The Tech Lead has a unique combination of experience, soft and hard skills, coaching ability, and unwavering resilience under pressure.

They are seasoned engineers who have tackled a wide array of problems—queues, CDNs, stream processing, platforms, you name it.

The key term is “real world experience”, not theoretical knowledge. There’s a big difference.

These "been there, done that" individuals can save teams weeks, if not months, of costly trial and error and technical debt by swiftly proposing well-designed, functional solutions.

A good Tech Lead knows how to navigate the strengths of both coding machines and high potentials. They strike a balance, guiding their growth while leveraging their expertise.

Now, a word of caution: don't assume that any successful senior engineer from a renowned company automatically fits the Tech Lead description. These exceptional individuals possess a unique blend of technical skills, soft skills, ability to thrive under pressure and ambiguity, and a healthy dose of pragmatism. The link below explains the type well.

Musings Of A Caring Techie

So you want to be a Tech Lead

Be we jump into the article, I wanted to let you know I had the honor to be a guest on the “The Elevate - Women in Tech” podcast hosted by the lovely Kellie Kwarteng. We delve into my tech career progression, from my school years all the way to moving to California to work in Silicon Valley. 💪…

Read more

3 years ago · 21 likes · 4 comments · Irina Stanescu

Supporting them: create a partnership

Alignment on the macro and accountability on the micro—these are the foundations of supporting a Tech Lead.

Create a "highly aligned, loosely coupled" environment. Tech Leads thrive when they have sufficient context and guidance to understand what success looks like, coupled with the freedom to execute.

So partner with them: establish responsibility and accountability, and let them solve the toughest problems for you.

They should be able to lead small groups of engineers, including coding machines and high potentials, to conquer challenging projects while fostering growth.

Tech Leads excel at crafting solutions that work well and take near future into consideration. However, be sure to challenge them if you spot signs of over-engineering. Their wealth of knowledge can sometimes blind them to simple, effective solutions that are good enough in the right context.

What’s Next

Whether you find yourself in a humble garage or an unconventional workspace, remember that greatness can arise from the most unexpected places.

The coding machines, with their unwavering focus and rapid delivery, lay the foundation for productivity.

The high potentials, with their boundless curiosity and ability to learn anything, push boundaries and drive innovation.

The Tech Lead, with their wealth of real-world experience, problem-solving prowess, and effective soft skills, guides the team to well-crafted, efficient solutions, and happy users.

Supporting these extraordinary individuals requires work. Create an environment that allows the coding machines to shine, free from unnecessary bureaucracy and with clear direction. Nurture the high potentials, providing them with challenging opportunities to grow. Forge a partnership with the Tech Lead, aligning on the big picture while entrusting them with solving the toughest problems.

Finding such great people can be a challenge. I wrote about tech hiring in the past, so that should help you get started.

Now go out there and build something great!

It’s remarkable how so many things are made better with great search. Google made it easy for normal folks to find whatever they needed online, no matter how obscure. IDEA’s fuzzy matching and symbol search helped programmers forget the directory structure of their code bases. AirTag added advanced spatial location to my cat. A well-crafted discovery feature can help add that “wow” factor that iconic, habit forming products have.

In this post I’ll cover how a fast-moving team can leverage Large Language Models (LLMs), Vector Databases, Machine Learning, and other goodies to create a wow-inspiring search and discovery experience with startup money and (lack of) time.

Subscribe now

Semantic Search

Semantic Search is a search method for surfacing highly relevant results based on the meaning of the query, context, and content. It goes beyond simple keyword indexing or filtering. It allows users to find things more naturally and with better support nuance than highly sophisticated but rigid traditional relevancy methods. In practice, it feels like the difference between asking a real person or talking to a machine.

Tech companies from all over the world are racing to add these capabilities to their existing products. Instacart published an extensive article on how they added semantic deduplication to their search experience. Examples of companies implementing some form of semantic search include eBay, Shopee, Ikea, Walmart, and many others.

The reason for this rush towards semantic search is simple: more relevant results = happier customers = more money. Discovery, relevancy, and trustworthiness are some of the hardest problems to solve in e-commerce, and an entire ecosystem exists to help companies solve them.

Many companies working on semantic search today solve this problem using document embeddings - a way of representing meaning as vectors. Since semantic search alone may not be able to provide enough relevant hits, traditional full text indexing is used as a backup method. A feedback loop is added to track user interactions and use them to provide super relevant results through result re-ranking.

This method has three key processes: indexing, querying, and tracking.

Indexing is done by converting a document’s content to an embeddings vector through a text-to-vector encoder (ex: OpenAI’s Embeddings API) and inserting it into a Vector Database (ex; Qdrant, Milvus, Pinecone, etc.). Documents are also indexed in a traditional full text search engine (ex: Elasticsearch).

Querying relies on encoding incoming queries into vectors (preferably using the same encoder as the previous step) and querying the vector database using them. These results are then combined with traditional full text results and re-ranked for relevancy. This combination is usually referred to as “hybrid search”. Search re-ranking is usually a complex problem, and often relies on a mix of machine learning and heuristics.

Tracking involves capturing important user interactions - ex: clicking on results, liking items, etc. - and using these events to update the machine learning models involved in re-ranking. This provides a feedback loop that uses user input to continuously improve relevancy.

MVP

Most companies should not copy the architectures of large tech behemoths, startups least of all. The realities are just too different. That’s not to say that we can’t borrow a few tricks from them to implement a reasonably good solution with non-infinite budget and time.

The approach I’m going to explore here is based on mixing semantic search and full text results, re-ranking them for increased relevancy, and tracking user feedback to improve search quality. This is a combination of hybrid search (full text + semantic) and learn-to-rank (closed loop re-ranking).

Vector similarity search will be addressed by Qdrant. Qdrant is as fast vector database with a wonderful developer experience. Getting started with it was a breeze, the company recently raised a healthy investment round, and the team is actively responding to community feedback and improving the product. A great system to start your vector journey with, especially considering some of the alternatives.

I am also using OpenAI’s Embeddings API to encode text into embeddings. OpenAI’s text-embedding-ada-002 model is quite good, but there are other players in the market today. You can also checkout Cohere or even self-hosted models, like all-MiniLM-L6-v2. I recommend starting with cloud-hosted ones for simplicity though.

Our full text search part will be done by ElasticSearch (ES). ES is a mature, batteries-included search system with many capabilities. Interestingly, Elastic seems to be deeply interested in vector search. Definitely something to keep an eye on.

Re-ranking will be handled by Metarank. Search re-ranking is a hard problem, and I’m surprised that there is a relatively easy to use open source solution available. The re-ranking part is somewhat complex (especially when you get to fine-tuning), so I would recommend that you first get the basic indexing and search working and add re-ranking on top.

NOTE: the reason why we usually need to combine semantic search and full text results is that semantic search may not return enough hits. Your specific results may vary, so feel free to experiment!

Indexing

The first step is to index items for search. Items could be anything - products, locations, sellers, images, etc. Items are stored in the main database (MongoDB in this example), which serves as the source of truth.

To index items we will push changes (inserts, updates, and deletions) into a Kafka topic, which will then be consumed by multiple processors. Redis queues would work too. This is a pull-type architecture and it is quite robust in production. You could call each system directly from the Items API, but this can easily lead to partially indexed items.

Three processors consume this topic:

• Full Text Indexer: updates the full text index (ElasticSearch in our example).

• Semantic Indexer: assembles text strings from item changes (ex: product titles + description), encodes them into vector embeddings, and saves them to the vector database (Qdrant).

• Item Ranking Updater: updates Metarank’s item metadata.

Note that none of these systems will generally contain the full item data, which is usually unnecessary (and costly).

Querying

This is where things get interesting.

Our Search API works in four major processes:

• Search: the first step consists in sending the query to our two providers - Full Text (ElasticSearch) and Semantic (Qdrant).

  • Notice that the semantic search provider needs to first convert the query into vector embeddings much like the semantic indexer.

  • This is a good step to perform some pre-filtering, like simple criteria (ex: category IDs), geographical radius, etc.

• Re-ranking: once the search service collects all hits it routes the full set to the Result Re-ranker, which re-orders them for relevancy using Metarank.

  • Metarank does not work without some initial data. You can solve this cold start problem by having a simple ranker as a fallback. I had good results with just adding the top 3 semantic hits at the top and the full text ones after. This generally doesn’t look half bad, and it’s just for a little while as real users start using the system. For a more sophisticated approach, check out this amazing article by Metarank’s own co-founder.

• Result Generation: search hits do not generally contain all item information. In order to return a complete human-readable result set we will “hydrate” our ranked hit list into a ranked item list.

  • This is a good place to cache the result list with a relatively short TTL. This helps a lot with things like pagination and sorting.

  • You may also want to store search session metadata here. This is usually not the same as a user session. This allows you to group search and result queries later for analysis and ML, and is a parameter that we can pass to Metarank to improve ranking relevancy.

• Result Tracking: once we have a fully hydrated and paginated set of results we will update Metarank with the exact list of items we are showing users.

  • This could also be accomplished from the frontend if we want to keep this API simple and fast.

NOTE: I mapped the different components for the sake of clarity. If you are operating in a small team or startup I would not recommend going around creating tons of micro services!

Tracking

We need to track how users interact with our results so that we can create a learn-to-rank feedback loop. Examples of tracked interactions include viewing results, clicking them, liking them, etc. The least interaction you should track are result clicks.

This is accomplished by sending these events to a lightweight tracking API, which quickly pushes them to a Kafka topic (a Redis queue or similar would work as well). Since not all data is available in the front end, we may want to first enrich them with internal metadata. Finally, this enriched result is shipped to Metarank (directly reading from Kafka or through its HTTP API) and to a data lake for future analysis.

I am also keeping this at a high level since building such data pipelines by hand nowadays is usually not recommended, especially to small teams. There are plenty of great tools available (ex: Segment, Rudderstack, Fivetran, dbt, Snowplow, etc.) that can help you build a strong data pipeline or plug Metarank into an existing one. For example, here is a chart showing Metarank’s native integration with Snowplow:

NOTE: This is an optional step, and adds quite a bit of complexity to the system. I suggest you implement this only if you are committed to implementing a full blown learn-to-rank system.

What’s Next

Creating great search experiences has never been easier. Semantic hybrid search is a solid first step into providing search results beyond LIKE. Customers are slowly but surely becoming used to this increased level of relevancy, which raises the bar for everyone.

Luckily for small teams, the tooling ecosystem is developing fast.

Many search tools are striving for convergence. Elasticsearch has a working (but slow) vector search function. Qdrant added lots of filtering capabilities (like match and geo-radius). Metarank ships with a semantic similarity recommendation model. There may soon come a time where we have a simple, batteries-included system that can do a good job across the board from the get go.

You can also forgo much of this work and use Algolia NeuralSearch if you have a small number of items, a moderate traffic app (ex: B2B SaaS dashboard), just want to ship a POC fast and see how users respond, or infinite money. It’s a powerful, fully hosted solution from a company that knows search deeply.

There are many ways to get started, and few excuses to keep giving your users a meh search experience!

Getting that awesome software engineering gig you really want can be hard. Competition is tough, interviewing is exhausting, and you may feel that you don’t have a lot to show if you are at the beginning of your career. Missing good opportunities despite all the hard work you put into your craft is a horrible feeling. And this is not limited to first-timers - most folks are not “interview savvy” until they get burned multiple times.

I see many talented, hard working folks struggling to break into tech or to find a role they are happy with. It doesn’t have to be this way. You can do it. Got it? Good. Let’s get to work.

Note to Managers: while this post is geared towards individual contributors (ICs), I think that you can learn something valuable here too. You can make better hiring decisions by understanding the challenges of modern engineering recruiting from the candidate’s perspective and creating great interview prep resources for your company. Or just send them this post.

This is a multi-part series. I will cover the entire tech hiring process, end-to-end.

Subscribe now

The Challenge

“People don’t want to buy a quarter-inch drill, they want a quarter-inch hole.”

– Theodore Levitt

In true Moneyball fashion, companies don’t “buy” engineers, they buy results. Companies want to solve customer problems, ship reasonably good products that don’t break too often, and make lots of money. Your amazing coding skills and captivating personality are, essentially, means of accomplishing that.

Recruiting is time, money, and people intensive, not to mention risky. Hiring a developer takes tens to hundreds of people.hours in most companies, and a bad hire can set a project back significantly. To make things worse, most engineering job posts get hundreds, even thousands, of applicants. This means that the time per applicant that staff will dedicate to your post is going to be rather short.

Many inexperienced applicants believe that recruiting is a perfect process designed to accurately assess their skills and generate deterministic, objective results. This is not true.

Tech hiring processes are indeed designed to screen for functional competency. They are also designed for cost efficiency (i.e. in terms of people, time, and money), to screen for several desirable traits (ex: teamwork, delivering results, working under pressure, specific cultural values, etc.), to scale to many applicants, and to minimize risk (which is why folks with unconventional backgrounds have such a hard time interviewing).

Trade-offs include candidate experience and decision quality. They are also driven by real people, further complicating the whole thing. Finally, many tech companies simply don’t know how to hire engineers, which adds a whole new degree of fun.

Interviewing is a stressful process. Not everyone will be nice. Some folks may be downright disrespectful or unprepared. Dealing with interviewers who clearly don’t want to be there or recruiters who ghost candidates is nobody’s idea of a good time.

Anatomy of the Tech Hiring Process

I’ve written about the general tech hiring process before. They can vary heavily from company to company, but they generally look like this:

The first step is the CV Screening. This is where a good CV and customized cover letter will help you. Your goal here is to get to a call. This stage includes:

• Recruiter CV Screening: first screening, done by tech recruiters. They won’t dive too deep. They are looking for basic fitness (ex: programming language or years of experience) or red flags (ex: lots of typos, obviously false info, irrelevant background). Has 100’s of CVs to review.

• Hiring Manager CV Screening: usually your future (engineering) manager. Will look a bit deeper and decide on go/no go for an interview. Has 10’s of CVs to review.

If you clear the CV Screening then you really are in the game. The next stage is the Screening Calls, where you will speak with the recruiter and, hopefully, the hiring manager.

You won’t dive too deep here - these calls tend to last 30mins or so. Good screeners will be looking for basic fitness and strong red flags (i.e. deal breakers). Whether screeners share notes with other interviewers varies from company to company. You may get a take-home test from some companies. The goal here is to get to the Deep Dive (a.k.a. on site).

The final stage is the Deep Dive. This is it - the bulk of the interview process happens here. This will take anywhere from 2h to 3 days, with 3-5 1h interviews being common. Common interviews are:

• Software Engineering Fundamentals: this is your typical “coding interview”. You will be asked to solve technical problems, varying from Hacker Rank to debugging. You will review your take-home test here if you had one. Be prepared to bring your A-game in terms of algorithms, data structures, programming language knowledge, and basic problem solving.

• Systems Design: this is a personal favorite of mine. Here you will solve a real problem with real specs by designing a system that a company (preferably the one you’re speaking with) could reasonably implement. Think questions like “design Google Maps”, or “design Uber“, etc. The complexity of the challenge will be fine tuned to the role’s skill level requirements. Good candidates will ask clarifying questions and use their system design knowledge to create a solution taking into account scale, efficiency, implementation difficulty, trade-offs, etc.

• Behavioral: interview focused on understanding how you work within a team, how you operate under pressure, how you own and learn from past mistakes, how you communicate with stakeholders, etc. This is a soft skills focused interview, and many engineers make the mistake of dismissing it. This is a mistake. This interview is as important as the hard-skills focused ones.

• Bar Raiser (optional): the Bar Raiser is an interesting interview. Bar Raisers tend to be very senior folks with specific training to really dig and find your limits. Good bar raisers are uncomfortable - you’re being pushed, after all. They cover hard and soft skills, and can even factor in notes from previous rounds. Not all companies do Bar Raisers, and they tend to be reserved for more senior roles, but watch out for them! Bar Raisers are highly regarded folks and their opinions hold a lot of sway.

• Skip Level (optional): good news, you are likely one foot into the door (but don’t let up, you’re not there yet). This is a call with the boss of your future boss (or even the company founder). It’s not very structured, but the interviewer expects lots of questions and enthusiasm. They will be doing a sanity check, watching out for red flags other interviewers might have missed, and selling the position hard (they like you, after all). Good candidates will have plenty of questions about the company, product, team, career development prospects, and other relevant topics. Pro-tip: leave questions like vacation policy and bonus payment schedule to your recruiter or offer call.

Assuming everything went well, you will get get an offer. Congratulations! Usually there will be a call to go over the offer details, key dates, contract specifics, etc. It tends to be pretty straightforward.

NOTE: while this process can vary a lot from company to company, preparing for this standard will usually leave you over-prepared. There’s no such thing as overkill in interviewing IMHO.

Before the Interview

“Every battle is won before it is fought.”

- Sun Tzu

The road to getting an offer starts before any interview is scheduled. There is no hack, shortcut, or silver bullet that will replace preparation and strategic hard work.

Recruiting is a complex, multi-dimensional process. Shockingly, companies don’t usually prepare their employees to interview elsewhere. Universities and boot camps generally don’t do a stellar job either. Preparing is on you. You need two things to be fully prepared: strong functional skills and interview skills.

Functional skills - i.e. what you need to do the job - can be divided into hard and soft skills.

Hard skills include solid software engineering fundamentals, knowledge of core tools and processes (ex: Javascript and Agile), and the ability to solve real problems by designing good solutions, taking into account reasonable business and non-functional requirements. This is usual the easy part for most engineers.

Soft skills include knowing how to constructively deliver results, individually and as a member of a team; having a growth mindset, constantly learning; communicating effectively, adapting for the audience; being able to self-manage, manage up, and help others. These can be hard to grok for engineers, but are essential.

Interview skills - i.e. you can convince others that you can do the job - revolve around communications, sales, self-control, and time management. Remember, tech hiring is a risky proposition for companies and you have a limited time budget to prove you can do the job. They won’t hire otherwise good candidates if the risk is deemed too high, which almost always happens when that candidate interviews badly.

Cue the training montage!

Tenets

Let’s start by establishing a few tenets. Explaining and proving each one is a post in itself so, for now, take these as self-evident truths.

Competency != offer. Recruiting is an imperfect process, as are the people involved in it. Just being competent will not, unfortunately, guarantee your success. This can be incredibly frustrating, especially if you end up missing an opportunity that you were super excited about and felt like a perfect fit.

It’s a numbers game. Most folks need to apply to 50+ jobs before succeeding. These numbers can be lower if you are an amazing and really well-prepared candidate. It’s easy to get discouraged after applying dozens of times without any success. Keep calm. Power through.

Treat each opportunity as the last job on earth. Many folks who hear the “it’s a numbers game” spiel end up blasting fifty low-effort, generic applications to every role with “Software” in the title. It’s important to read through every description, tailor your application accordingly, write a custom cover letter when possible, prepare a high quality resume, etc. The person screening your application will likely invest 10-30 seconds doing a first scan, and low-effort / generic applications easily stand out (in a bad way). Respond all emails ASAP and be on time for all calls. Being late is not a major issue if you have a good reason, but it doesn’t look good.

Always be selling. Make no mistake, recruiting is a sales process. The product: you. Keep that in mind at every stage of the process. Be polite. Focus on the positive impact you will bring to the company. Show how you’ve learned from past wins and mistakes. Do a bit of subtle self promotion too (I know, it’s hard). You want the best non-fictional version of you to come across at all times.

Failing to prepare = preparing to fail. I think we covered this already, but let me reiterate: preparation is key to success if you want that awesome role. Build a schedule and stick to it. Preparing will require discipline and hard work. Motivation alone is not enough.

Learn, iterate, and move on. Chances are you will fail most of the time. That’s fine. Don’t take that personally. Learn from the process, figure out what you can do better, and move on.

Preparing

First, establish a baseline for the role you are seeking. The job description is the first place to look. I also wrote on engineering levels before, so you can use that to figure out what skill levels and scopes are behind the JD.

There is no such thing as being over-prepared for interviewing. If you follow these practices with discipline and dedication, you will be ready (and likely learn a lot in the process). It may take a month or six, but it will happen.

Fundamentals & System Design

Let’s start with the more technically-oriented rounds: Software Engineering Fundamentals and System Design.

Solid software engineering fundamentals include:

• Data structures: knowing basic data structures (ex: maps, arrays, lists, etc.), when to use them, etc.

• Algorithms: knowing how to effectively manipulate data and perform work in a variety of scenarios (ex: sorting, looping, searching, filtering, etc.)

• Tooling: knowing how to effectively use tools relevant to the target company. Ex: Javascript, AWS, something SQL, etc.

• Software Design: techniques and principles to reliably, efficiently, and effectively solve common software problems, like business logic encapsulation and data access. Think Design Patterns, SOLID, Domain-driven Design, TDD, etc. At a more granular level, this includes service objects, repositories, REST, MVC, web components, etc.

• Development & Operations: practical skills engineers rely on to develop, build, distribute, operate, and troubleshoot applications. This includes source control, package management, basic deployment and ops (ex: SSH, PaaS, maybe some Kubernetes, etc), application monitoring (ex: using DataDog), debugging, and incident management.

• Problem Solving: ability to effectively use all of the above to solve problems, taking into account efficiency, requirements, and constraints.

Start by grinding your way through online code challenges. Setup a regular schedule to solve a couple every day. This can be tedious and frustrating, but it will help you build a good foundation in terms of data structures, algorithms, programming language (part of tooling), and basic problem solving. I strongly recommend using an interview prep platform if you can. My go-to recommendation is Algoexpert, but there are several options online.

The best way to develop strong tooling, software design, development & operations, and more complex problem solving is to implement real world applications. If you had a chance of doing this professionally then great! Reflect on what you did, what you learned, and what you think you could do better. You could even re-implement parts of it to test out these concepts.

Fear not if you didn’t have a chance of building good practical knowledge. The next best thing to on-the-job-training here is to find interesting or common business problems and build fully fledged applications around them. These can vary from simple TODO and chat applications to cloning Google Maps. You would be surprised how much you can learn if you take this exercise seriously!

EDIT: for a fantastic example of the above, check out this blog post from the great Pragmatic Engineer. I love the overkill :)

Moving on to System Design. I love System Design. This is the ability to solve real-world problems from user to server. This interview will assess:

• Requirements Gathering: the first step to designing a real world system is to accurately and comprehensively understand what problem we are solving and who we are solving it for (a.k.a. the user). These are then translated into clear business and technical requirements and constraints. Bonus: mapping the jobs to be done.

• Domain Modeling: translating the problem, requirements, and constraints to a representation of concepts, relationships, and workflows. Good systems tend to stem from well designed domains.

• System Components: these are the basic building blocks of any system. Ex: HTTP APIs, load balancers, background workers, stream processors, databases, block storage, etc.

• System Patterns: how you can combine components together to solve problems, when to use them effectively, and the difficulties and trade-offs associated. Ex: CRUD HTTP APIs, pub-sub, work queues, event streams, lambda data architecture, database sharding, two-phase commit transactions, etc. This also includes the basics necessary to “stitch” components together, like networking protocols, encryption, etc.

• Infrastructure & Operations: how to deploy and run the system at the scale necessary. Ex: S3, Kubernetes, Data Dog, Jenkins, etc.

The best way to build system design skills is to, well, build systems. If you have previous experience building complex systems, go back with a critical eye and understand why things were done a certain way and what could be improved.

You can create proof-of-concept applications solving problems that require non-trivial design patterns (or at least ones you are not familiar with). Building a chat app will help you learn about pub-sub, web sockets, and data bootstrapping. Building a click tracking app will help you learn about high throughput APIs, event streaming, background workers, and analytics.

I strongly recommend checking out interview prep platforms with good system design sections if you can. Algoexpert is a great choice here too. They have tons of system design videos simulating real interview conditions. I’m not affiliated with them by the way, just love their work. Way to go, Clement.

Finally, there are tons of great system design resources online, many available for free. I’ll link some at the end of this section.

NOTE: many large tech companies put a lot of emphasis on abstract tech challenge, but startups and younger/nimbler companies really want real world skills.

Behavioral

Moving on to the Behavioral interview, a decidedly soft-skills-focused round. This is where many engineers with strong hard skills tend to slip.

Sadly, many engineers take too long to understand the importance of soft skills. They are absolutely essential to getting things done in most work environments. The reason is that most businesses are marathons, not a sprints. A “10X engineer” with terrible soft skills can deliver a POC or address really complex tickets in record speed while killing morale and efficiency for everyone else. Savvy managers know how to deal with them, but nobody likes working with a jerk long term.

Some of the main soft skill clusters employers seek are:

• Self-Management & Delivering Results: having strong technical skills is great, but knowing how to apply them to solve problems and deliver results is what employers want. This includes creative problem solving, self-management, working backwards from the desired end-result, and others.

• Teamwork: unless you work in a vacuum, you need people to get things done. These can be colleagues, your manager, stakeholders, customers, and others. This cluster includes interpersonal skills, a positive (but not naive) attitude, empathy, and others.

• Communications: the ability to effectively get your point across, gather information efficiently, have difficult conversations in a mature way, etc. One key point many engineers take years to learn: adapting for the audience (i.e. what matters to your colleagues may not matter to the Product Manager).

• Business: the vast majority of employers want to make money. This means solving real problems to someone for some reason (a.k.a. providing value to customers). Closely related to delivering results. This includes knowing who your customers are, what problems you are solving for them, why those problems are important, what challenges they are currently facing with your solution, etc. Extra bonus points if you remember business KPIs and jobs-to-be-done.

• Ownership & Growth: do you take ownership for your wins and your mistakes? Or do you push blame onto others? Do you go the extra mile to identify and fix problems, showing initiative? Do you focus on negatives, or do you learn from your mistakes and move on?

• Leadership: leadership does not mean authority. Great engineers, even straight out of college, know how to lead by influence and drive an important project forward. The best “high potentials” are those who are also great leaders IMHO. Managers love engineers with high ownership and leadership skills as they tend to be “fire-and-forget”, being able to operate in an ambiguous environment with little to no oversight.

It’s not easy to prepare soft skills outside of real world experience. Worse, employers are really looking for the practical application of these skills, not theoretical answers. This is hard for first-time candidates or those who did not have good experiences so far. That doesn’t mean that you can’t prepare or shine. I will write a post dedicated to this in the future, but let’s focus on a few things you can do right now.

Self-reflection is your first option. You can reflect on past experiences through the lenses STAR framework. STAR stands for “Situation, Task, Action, and Results” and provides a way to organize past experiences and analyze them. Example:

• Situation: Our website was slow, which caused significant customer frustration and lowered our conversion rates.

• Task: I had to fix the website load speed.

• Action: First, I looked at our monitoring and logging to figure out why the website was slow. I noticed that we didn’t have all the data, so I implemented Solution X to figure out what the issue was. The problem turned out to be our CDN - as in, it did not exist. So I proceeded to setup a CDN with global edge locations to serve our compiled website.

• Result: We reduced the website load time by X%. More importantly, I learned that the number of customer complaints reduced significantly, but I do not have the real numbers here with me.

• Learnings (BONUS): I learned that it is really important to have good website monitoring. I think that we could have solved this issue much earlier if we knew what the problem was. Since then, I try to setup really good monitoring from day one when creating or changing anything.

Create a storybook in STAR format covering as many of the soft skill clusters as you can. I cannot emphasize this enough. This is the key to confidently answering questions like “tell me about a time that…” without replying with “uh…hmmm…well there was this, uh, time that <insert badly remembered semi relevant rambling here>”.

By writing down this storybook you will be able to reflect on past experiences through a new perspective - possibly even identifying learnings that you did not see at the time. You don’t need to write The Lord of the Rings here - 5-20 stories should be sufficient. And for gods sake they should all be true. Good behavioral interviewers are excellent BS detectors.

Oh, and make sure to include mistakes too so you can crush the dreaded “tell me about a time you made a mistake” question. Here’s an example of how to talk about a mistake in a constructive way:

• Situation: We had to deploy a new website for a product launch.

• Task: I was tasked with setting it up and making sure that the website was online on date X.

• Action: we were on a tight schedule, so I used a static website generator and NodeJS to compile and serve it.

• Result: I was able to push the website live on time, but something was off. The site was slow for many users and we got a lot of complaints.

• Follow Up (BONUS): I added some monitoring and figured out that, while serving with nodejs worked, it was not efficient given our request load, and we had users from all around the world coming in.

• Fix (BONUS): I quickly added a CDN in front of our website with plenty of edge locations, which fixed the issue instantly.

• Learnings: I will be more careful in the future when considering the launch plan parameters. Just working is not necessarily enough. Also, I should add monitoring on day one so that I can quickly capture problems.

There you go. That story could have been a major disaster at first, but you were able to communicate it truthfully while remaining reasonably positive and showing that you learned from the experience. This also works even if you were not the one who fixed the issue by the way.

“But Marcelo, I don’t have any experience, this is my first job! What can I do??” I hear you say. That’s alright. You can put together a storybook with situations from your college, open source projects, hackathons, etc. Just make sure that they are relevant to the job (i.e. nobody wants to hear about your last minute beer run in STAR format). If your Behavioral interviewer insist on “real world situation”, you can politely remind them that this is your first job.

NOTE: some folks might think that this is cheating or manipulation. It is not. Employers have a bias towards not hiring if the team is not sure about the candidate. A great engineer that interviews badly will not build that confidence and will not get the job 90%+ of the time. I would much rather interview a clearly well-prepared candidate and make a confident decision than go through a painful one hour call with an ill-prepared candidate. It’s just the way it is.

Another way of preparing is by seeking mentoring or coaching. Many people find it hard to self-reflect at the best of times, and early-career folks may not have the experience to do so objectively and thoroughly. There are great options online to connect with mentors. An example is The Mentoring Club, where experienced professionals mentor folks like you for free. I serve as a pro-bono mentor there.

Finally, there are books and YouTube. There are tons of interview tips or, even better, simulated interview videos there (not as many books though). Many of them are created by companies themselves. Why? Because companies want to hire you for your functional skills, not your interview skills. Managers hate to pass up on potentially good candidates that failed the interview.

All Other Rounds

I will not cover the other rounds in the prep stage (screening, bar raiser, etc.). Your core preparation will target the Software Engineering Fundamentals, System Design, and Behavioral rounds. This is your foundation. The other rounds will largely rely on this foundation, exploring different facets in different ways. The key is in how you go through them, which I will cover on Part 2.

Additional Resources

Other great sources of information are books, blog posts, open sample codebases, online courses, and YouTube. I like them and you can learn a lot from them, but I wouldn’t rely just on passive learning. You have to learn by doing.

• Fireship: great YouTube channels with “high intensity coding tutorials”.

• ByteByteGo: my go-to newsletter for systems design of all shapes and sizes.

• Mentoring Club

• Interview preparation platforms:

  • Algoexpert

  • HackerRank

  • Exponent

• Books:

  • “Cracking the Coding Interview”, by Gayle Laakmann McDowell.

  • “System Design Interview”, by Alex Xu.

  • “Domain Driven Design Distilled“, by Vaughn Vernon.

  • “Answering Behavioral Questions in Amazon Interviews”, by Jennifer Scupi.

• Videos:

  • “Amazon Interview Questions”, by Exponent

• Online courses: Udemy, Coursera, etc.

Key Takeaways

• Companies buy results, not work. They have a problem to solve. Your skills are a means to an end. The goal of the entire process is to answer this one question: can you deliver the results the company wants?

• Tech hiring is not perfect. This is a human and time-bound process. Things will be messy. Don’t assume that competency is enough.

• You need functional and interview skills. Functional skills prove you can do the job. Interview skills convince others of that fact.

• Preparation is critical. Most people don’t breeze through a strong tech hiring process, and all the great jobs are behind one. Prepare by working smart and hard. Build a schedule, and stick to it. There’s no such thing as overkill.

• You can make it. Folks land great jobs (or first jobs) all the time. You can do it, if you do the work. It may take a week, a month, or an year, but you’ll make it.

What’s Next

I will cover the rest of the tech hiring process on Part 2, including how to run the interviews, what to do (and not to do) afterwards, and how to close the deal. There is nothing preventing you from starting today, however. Happy prepping!

If you think someone in your network would like this, then

Share

Want to join the conversation?

Leave a comment

Thanks for reading, I hope you liked it! For more content like, feel free to

Subscribe now

Helping engineers perform and developing their careers is not easy. Startups tend to have very little structure to begin with, so managers and engineers often find themselves reinventing this wheel while pushing it uphill. But there’s a trick from established companies that can help: engineering levels.

Whether you are a first time tech exec tuning your engineering team, an engineering manager who wants to do right by their team, or an engineer who wants to grow professionally and look great doing it, read on. This one is for you.

A Brief Introduction

Engineering levels are one of the fundamental building blocks of finely tuned tech companies. You will find them in FAANGs, established companies and startups built or managed by experienced tech execs. I personally experienced them at Delivery Hero and Amazon, supported their launch at AutoScout24, and designed the framework from the ground up at multiple startups.

Engineering levels establish clear win criteria for engineers at different stages of their careers. This provides four key benefits:

• Performance management: managers can assess where contributors currently fall into their assessed level, set clear expectations ahead of time and help them close any gaps over a reasonable time frame (often a quarter).

• Career development: there is a clear path between a person’s current capabilities and the next step in their development journey. Managers and contributors can identify concrete development action items and track development progress over time.

• Fair compensation and promotions: having a well understood common measurement stick helps with providing fair, unbiased assessments to contributors of all backgrounds.

• Staff planning: knowing what you can expect from people at different career stages allows managers to reasonably plan their staffing needs based on capacity gaps and project needs.

These benefits are not limited to individual contributors (ICs). In fact, many tech companies have a levels structure (or “tracks”) for engineering management, product management, program management, and many other tracks.

Building an engineering levels framework and launching it is not trivial. The specifics on the engineering levels of these companies are not, usually, publicly available information. You can probably find a high level description of them, but anything more specific is hard to come by.

To solve this I created a foundational framework that you can adapt. You can use it to kickstart your engineering career program and evolve it as you gain more experience.

Note to individual contributors: keep reading as this will give you a deeper understanding of why your company might have a similar framework in place, how it works, and how you can use it to improve. If your company doesn’t have this system in place and you would like the benefits that this mechanism brings, send this post to your manager. We are usually pretty cool people.

Reference Engineering Levels Framework

Our reference framework is based on five distinct levels - Level 1 (L1) through Level 5 (L5). This model works well for organizations of a single team up to a few hundred engineers. After that point, you would need more levels (like Google’s Fellow), or finer grained levels (like “Senior Staff Engineer”).

We are going to focus on the Individual Contributor (IC) track. There is a distinct track for engineering managers, which I will cover separately.

The Five Levels

The five levels in this framework are:

• Associate Engineer (L1): the tech track’s entry point. Zero to minimal industry experience, but a mountain of willingness to learn.

• Engineer (L2): the foundation of most teams. Moderate amount of industry experience. Can do most jobs. Needs support for complex tasks.

• Senior Engineer (L3): the keystone of most teams. Lots of industry experience and a wide array of skillsets. Tends to be a subject matter expert in one or more areas. Enables teams to deliver on projects of any complexity by supporting L1s and L2s when needed.

• Staff Engineer (L4): fundamental to delivering on critical and/or cross team projects, often working closely with engineering managers, stakeholders and engineering teams. Excellent individual contributor skills. Leads by influence. Tends to be a subject matter expert in multiple areas, having served in many teams and solved many different problems. Coding starts to take a backseat to experimentation, coordination, planning and support. Helps create an engineering vision and strategy for the group.

• Principal Engineer (L5): critical to setting a medium and long term engineering strategy for the organization or division. Has a deep understanding of technical and business matters. Expected to interact often with directors and other executives, identify large scale problems and/or opportunities on their own (and address them) or own a critical project. Good communication, leadership and management skills. Codes little or not at all, and only on specific situations.

Definitions

The Title serves as a reference point and can vary from company to company. What company A looks for in a “Senior Engineer” can differ significantly from Company B’s version.

The Scope represents the degree of responsibility at the organizational, product or architecture level. In this framework, the target scopes are a single team, a group of teams, and an organization (major division or the entire company).

Scopes can be further categorized into normal and high stakes. High stake teams, groups and organizations are usually in charge of a core system or platform that many teams rely upon, a mission-critical function or even a very important project. Ex: Infrastructure, Payments, Authentication, etc.

Expectations can be divided into two main categories - Inputs and Outputs. Inputs represent the capabilities, skills and behaviors an engineer displays. These are good predictors of someone’s ability to deliver results and generate impact. That’s what we want at the end of the day.

Outputs represent the results and impact an engineer generates. Results (a.k.a. outcomes) are closely linked with how reliably and how well a person executes tasks and projects of increasing complexity.

Impact represents the net effect of everything a person does. This includes the impact of the projects they tackle, the problems they set out to solve, and even how positively (or negatively) they affect those around them. Think of impact as solving the problem vs doing the task.

Be careful when using impact in performance management. An individual’s impact is heavily influenced by circumstances outside of their control (ex: the team’s product roadmap). Ex: a senior engineer responsible for a major site reliability project must not only execute several complex tasks (results) but, also, interpret their results, iterate on the plan and coordinate at multiple levels to ultimately achieve the end goal of increasing reliability (impact).

Finally, each level also has a reference experience band, in total years of software engineering experience, that a person at that level typically has. This is not a hard and fast rule (more on this later)!

Diving Deeper

The degree of autonomy and impact increases the further up the ladder we go. The work also changes focus from from individual contribution to higher level design, coordination, coaching, strategy and communications.

Reality will not always line up perfectly with this framework. It should not be used as a substitute for good judgement. It’s important to understand the letter and the spirit behind these levels. Examples:

• high potentials: folks with strongly skewed skillsets (ex: strong tech skills, bad interpersonal skills).

• strong demand for a certain role: pushing someone underprepared into larger roles (ex: an L3 supporting a group like an L4, or an L2 tackling major tasks without L3 support).

• small organization size: not enough “room” to provide upwards mobility, increasing the risk of pushing high performers out of the organization.

I will cover these situations in the implementation and maintenance phases in more detail.

Associate Engineers (L1)

Associate Engineers are the entry point in the professional software engineering career. They often have 0-3 years of industry experience. Most are fresh out of college, but you might see a few older folks who are changing career tracks.

Scope

L1s do better in normal (i.e. non-high-stakes) teams.

L1s are expected to introduce production-breaking bugs from time to time. They seem to be able to do this despite sophisticated checks and balances and processes, so just expect that to happen every now and then.

Accept that things will break and place them in an environment where they can safely learn from their mistakes.

Capabilities, Skills & Behaviors

They should be curious, take feedback well, be humble and have a solid foundation of software engineering basics to build upon. This includes data structure fundamentals, basic algorithms, common system and design patterns, well known tools, etc.

Many L1s coming out of top universities or well known companies might have an overdeveloped ego. Look out for difficulties in taking feedback well, learning new things, an “I already know this” attitude or an over-eagerness to introduce new tools or practices without learning more about the status quo.

Results & Impact

They should be able to execute simple tasks without supervision, and tackle medium-level work with L2+ support. Look for clean, well tested code that is not necessarily optimized or well designed at the system level.

They should be able to handle basic on-call duties, but do not expect them to handle major incidents. If you can, schedule their on-call duties together with L2s and L3s. They can still help if an incident happens and they will have a valuable learning experience.

Finally, look for L1s who are growing fast into L2s. That should be their ultimate goal.

Engineers (L2)

Engineers (L2) - are the foundation of most teams. L2s tend to have 2-6 years of experience and a solid understanding of how to craft software in “the real world”. Good L2s will likely build & run the majority of your products - be it by themselves or with the support or L3+ folks.

Common names for L2s are “professional engineers”, “full engineers”, “competent engineers”, and others.

Scope

L2s can make up the bulk of normal teams and some can do well in high stakes ones. They should have a working knowledge of their team’s (technical) domain and how it fits within the group.

Good L2s will also have a basic understanding of who their customers are, which problems they are solving and how the business works. The best ones learn “why” they need to implement Feature A and use that knowledge to drive design and implementation decisions.

Capabilities, Skills & Behaviors

L2s should have a deeper and wider understanding of the fundamental skills they cultivated as L1s. The main difference, however, is knowing how they all come together in the real world and work in practice.

At this level they also should have a deeper understanding of tools and techniques required by your SDLC. This includes source control, releasing, deploying, CI/CD, monitoring, tech ops (in your stack), etc. This includes “business” tools too, like OKRs and KPIs.

Results & Impact

L2s can design and execute tasks up to medium complexity with little to no support, and tackle complex tasks or projects with L3+ support. A team with a good balance of L2s and L3s working together can be very effective.

L2s should also serve as Incident Commander of minor incidents. This will enable them to lead bigger ones in the future.

Senior Engineers (L3)

Senior Engineers (L3) tend to have 5-12+ years of experience and that shows in their degree of maturity. A hallmark of good L3s is that they are the most capable and reliable individual contributors in most organizations, requiring the least amount of support to get the job done.

L3 is the widest and most difficult level to clear in my opinion, with the second half band being much harder than the first. This is where supporting others starts to become a significant part of the job, and that requires developing a whole different skillset.

Scope

Most teams should have at least one L3. L3s can also serve as the foundation of high stakes teams.

Good L3s will have an excellent understanding of their team’s domain, a good knowledge of what other teams do and how the organization works.

Most L3s will be subject-matter experts in one or more non-trivial areas. Ex: you might have an L3 who knows everything about Payments.

Capabilities, Skills & Behaviors

L3s have an excellent command of software engineering and systems design skills in real world settings. They can choose the right design patterns for a given problem, identify operational and security concerns, take cost into consideration, etc.

L3s are effective communicators - they can write clean documentation, effectively align on requirements with stakeholders and implementation details with colleagues, know when to bring relevant facts into a discussion, etc. L3s should be particularly good at adjusting for the audience, leaving technical or non-relevant details out when desirable.

L3s should be able to lead by influence, not authority. They have many responsibilities in supporting and leading others, but not formal authority to compel action (which is not normally desirable anyway). They should be able to engage stakeholders and teammates constructively, have “strong opinions weakly held”, be able to disagree and commit, etc.

L3s are great at managing up, and have a deep enough understanding of how delivering software works that they can work effectively with engineering managers as partners. This, coupled with leading by influence, often makes L3s serve as “tech leads” of their teams. Many Engineering Managers come from an L3 background.

Great tech companies can develop an “L3 Mafia”. Their L3s understand really well what each team does and build a good rapport between themselves. They usually know who to DM when they need some information, a minor change, help during an incident, or anything else that crosses team boundaries - often without needing the support from managers. Good managers would do well to encourage and help build such networks.

Finally, L3s should be good at asking for feedback regularly and responding to it in a mature way.

Results & Impact

L3s can design and implement tasks of all sizes as individual contributors or as leaders of a small task force of L1-L3s with minimal to no support. They are as close to “fire and forget” as you can get.

L3s should also be able to onboard L1-L3s and mentor L1s and L2s. In fact, mentoring, supporting and leading others effectively are some of the most critical skills an L3 needs to master before becoming an L4.

Good L3s can serve as Incident Commanders of critical incidents. They also tend to be “pulled in” into incidents as subject matter experts.

Staff Engineers (L4) and Principal Engineers (L5)

Staff Engineers (L4) and Principal Engineers (L5) are roles where the degree of autonomy, responsibility, and ownership increase significantly, making these levels quite different from the L1-L3 range.

L4s and L5s share many characteristics with the Management track - so much so that, in many companies, the Individual Contributor and Management tracks converge at one point.

As these levels have significantly different mechanics from the previous ones, I will cover them separately in future posts.

What’s Next

This simple framework should be enough to get started in most organizations. Naturally, you should adapt it to the reality of your company. Implementing it and using it to drive hiring, career development, promotions, and other key processes can be challenging in reality, so I will write about these topics in future posts.

I will also cover the Engineering Management and Product Management tracks in the next posts.

In the meantime, happy leveling!

From a Non-Traditional Background to Director of Software Engineering at Spotify by Gergely Orosz and Nivia Henry

I don’t have much patience for theory and much prefer learning by doing. Learning from the real experiences of great people comes in close second. This is the story of how Nivia became a Director of Software Engineering at Spotify. That, by itself, would already be a story. What makes this a great story are her unusual background, the challenges she overcame and the lessons she learned along the way.

Tech is a wonderful industry where folks from all walks of life and backgrounds can find opportunity, myself included (I’m a terrible physicist).

Inside the World’s First Undersea Roundabout by Jaden Urbi

I often forget that great lessons don’t have to come from business or tech articles - or even be directly related to them. This week I learned that the Faroe Islands, a tiny island country of 50K people in the North Atlantic, has underground tunnels. A lot of them.

What makes this especially interesting is how quickly they build them. A recent, major project took about 4 years to construct, and I saw estimates that a similar project in, say, NYC would take 15 years or more. They can make decisions quickly and run circles around much larger communities exactly because they are so small.

If you work at a startup where decisions take waaaay too long, remember the Faroes - being small can be a major super power if you use it right!

Subscribe now

What are leading and lagging indicators? by James Stanier

I’ve learned the concept of leading and lagging indicators a while ago and I’ve treated it as pretty day to day topics since then. I’m helping improve how we execute OKRs at my current company and the topic came up.

Even outside of the context of OKRs, knowing what leading and lagging indicators are is a deceptively simple skill - it helps you identify and plan for what you actually want to achieve (usually lagging indicators) and use the right numbers to tell if you’re going in the right direction (leading indicators).

This is a good, non-jargon-y, down to earth introduction to the topic.

Mutation Testing by Robert C. Martin (Uncle Bob)

I have a confession to make - I’ve never done “proper” TDD. Sigh, feels great getting that off my chest. Back when I served as an engineer, I usually wrote tests after writing a small piece of code and went back and forth a little. I found writing lots of tests upfront to be super boring TBH. You should still do tests properly, goes without saying but Uncle Bob knows a lot more about the subject than I do.

I never looked into mutation testing before, and this was a nice introduction to the subject. Many associate and professional engineers start trusting things like TDD and test coverage metrics with an almost religious zeal, forgetting that they’re not perfect. This could be a nice addition to your team’s arsenal towards not setting production on fire.

Tech Debt: Reclaiming Tech Equity by Vishal Dalal, Krish Krishnakanthan, Björn Münstermann, and Rob Patenge

I chuckled a bit when I saw this. The content is good, but I thought it was funny seeing something about Tech Debt coming from McKinsey. The analogy with financial debt was particularly insightful, and definitely something I will bring up when convincing non-tech stakeholders why managing and paying down excessive tech debt is important (and why doing that might push Shiny Feature A back by a sprint or two).

Share

I wanted to break a bit from the relative doom & gloom of recent weeks. I found some interesting readings this week from people who are masters at what they do. Enjoy!

Software Engineering - The Soft Parts by Addy Osmani

This is probably my favorite this week. It’s a deceptively simple and compact write-up that contains a lifetime of practical experience from Addy Osmani, a Sr. Staff Engineering Manager at Google.

It is rare that we get a glimpse into “the real deal”, and the lessons Addy shares about software engineering, engineering management, working with others, growing and other cool topics are invaluable to anyone in tech. I wished I had run into something like this 10 years ago!

Highly recommended, even if you are not in tech.

Bottleneck #01: Tech Debt by Tim Cochran and Carl Nygard

I’m helping scaling and accelerating a fast growing startup team and the topic of managing tech debt came up. As with many successful startups, the team accelerated development early on in order to experiment faster and find product-market fit. As the product becomes more complex, the team grows and the company matures we need to manage our accrued tech debt well in order to maintain good speed.

Tech debt is usually “handwaved” as an almost arcane term and often mismanaged. This write-up provides clear guidelines for identifying, dealing with and managing tech debt in a sustainable and practical way. It also keeps in mind that that we need to ship features, provide a great use experience and generate revenue - i.e. this is not a purely technical exercise.

I recommend this one even if you are not a scale-up.

Subscribe now

The Anatomy of an Amazon 6-pager by Jesse Freeman

Amazon is one of the most successful tech companies of all time. It is also one of the most “cult-y”, and you can often spot an ex-Amazon person in the workplace by the unique terms, techniques and ways of thinking they use. Amazon’s writing practices are particularly interesting to me.

Jesse served at Amazon for 5 years and walks us through the “6 pager” with much more authority than many other similar posts do. This is a document usually reserved to plan significant projects, changes, processes or other high stakes moves. More importantly, he provides a concrete example that he created - a rare find indeed.

The Product Culture Shift by Camille Fournier

Camille is the author of The Manager’s Path, one of my favorite books in tech management (or management in general). In this article she addresses the topic of changing the culture of teams that are usually not directly involved in serving customers - usually infrastructure and internal platforms.

Picture an e-commerce company that, let’s say, handles deliveries for its merchants. Your team is growing, the product is becoming more complex and you provide merchants with multiple ways of selling and fulfilling their orders.

In order to keep the teams responsible for user facing features moving fast, your CTO decides to launch an internal infrastructure team (let’s say, an SRE team) and a logistics platform team, responsible for providing APIs to anyone building features around deliveries. Why is this hard? Quoting the author:

“Both of these shifts require going from a siloed, process, tech-focused mindset to a portfolio, usability, and customer-focused mindset. This is a hard transformation, and it’s easy for people who have spent their whole career building infrastructure to misunderstand what product and platform really mean.”

Can a Zebra Change Its Stripes? By Eric Newcomer

This one is a head scratcher, but you might’ve heard that Adam Neumann, the (in)famous founder of WeWork, just raised $350M from Andreessen Horowitz (a16z) to build his new company, Flow.

Eric helps us get a look into how VC works and how some such decisions are made, especially those that leave the rest of us puzzled.

That’s it for this week, I hope you enjoyed the list and has a chance to read at least a few of the recommendations.

I am working on some longer form, deep-dive articles by myself and in collaboration with a few friends, attacking problems from how to prepare for a tech deep-dive, deploying K8S in production, how engineering managers and product managers can collaborate better and a whole lot more.

If you have any topics that you want me to cover let me know, I’d be happy to help!

Subscribe now

Software Engineering

• 14 Patterns to Ace Any Coding Interview Question: many may be job-hunting for different reasons right now and, if you’re an engineer, chances are that you’ll go through a coding interview. This is a solid read on patterns common to most such interviews.

• How to Implement Trie (Prefix Tree) - Blind 75 LeetCode Questions: this is a good read on the Trie topic but, perhaps more than that, it’s a good intro into a popular series hosted at HackerNoon that covers many top LeetCode questions.

• Making your Code Look Pretty: moving away from interviewing a bit, this is a topic dear to my heart. We tend to be logical folks as engineers (most of the time), and topics like aesthetics can fall through the cracks. That’s a shame considering that code is read more often than written, and a nicely laid out function is a gift to countless future colleagues. This one provides a good, actionable starting point.

Leadership & Management

• Two-Pizza Teams Are Just the Start, Part 2: Accountability and Empowerment Are Key to High-Performing Agile Organizations: this is Part 2 in a great running series by AWS. I’ve often found that, amongst all of Big Tech, Amazon’s practices seem to be the easiest to translate to SMEs and startups, and the ones that end up being the most effective.

• Single Threaded Leadership - Lessons learned at Amazon: single threaded leadership is a concept that many are unfamiliar with, and that I first learned about at Amazon. This is a short introduction to STL.

Business

• ‘Metaverse’ job openings are down 81% as Facebook, Apple, and Google roll back hiring: even tech titans are feeling the economic headwinds, and their hiring decisions can often be used as a bellwether for much of our industry.

• Google CEO tells employees productivity and focus must improve, launches ‘Simplicity Sprint’ to gather employee feedback on efficiency: I think that companies laying people off or reducing / freezing hiring are driven by two key factors - reduce costs / burn rate, and get more for their current people investments. Google is not alone in this conversation - I can see these undertones in many other companies that had inside leaks, including Meta.

• The Scoop: One Deep Layoff or Death By a Thousand Cuts?: as always the Pragmatic Engineer brings valuable inside info from interesting companies. The analysis on the different types of cut strategies employed is particularly noteworthy.

We are going into a downturn. There's no question about it. Now's the time to figure out how we can get through these difficult times. This requires understanding what is going on in tech, tackling challenges that have not gone away with the downturn, and, even better, getting back on track by prioritizing work that generates impact.

• 'We were burning through money like no one's business': the economic downturn surprised many tech companies. This article by Business Insider provides a cautionary tale on how overspending - and the consequences of it - can significantly impact a would-be unicorn.

• YC advises founders to 'plan for the worst' amid market teardown: this one is not exactly new, but it's a must-read for startups today. YC provides some of the most actionable, direct, and straightforward advice for companies preparing or going through a downturn. Must-read if you lead teams or companies or want to understand what's happening around you.

• Oncall Compensation: insightful article from the fantastic The Pragmatic Engineer, one of the top sources of engineering information available. On-call compensation is a topic I have always found a bit difficult to navigate - there are so many different views on the subject from startups, large companies, US vs. EU, etc.

• How to Spark a Consumer-Grade UX revolution: This is one of my articles recently published by the good folks at InfoQ. This article addresses how teams can kickstart a change towards consumer-grade UX without having to move the entire organization. This is interesting as, typically, such projects span multiple teams and are complex to coordinate and execute. But it doesn't have to be that way.

All, things are not so great right now. But I believe that the industry will get over this sooner than you might think. Do your homework, understand what this status quo means for you and execute through it. See you on the other side!

PS: This is the first edition of what I hope to be a running series. I have gotten amazing feedback from many folks who’ve read my content. This feedback is fundamental to making this work, so please feel free to hit me up and let me know if you like this and how I can improve 😎. Thanks!

Subscribe now

Originally published on TechCrunch on March 17th, 2022.

You need to move fast. You have to build POCs, create MVPs, iterate relentlessly and keep systems alive when you finally get TechCrunched (and after). You need excellent engineers suited for a fast-paced startup environment to make that happen. Recruiting a winning engineering team can be daunting, especially for first-time or non-technical founders.

Startup recruiting is different from larger companies. You are looking for different profiles, you are probably not as well known, you likely don’t have dedicated recruiters, you have stricter time constraints, and you certainly don’t have the same budget.

I served at multiple startups and established tech companies worldwide and hired over a hundred engineers. I found that recruiting great engineers has four main challenges: discovery, engagement, assessment, and hiring.

Finding good engineers (discovery) is a subject in itself and there is plenty of information on how to structure offers (hiring), so let’s focus on engaging & assessing great candidates. I have identified a few startup-specific principles to engage and assess engineers that you can apply immediately - even if you do not have a technical background. 

Engagement

You need to earn the attention of good candidates. Let’s skip the basics, like getting an introduction through your network or running engaging LinkedIn and StackOverflow ads.

You are targeting the top 25% engineers, which puts you in competition with the best recruiters in the industry. You have to go on the offensive. The good news is that engineers get hit by recruiters all the time, so they have become wary of them (sorry recruiters). You have an instant advantage as a founder or startup manager.

Think of your opening message as a pitch - you are selling the idea of working with you and making your startup happen. Make it interesting for them: talk about the magnitude of the problem you are solving and the impact they could have; tell them about the cutting edge tech you are using and how they will have the freedom to shape the company's future. Don’t overdo it, but don’t make it sound like they would be exchanging one cubicle for another, either. 

Finally, remember that most of these folks are probably not looking for a job. If you approach them with a dry copy and pasted invitation to apply, your message will get fast-tracked to the bin. Look at their profiles, the communities they belong to, their interests, their skills, their backgrounds, who they follow, their GitHub profiles, etc. Learn what makes them tick, personalize your pitch accordingly and tell them why they are an excellent fit for your company - and vice-versa.

Assessment

Bad hiring choices early on can set a project back months - even permanently - and generate tons of technical debt. Experienced engineering managers are probably familiar with tech hiring, but non-technical founders and technical founders with no management experience should learn two ground rules first:

• Move fast: contact candidates 48h max after interviews, promptly answer questions and finish all interviews in 2 weeks tops. This is one of the few advantages you have over recruiters and established companies.

• Be interesting: they are assessing you just as much as you are assessing them. Build upon your initial pitch as you get to know them better and keep selling.

You also want to answer two fundamental questions: “can they functionally do the job and deliver results?” and “will they thrive at my company?”. You can do that using a screening call and, if they clear it, three one hour deep dive / onsite interviews. A good candidate pool results in a 20-30% screening clearing rate and 1% to 2.5% end-to-end conversion rate.

Screening

The screening round is a 30-45 minute call where you will decide if it makes sense for you and the candidate to invest more time in the process. Are they articulate and good listeners? Have they delivered significant projects in the last three years? What technologies did they employ? Do they know those projects technical and business KPIs? Do they know who the customers were and how their work affected them? Are they enthusiastic when referring to their work? What about your company interests them? Don't talk more than 20%-30% of the time - you don’t have time to dive deep here.

Finally, clarify what their individual contributions were versus their team's. Some engineers might inflate their achievements by focusing on team and company, even if they had a small part to play. Move forward to the next stage if you are 70% or so happy with their answers to avoid over-filtering.

Software Engineering

Good software engineers know more than just coding - they know how to create usable, scalable, secure software on spec, on time and on budget (mostly). Great ones can do so with one or more unknowns in the previous list.

If you have a good technical background you can check their software engineering fundamentals using a coding and problem solving interview. Startups should use real-world reference problems that cover basic data structures, scaling, design patterns, data manipulation and more. Avoid the synthetic exercises bigger companies use - you want someone who can deliver value on day one in a small team.

Ask the candidate to add caching to an API performing complex database calls; refactor a large service into smaller, cleaner ones; find bugs in non-trivial code; efficiently store and retrieve data based on a given use-case; etc. Good candidates should walk you through their thinking process and ask good questions in the process. Verify whether they command the language well, with some leeway for interview-grade pseudo-code.

If you are a non-technical founder and you can’t rely on a sr. engineer (employee, friend, mentor, advisor), look into third party selection services like automated code assessment platforms (ex: HackerRank, Coderbyte, and Codility) and interview-as-a-service companies (ex: Karat, expertlead and Geektastic).

Both work well, but senior startup engineers tend to prefer the latter. Speaking with good technical interviewers is a lot more engaging and accommodating of nuance than automated tests, to the point that many candidates might simply refuse to take them.

These services cost money, but you can balance that out by the time saved and the reduced hiring risk. They can also interview multiple candidates in parallel in case you have the (mythical) problem of too many good prospects.

Alternatively, you can learn the foundations via websites like Algoexpert (they have amazing basic data structure and systems design courses). Picking up the basics of a programming language like JS or Python is also easier than you might think, and that can help you understand better what makes great engineers great.

Systems Design

There are many engineers who are competent at solving narrow technical problems or writing great code but who cannot work backwards from a business problem towards a real world solution. Established companies can compensate by having different skill sets in a team. In a startup, you need flexible, pragmatic, skilled people who know how to create entire systems.

If you have a solid technical background this is the round where you ask questions like “how would you design Uber?” or “how would you implement Google Maps?”. Good candidates will ask lots of clarifying questions, like what is the target throughput, who are the users, what do they want to achieve, etc. Great candidates can figure most of that out from basic fundamental assumptions, like how much storage you need to power a Maps-like application for millions of users.

Ask them to design a concrete architecture diagram, make real choices for key components (ex: you want to hear “Kafka” and why, not just “pub/sub”) and walk you through their solution. It is important to pick a challenge that is somewhat related to what your company does, but make it clear that you are not just getting free consulting from your candidates.

Finishing the entire design is not important, but watch for signs that the candidate is over complicating their solution and offer hints to help them see it.

If you are not a technical person then interview-as-a-service companies can help. Make sure to specify what type of challenges you want them to use - you want engineers who can solve e-commerce related problems for your e-commerce startup.

Alternatively, study and use some design challenges online and take the role of a non-technical product manager when interviewing. You might not be able to understand the finer technical details, but you can dig into requirements, pros and cons, what candidates miss and how much they understand the business needs. This is also representative of how you will actually work together.

Values & Capabilities

In this round you want to explore the candidate’s ability to communicate, work in a team, understand business and customers, deal with difficult situations and deliver results.

Check their motivations and what they want to achieve. This can be the difference between sticking around through tough times (which is a given in startups) or jumping ship when the greenfield project feeling is over. What are their long term goals? What do they see in your company that they are not getting in their current role? What do they love about engineering?

Understand how they work and what they value. What were their biggest achievements and what did they learn from those experiences? What about their biggest misses - do they blame others or focus on lessons learned? Do they know how to give and receive constructive feedback without confrontation? Do they like to tell others what to do or collaborate? How did they handle high-stress situations, like a major outage or a make or break deadline?

Finally, check what they know about business. This is particularly important in startups - you want engineers who know that the goal is not to ship software, but to serve customers. Do they know who their customers were and what they cared about? What were their technical and business KPIs, and how did they correlate? What is the business model of their current company?

Once you have built a mental model of who they are, what they value and what they want to achieve, you can understand whether they would thrive at your company. Combined with the functional knowledge and real world problem solving skills you checked in the previous two rounds, you can make a confident decision to move ahead or not.