They myth of the 10x engineer and what we’re getting wrong.
The concept of a 10x engineer has become ubiquitous with the rise of start up vernacular. A legendary being as elusive as the Lochness monster with the deductive reasoning of a tenured professor, the work ethic of an olympic level athlete, and the diplomacy of a hostage negotiator. Where do these individuals come from and what makes them so sought after? Everyone will have their own definition of what they believe a 10x engineer provides, but in this article I will make a case for the idea that they provide a lot less than you expect; they provide simplicity.
One of my favourite articles on the idea of simplicity in software development is modelled by this very easy to interpret journey of the 10 year developer: https://medium.com/@webseanhickey/the-evolution-of-a-software-engineer-db85468924 (highly recommend clicking the link, it is very visual and a 1 min read) .The TL;DR is that as you progress through your career you grow through an increasing insecurity that complexity means sophisticated. You imagine complex code does a lot of things, its probably covering errors you can’t imagine, it must have the cleanest abstractions, and it must be enduring. You inevitably strive to write the same complex abstraction rich code. What the article demonstrates is that inevitably, once you reach the peak of complexity mountain, you realize, simple got you just as far and when it didn’t, it was easier to change.
The best engineers write less code when appropriate, they make sure its easier to read, they keep it easy to understand and find things, they solve the tough problems in simple ways that even junior engineers can understand. Their code looks boring, it’s plain, and that’s what makes it so good. Very often when evaluating engineers, they are given tests to demonstrate their ability to solve complex problems that they almost never do in their day to day job. We ask candidates to white board abstract problems like dropping magical eggs from floors, optimal search solutions, or program the Fibonacci sequence (which for engineers actually isn’t that hard). We should be asking them to solve simple problems looking at the decisions they make; how are they naming functions, how are they organizing their files, what types of patterns do they use?
On top of all the regular criteria your team is using to seek out top candidates, here are some non conventional assessments you can also consider adding to your interview process.
- Do they know their history
OOP, functional programming, micro services, monoliths, composition, inheritance, piping, procedures, orchestration, REST, SOAP. Understanding not just what these concepts are but their history and the problems they were addressing often acts as guides to solving the problems your team faces today. Consider asking candidates what they feel has been the most impactful contribution to modern app development? If you asked me I would say something as simple as the introduction of the JSON specification by Douglas Crockford had a more profound impact on modern programming than likely was anticipated at the time (and I would be happy to elaborate why, but not here).
- End to End Knowledge
All applications need to manage data and state at some point. For example, the better designed your database is, the simpler your code base tends to be. A thoughtful database is designed in a way that thinks about how your API’s and the clients of those API’s will interact with that data. So being able to design a system from the perspective of where data originates and where it is consumed is helpful in reducing the amount of code that needs to be written. Consider evaluating your engineers by asking them to build a simple app that requires some end to end design. One of my favourite asks of candidates is to build an app that uses the Pokemon api to infinite scroll a list of Pokemon. I don’t set a list of requirements I encourage them to over engineer (within reason) as a means of demonstrating the depth of their skill. That’s whats great about a simple challenge like this, it allows the candidate to show you the depth of their knowledge because this app can be done in 10 lines of code, or thousands if built to reflect how a production application handles an infinite client side list from an api. When evaluating their response keep in my mind the journey of the 10 year developer. You can solve this problem with docker, an api, react + redux, and Postgres and it can still look simpler than some candidates front end only solutions.
- Ask them to teach you something you don’t know
One of the hardest parts of hiring engineers when you are a non technical founder or early in your own engineering journey is knowing what you don’t know. As a founder you will not always know what you need to know when you set out to build your products and you will need to not just trust your team in guiding you correctly but also to provide you with the information you need to make effective decisions. To truly know a concept inside and out is the only way to teach it effectively. The best teachers can explain concepts in many ways such that someone relatively new to the information can interpret it effectively. I regularly do this by making analogies to tech with regard to another technology they individual already understands or a concept in their discipline they are already familiar with. Consider asking them teach you the difference between the following three writing patterns and when you would consider applying them to a design solution; MVC, Backend for Frontend, and Repository Pattern. Or, ask them to explain to how you would consider incorporating domain driven design in your micro service refactor?
Top talent in any field is comprised of non conventional individuals, therefore finding them requires some non conventional simple assessments. Remember, simplicity is inherently complicated to achieve.