Areas To Evaluate When Hiring An Engineer
When hiring a software engineer, evaluate the following areas:
Growth potential: This is a critical factor many interviews ignore. They evaluate a snapshot of a person as is he today. But people are dynamic, not static. You want to make a decision based on where he’ll be 1-2 years from now, not where he is today. And you want people who can pick up the skills needed to solve novel problems thrown at them, as is likely in many jobs.
Skill in a specific area like frontend, mobile, backend, ML, etc 1 that’s relevant to your startup.
Coding skills: Evaluating coding skills is important since some people talk impressively but can’t code. Give the candidate a take-home assignment to evaluate coding skills.
Design skills: I point candidates to my former startup Futurecam’s web site and ask them to spend five minutes looking through it and playing with the sliders. Then I ask them how they’d build this app. Unless you have a background in image-processing, both conceptually and in mapping algorithms to use cases, this is a hard problem. If you’d gone back in time to before I started the startup, showed me the site, and told me I’ll build this, I’d be amazed. And intimidated, because it’s far outside my capabilities before I began. You want to ask such a question because you want to see if the candidate can identify high-level architectural considerations without needing to know the specifics. For example, one candidate told me, “The image processing will happen on the server, and the app needs a high-bandwidth Internet connection to upload video live. Using the camera, screen, sensors and high bandwidth simultaneously will drain the battery. This means that the app should check the battery level before beginning and warn the user if it’s below a threshold. If it runs out of battery midway, the app should have the ability to resume. Since the server-side processing will be demanding, users’ requests may be queued up and we need a UX where we tell them to come back in an hour and check the results. We can trade off server costs for user experience by under-provisioning our servers, in which case users will have to wait longer.” See how he was able to identify broad factors and chase down their implications across multiple areas like hardware, client, server, user experience and cost? This also checks his attitude: does he give up even before beginning by saying “I don’t even know where to begin?” Or does he make assumptions and abstract out certain parts, such as by saying that creating a light trail logically consists of three parts: capturing a video, determining which path a car is taking, and painting light in that path, assuming an algorithm for each, and building the rest of the solution from these building blocks. Some of the specifics may be wrong, and you should check not whether the answer is right but whether the approach is reasonable for someone without experience in the domain.
HR aspects like the person’s expectations from the job, his career goals, what kind of company is right for him, willingness to work on whatever turns out to be required, is he coming to us for the right reasons, and so on.
QA skills like various ways of testing (unit tests, end-to-end tests), mocking, assertions, knowing when to use each of these techniques, and team practices like code reviews to increase quality. Evaluate QA skills only for some roles: QA engineers, DevOps engineers (who manage releases) and engineering leads.
Engineering leadership: This checks whether the candidate can work as a Staff Engineer. Applicable only for some roles, obviously.
If someone has a skill in an area that’s critical for your startup, hire him even if you don’t need such a person now. For example, if you’re looking for a frontend engineer, and you come across a great backend engineer, hire him even if you aren’t looking out for backend engineers. Some work will appear soon that will use the new engineer’s backend skills. People generally underestimate the amount of manpower they need.