I’ve been teaching computer engineering at the University for 16 years now; in the meantime, I developed an eagle eye to identify in the first 4 weeks of class which students definitely are going to pass the course, no matter what are going to be their projects. It is possible because they show in early stages what I called the click
The click, is a particular ability and abstraction which gives people the capability to easily and accurate understand how tech logic works. With that capability the person is able to adapt himself to different technologies, programming languages, platforms, services and more; additionally, they can use this capability to design simple and scalable solutions, solving the current problem and designing for future requirements at the same time.
What are you looking for?
If you’re interested in finding developers with high skills on specific programming languages, techniques and certainty among of years of experience, you can keep using your common interviews and recruiting process for IT people. Nonetheless if you’re looking for engineers to solve a wide spread of problems, design scalable solutions, implement solid architects, research and produces business changes then consider the following filters:
- Ask cases: a satisfactorily good engineer with at least 2 years of experience must be able to draw on a whiteboard a technical architect/solution within 2 to 3 minutes, based on a case. Likewise, they will be able to add one or two variations of that solution in the next 5 minutes. Your CTO/Engineers must be there in order to corroborate the sense of the solution.
- Algorithms: do not ask for programming languages or development tools. Focus on giving them specific processing problems with several solutions, previously figure out with the CTO/Engineers some solutions, involving simplicity and scalability, in five minutes a couple of good solutions should show up.
- Integration case: ask how to manage an integration case between two large systems; good engineers tend to think and design in their mind a built up strategy. It means is going to cover aspects like planning, management, infrastructure, design, testing phases, reusable technologies and other factors required to build the solution. A bad engineer is going to talk just about involved programming languages and tools.
- Socialize: Suddenly expose the person to your crew in the middle of a problem solving session. It can be a simulated situation. Let your team start talking about the problem, looking to solve the big issues, then monitor reactions. A respectable engineer will find out the way to express ideas. Remember you’re going to pay at least $130K a year for a decent engineer. The candidate must be a leader and a front-runner, they must be able to face many kinds of people in emerging situations.
- Code: Do live coding exercises, for a simple algorithm. Watching a software engineer is great, because the unproductive ones are going to code immediately, erase and write small steps like a baby. The respectable chief is going to take time to think and design; taking in consideration several scenarios before start coding.
- Non-sense: check his major tech skills, then tell him a story about doing a non-sense affirmation over the topics where the person has abilities; monitors his expressions, how he manages disagreement. It’s much better if he tries to clarify; a good engineer doesn’t have afraid of.
- Non- stuck: a good engineer does not stay in the same technology for more than two years. Even if we’re talking about large platforms his CV must reflect how he moves between areas, modules, subcomponents, satellite services, and tackles around the platform; a good one dislikes continually doing the same thing for more than a year.
- Recruiting service: do not rely only on your recruiting firm or RRHH department. At the end this person is going to work with you and with your team, must fit in and show empathy.
- I’m: the inferior individual is going to tell stories about all known technologies and all his achievements. An exceptional individual is going to talk about the problems solved in each technology and how he and his team obtained the results.
- In the blood: a respectable engineer will find this article so obvious; a flawed one can read this before the interview ending with inadequately flawed answers.