What I’ve Learned Interviewing 300+ Engineers for 20+ top Silicon Valley startups. After a year and a half recruiting engineers for top early-stage Silicon Valley startups, including YC, Thiel, PearX, HF0, a16z founders, and more; and spending over 3000 hours searching for the best LatAm engineers, interviewing them, and analyzing them; I started to realize that there is a set of traits, behaviors and experiences, that make a great startup engineer. I’m talking about greatness, not perfection. Decoding a person is not an easy task, but as it comes to people, when it comes to engineers they come in all shapes and sizes, with different technology stacks and personality traits. However, the more I interviewed them, the  more patterns I saw. I embarked on a quest to deconstruct these qualities that I found fascinating, that usually are more personal, or related to how they think, than merely technical.  Great engineers possess a unique combination of these traits. My goal is to create a framework for any founder, technical manager or recruiter to spot the best engineers and startup recruits. Here is what I learned:

Crusaders: Great engineers take risks and do hard things.

Many great startup engineers, especially those who thrive in the early days, have a tendency towards taking risks. They cultivate this inclination and put themselves in situations where they can embrace challenges. Sometimes, they even come from unconventional career paths and switch their careers to software engineering.  Many interesting software engineers that I’ve interviewed studied hard sciences like physics, completed PhDs and found themselves without enough research opportunities in LatAm, or worked as hardware engineers, and ended up as strong backend engineers, as well as I saw experienced marketing or design strategists looking to add more to the product that became front end engineers, to just name a few.  It doesn’t mean that all of them have uncommon stories, but rather that a great engineer can come from almost any previous career path and that those who have encountered themselves with hard mental and professional challenges before may be fit for a career in software development.  People who switch careers encounter challenges and embrace high levels of the risk that come with such changes. A career change is a risk itself, but deciding to join a startup with an uncertain future is even riskier.  Probably one of the reasons why this trait is so important is because a risk averse person may be a great asset for a company and there may be sometimes smarter people who are risk averse, but maybe not the right fit for a startup, at least in the very early stages.  Many of the engineers that we tried to recruit that were risk averse, those from larger tech companies and specially the ones from consulting, opted not to take the job at the end of the process, mostly because of the uncertainty that joining a startup embraced as opposed to their stable jobs. So trying to assess the risk aversion early was pivotal as time is critical for early stage startups looking to recruit successfully. Risk takers are a good add to an startup early crew. This doesn’t mean however that there shouldn't be an effort on the recruiting side for assuring a stable job and a secure future, to its potential employees. Startups need to show how their solutions are relevant and the reward that comes with taking such risk; even as there is still the uncertain outcome that comes with a new venture. Sometimes people who take professional and intellectual risks, may not be able to take economical risks. So articulating a strong mission, opportunity for career growth, a transparent sight on the runway to pay salaries, and potential future rewards is key to attract risk takers. Another trait that I found interviewing engineers who take risks is that they are not afraid to speak their words and ideas. They take the risk to disagree with superiors, they feel proud about it through the stories they tell of their careers and contributions, which I think is very essential to the nature of a startup and its success. They are people who disagree, not afraid to do it, but instead of passively resenting it, take action. To find risk-takers, you usually have to look at their career trajectory, but also ask questions that relate to why they took a certain career or coding path at a pivotal point, what do they value in life and professionally, and if there was a moment in which they disagreed with an approach to things or even with a boss, and how they acted upon that?

Mavericks: Great engineers are independent thinkers and figure things out.

Quite a few of the best engineers that I’ve interviewed, especially those with more startup backgrounds, seem to be very independent thinkers and have what I like to see as a ‘figure it out’ mindset. They are more focused on the objective than on the task, if they are set to achieve something, they figure out the way to get there. Being independent in thought and action is a vital attitude of engineers looking to join a startup. In the early days of companies, founders rarely know the way to get to a goal, as sometimes the goal or the product is not yet totally clear. You’re venturing into unexplored territories and pioneering new paths, usually with a totally different and new solution, so an engineer who is capable of and comfortable with working in these kinds of unshaped but intentional environments may be the best fit for a startup. Being independent doesn’t just happen naturally, even as some people may be more prone to such behavior. Rather, I’ve observed that the engineers who possess this quality have experienced circumstances that led them to develop self-sufficiency and resourcefulness.  Independent thinkers, usually develop projects or skills of their own, hold experience of working at unstructured environments, were handed big responsibilities early in their careers, and are capable of disagreeing with people up in the hierarchies.  If you want to hire an independent thinker, look for their desire to do things. Some of these project-driven individuals are very active on GitHub, started their own projects in the past or can share personal websites to spot some personal projects. They may be avid learners  as well, and you could see them acquiring new skills for work or getting into things that are interesting to them. They are masters of their own growth. They are comfortable in unstructured environments, where they navigate the opportunity of solving problems and building structure instead of being stuck into chaos. This usually happens when they joined small companies or high-growth startups early in their careers, where everything was moving so fast and they had to catch-up. Some engineers can’t endure the chaos and leave fast, and some others learn to develop themselves through these experiences, and this is the kind of engineer that you’d like early on. Somebody who figures things out at a startup.  I saw this in an early engineer that I interviewed from Rappi, LatAm’s largest delivery startup. He suffered from what I’d call the cage of immobility after being in a place that allowed him to move fast and break things. He started his career as a NodeJS backend engineer in the delivery startup, he proposed migrating the Search Engine of Rappi from NodeJS to Golang, given the scale they were achieving and their performance issues. He didn’t know much about Golang but given his independent drive, he made it happen and grew this team to 30 people.  He later moved to GoDaddy as a remote engineer, he was stuck and bored, they didn’t allow him to do anything new. Later lobbied for his coming back to Rappi and built again something from scratch. This time their dynamic Search Suggester, improving the experience of the search engine, and winning the Golden Mustache, the most important recognition of contribution for any engineer at Rappi. I always remember his story when thinking of independent and ruthless engineers, because he is the kind of engineer that criticizes stuff, proposes new things and goes to build it. Even if he doesn’t know, he’d go and learn how to do it. When trying to spot this kind of engineer, ask for stuff that they realized didn’t work and what they did about it, try to see if they allow the status quo or if they go and break things. Another commonality I encountered from ‘figure it out’ engineers, is that some of them developed the capacity of independent action,  when very quickly into the job their bosses resigned and they had to take over the product and the code without much guidance. They were forced to grow fast and they lost the fear of leading and being at the forefront of problem solving.  Becoming independent may be part of a mix of circumstances. Many engineers that exhibit this quality have worked at places with few resources and figuring things out became a necessity. This is especially true in engineers that worked at bootstrapped startups in places like LatAm. 

Missionaries: Great engineers move fast and follow the north star.

Probably one of the most relevant characteristics of an early startup engineer is how aligned they are with the mission of the company and how seriously they take achieving such a mission.  Finding people who put a purpose greater than themselves over their own personal or professional interest is hard. One’s company incentives to achieve this matter, such as a good salary or equity, but at the end there are some people who truly find joy in building something exceptional and achieving a goal.  I mostly found this skill in engineers who worked at early stage startups alongside founders or who expressed that someday they want to be founders themselves. Many times I realized that an engineer was a mission-driven person, by the way they talked about the products they’ve built, referring to them as ‘my baby’ or ‘I built it from scratch’, rather than just a contribution. That sense of ownership, makes them feel that the product is their own and they were pivotal to its creation and success.  Mission-driven engineers have a sense of urgency, they move fast. Many times I realized from the beginning that an engineer has this quality since I reached out to them. I tasted their sense of urgency by asking to have a screening interview the next day and many times they replied the same night. After all, if a person is open to talking to a recruiter and changing jobs for a better opportunity, moving fast makes a lot of sense.  This attitude usually extrapolated to the sense of urgency they displayed during the interview with the stories they shared of how they quickly solved a problem, built a feature or jumped into an internal challenge. Speed is very important in startups, and moving fast from the first interaction is a sign of a great engineer. Engineers who possess a sense of urgency are also great at helping startups move fast. We know how important it is for startups to pivot and to do that a startup needs an engineer who is not so emotionally attached to a solution, but with a sense of urgency to solve a problem.  Discovering the way is already progress, even if it means starting again. Engineers who move fast tend to avoid the anchor bias, they don’t rely or anchor on their previous effort or solution. I specially saw this in engineers who worked at very early stage startups, some of them who left because of that chaos and some of them who stayed and enjoyed this process. The latter ones were the start-up engineers. Engineers who are comfortable with pivoting usually have past experiences of switching careers, worked for small and scrappy businesses, started their own things in the past or have a track record of creating many features for a high-growth business. They understand that progress is not necessarily linear.  I remember talking to one of the first engineers at Yalo, one of the earliest AI Conversational startups in LatAm. He went from being a founding engineer to be one of the engineering leaders when the company had over 250 people. What impressed me is that he entered as a junior engineer and developed himself inside the company all the way to a senior and architect.  He was comfortable going through two pivots and migrating the monolith that he did early on to a microservices architecture. What I found about him is that he was the kind of person who didn’t stick to an idea, follow the chaotic journey of first time founders and learn new things everyday. He wasn’t anchored to anything. That is a growth mindset. He later joined Zubale, one of the largest e-commerce infrastructure startups in LatAm and built a company technically again. So asking questions related to moments in which a person was flexible, detached and growth-oriented is a great predictor of a mission-driven person.  This understanding relates with their capacity to add value. They focus more on the goal, than on the task. Great and mission-driven engineers are valued-oriented people instead of task-oriented. They want to go the extra-mile to achieve the goal and realize the tangible value of their contributions. Many of the great engineers that I interviewed mentioned things like ‘’Nobody asked for this feature but I built it because I knew it was necessary’’ or an ex-rappi engineer mentioned that he ‘’built an algorithm that could handle 26k requests per minute and a backend that updated the price on 1 million products per hour’’. These kinds of details allow us to spot an engineer who focuses on value creation. Being a value-oriented person, makes you a customer-centric engineer. These are people that don’t do things just because of a job description, but because they realize that the ultimate beneficiary of their code is the user. We should ask questions of how one’s technical decisions have impacted the customer journey*. Great developers are customer oriented, they take decisions based on customer needs and understand how technical decisions affect customer journeys. 

Olympiads: Great engineers are highly competitive and prolific

Another way to spot a great start-up engineer is looking for his ability to perform under high-competitive environments and high-stress situations, as well as their capacity to produce a high amount of work. This usually happens when engineers have experienced a strong academic environment, worked for fast-growth companies or even participated in coding competitions or hackathons.  Prolific engineers make countless contributions. They are usually capable of contributing large amounts of code, building many features or repeatedly doing something many times as domain experts. I specially saw this in engineers where the nature of their income or work depends on being productive. For Shopify developers for example as the nature of their income depends on the number of shops or plug-ins they make, asking for a lot of examples on shops makes sense, or at high-growth startups where engineers are building product features everyday.  This happens with backend engineers who work for data or api-building companies too where the product lays on many integrations, apis and bots, such as identity verification or financial api startups.  So I try to ask for a lot of examples of their work during the interviews or things that they have done repeatedly.  When I interviewed one of the first backend engineers at Belvo, LatAm’s answer to Plaid, he mentioned that he’ve done over 2000 bots for web-scraping. If every bot is 30-50 lines of code, he’s written 60k-100k lines of code just on web scrapers, not even counting his high level work as a backend. That’s mastery. Great engineers are prolific and asking for a list of their contributions or the things that they’ve done the most reveal this trait and their strengths. Great engineers are very competitive. They want to make a large contribution to the team where they’re working, quickly upscale themselves through learning new things and possess a strong work ethic to be able to deliver their contributions fast. They find joy in contributing and being recognized for their impact.  Highly-competitive engineers find more joy in growing as a developer than in scaling up the ladder for a bureaucratic position, their ambitions are usually technical, excelling as a senior developer, as they know that great skill will take them far in the long run.  I recognized this trait when asking about what they look for in a job, which usually leads to a conversation of feeling technically challenged and being able to contribute without much bureaucracy. They value a fast paced and competitive culture. Non ambitious or lazy people would take advantage of a bureaucratic and slow-paced environment, but a highly competitive person would get bored, as fast-growth is their goal.  Another way to identify this trait when talking about their most challenging work experiences or the moments when they learned the most. Individuals who have experienced competitive environments will come up with experiences of computing in hackathons, global coding competitions when they were in college, or winning recognition for their contributions in companies where they worked at.  I specially encountered this trait in LatAm engineers who’ve worked at Rappi at some point in their careers. After interviewing many engineers at the company, almost every former employee talked about the high-competitive culture in the company and how it impacted their careers.  Ex-rappis were the kind of engineers that built robust systems in a short time, worked hard even at night and weekends, and found pride in being able to make important contributions to the company, they usually excel at working under pressure. This makes sense, as Rappi is one of the companies that has experienced more rapid growth, fundraising and upscaling in the region. What intrigued me the most was trying to understand why and how they would get so many hard working individuals. I came to the conclusion that this is based in a culture of rewarding exceptionality and in a natural selection process.  They reward exceptionality through prizes as the black mustache, great contributors gain status and are handed challenging projects and promotions. On the other hand, in the early days of Rappi, each engineer was asked to name the smartest people they knew in college or at former jobs, this happened during on-boarding. Great strategies to promote exceptional performance and hiring. This relates to the last insight I found of highly competitive engineers. They are vetted by their peers. Most of the engineers that performed well in competitive environments and were crucial in their projects, were invited by their bosses to other projects, usually internally and outside of the company. If an engineer was directly invited by a person who worked with them day and night for years to join an important endeavor, it usually signals their quality. I saw this a lot in what is called the Rappi Mafia in LatAm, technical leaders who founded startups that invited some of their former collaborators to join them as founding engineers. I also realized this when somebody told me that they were invited to come back to a company after a year or two of leaving. Discovering that an engineer is vetted by their peers really signals their worth, and probably the best way to spot this, is asking questions of how they landed their more relevant jobs.

Strategists: Great engineers are big picture thinkers and predictors. 

The best engineers that I’ve interviewed, always referred to this skill of thinking systematically as probably the most important factor that made them into senior engineers.  Being able to see a problem in the first place as something that can be broken into parts is crucial. Great engineers develop a capacity to see a system as a big picture, its fundamental components and structure the code in the right way to solve problems easier or even anticipate them. They operate a systemic approach to problem solving. After talking to many engineers that worked at fast-scaling companies, there was a name that came up many times – the CTO of ADDI – the Buy Now, Pay Later startup of the region. He repeatedly came up in conversations about architecture, system design and big picture thinking for building a codebase that will be able to scale with the business interests at core, and a technical leader that could develop engineers to do so.  Many of the early engineers at ADDI came from Rappi, with a ‘move fast and break things’ ethos, but that wasn’t the case at ADDI. Since their early days, they decided to build the code of the company in a way that was modular, aligned with the business goals, and being able to scale fast.  Every ADDI engineer had to read the book Domain Driven Design and was quickly immersed into a culture of being event-driven and business-oriented in the code. They learned to master it but they looked for engineers who were strategic and big picture thinkers. That made me realize the qualities of a strategic engineer. Strategic engineers are structured. In ADDI for example, their architecture revolves around microservices for each business unit and modeled after the customer journey, which allows them to scale and keep organized in the problems they have to face.  A structured engineer is also somebody who thinks on categories, organizes their learning from first principles to branches, organizes their do-to list from casual problems to details. If a person is well organized in their thinking, they will be able to read and write documentation at work, their code will be clear and well aligned, and their work will be able to scale across the company.  Ask questions related to their methods for learning, working and their step by step approach to problems; or more directly how they organize their code and document work, to spot them.  Hiring strategic minds will bring structure into the messy startup process. People will operate with an organized sense of urgency; as opposed to a disorganized sense of urgency – which is to do things last minute because you didn't plan things you could have planned vs. organized sense of urgency – you do things last minute and urgently because you had to, something unexpected happened and you had to do it, and you do it gladly because you know where to attack and as it is your responsibility to solve the problem, not because the system is a mess. Strategic engineers are first principle thinkers. I find it provocative when an engineer answers ‘I’m language agnostic’ to the questions of what’s your techstack. It is very abstract, but it brings an inner attitude of thinking first on the problem rather than on a predetermined solution. First principle engineers tend to focus first on the challenge at hand, break it into parts, and then decide the tools to tackle the problem. A great example of this across many engineers was their approach to data. Many senior engineers told me that they used to try to solve every problem using a lot of code, while many times it was just a data problem, improving the database was the actual need and they learned it the hard way. First principle engineers are data-oriented. If they’re inexperienced, they are inquisitive enough to discover the right approach to problems.  First-principle thinking isn't just related to data itself, but the way an engineer organizes solutions.  One of the best frontend engineers I interviewed, shared with me how in the early days of the micro frontends paradigm, a modularity approach to frontends, product managers at Rappi wanted to create a micro frontend for every little detail, a button or small pop-up. Everything was a small project.  He shared how it was costly, bureaucratic and time-consuming. Unnecessary at its core. First principle engineers know the limits of good practices like modularity. They think from first principles how something can be solved in its right proportions.  Great engineers cook pizzas, not spaghettis.  Scaling platforms with large amounts of data is challenging – ask questions related to how much data did your platform operate on, how fast was growing the company you were working at, and how did you manage the new incoming data, how did you migrate to a data intense platform,  what did you learn along the way. Especially in the times of artificial intelligence, platforms are bringing a lot of data from different sources, and it starts compounding, so having an engineer that faces these challenges is very important. Learning how to process data, having better design patterns. From the frontend to the backend is crucial.*** Strategic engineers are good predictors. They have a capacity to predict external or adjacent factors to a problem. They see the big picture in a large timeline and in a network dynamic. Relating to the first principle thinking, I interviewed the lead backend of the largest YC-backed investing app in LatAm, he shared with me how he decided to use Rust for their Core as they knew as their app scaled given the number of users, brokers and shares supported, combined a the large flow of data in the change in the prices of shares and other factors.  As he knew it was the best technology for the core and the company,  he also knew that they were going to struggle finding engineers with that skill, so they built all their microservices using Python. So at the same time of thinking on the right tool to approach a problem of scalability, a strategic engineer would also anticipate other factors such as the talent availability.  To spot a forecasting engineer, ask questions of what past challenges have gone wrong that they didn’t anticipate and what moments they anticipated that nobody else would have thought of. There may be interesting answers. – Finding a great engineer is not an easy task, but depending on what you’re looking for, the best startup engineers are determined, resourceful, competitive and mission-driven. Having deep conversations is a great way to spot them, as the most passionate people are deep and proactive. Don't strive to find the perfect engineer. Look for somebody who has qualities that you value and you admire. When you find somebody that resonates with your vibe as a founder and as a company that is probably one of the best signals you can get.   Great start-up engineers come from anywhere, what matters the most is their desire to work hard, learn the best practices and build something exceptional.