How do you hire great engineers? The secret to hiring great engineers. Tips from a complete beginner at these things.

The question on everyone’s lips (everyone being a very specific subset of people whose work at their companies involves hiring people for engineering teams) is “how do you hire great engineers?”

To answer this question, we’d have to break it down into its parts and understand each of them.

How do you hire?

I’ve lumped these four words together because they’re pretty basic, no two ways about them. Anyone who does HR for a living should, I believe, understand and have a somewhat working solution to this question.

What is a great engineer?

I’m an engineer. I think. I’ve built websites and apps and things. I studied I.T. Does that make me an engineer? What is an engineer anyway? Let’s ask Google what it thinks:

Excellent! I was worried it might say something like: “a person who possesses qualifications in maths and science and has an IQ above 140”. Google’s definition pleases me. It validates my calling myself an engineer. In fact, if I reword “I coded a website” into “I designed, built and maintained an online digital request parser and multimedia data delivery engine”, you could say I fit Google’s definition perfectly. What does Bing say?

Bing gives us a third definition of the noun, which isn’t really something we can use here. Also, it almost looks like Bing uses Google and adds a little extra on top (I also stumbled upon this article that says Bing might be a good replacement for your searches).

How about Yahoo!? What does Yahoo! say? Does anyone even use Yahoo! anymore? Does Yahoo! even use the ! in their name anymore? Let’s ask this old timer what he thinks an engineer is:

Wai u liek dis, Yahoo!? I suppose if you were a billion dollar company in some distant internet bubble fuelled past, engineers probably were just that to you, people who did whatever work it was you paid them for.

But that was then. Millennials would probably balk at your thought of them as mere cogs in a machine of your design. They want ownership! They want autonomy! They want to be part of something bigger!

Ignoring what Yahoo! thinks an engineer should be, we can easily extrapolate from Google and Bing’s response that a good engineer should be one who is good at this designing, building and maintaining of things, which implies that she is proficient with her tools, understands the principles and best practices in her field, and cares enough about her work to maintain it after it has been built.

Excellent! This kind of stuff should be easily ascertained of an interviewee via her work. Her sample work and code (and she really should have some code to show, otherwise we’d have to just take her at her word that she writes good code — only to later find out that her definition of good isn’t exactly the same as ours) should speak volumes, and her explanation of it and how she came about it should reveal if she is indeed a good engineer.

Generally companies tend to suss this out early on in the process; usually in the step right after filtering out resumes. Typically this is done in the form of a technical assessment/quiz or a technical phone/video interview.

But what makes a great engineer? Engineeringschools.com and topengineer.com seem to roughly agree on the criteria involved. If you took a look at either of these lists, you’d find that a fair number of the criterions on them are either not really technical related or are hard to determine purely from inspecting someone’s work:

• Good communicator
• Creative
• Team player
• A problem solver
• Committed to continuously learning and improving

That’s already like half the list. If you said “but his code shows that he solved a problem!”, then I say someone else could have “solved the problem” and then just told this guy what to build. If you’re not solving engineering problems and just need a code monkey to build your stuff, this guy might be just who you’re looking for.

You also don’t want some eccentric super-genius-programmer who writes esoteric code that only he understands. Never mind that it runs now and that it works seamlessly with your Amazon Cloud Whatever set up, what if we need to fix it one day and he’s not around? How in the world is anyone else going to understand the code he wrote in Whitespace.

From what we’ve learnt so far, we know we’re looking for someone who is a good communicator, is creative, is a team player, is a problem solver and is committed to continuously learning and improving.

What you’re looking for is a Software Engineer. Someone who understands big picture stuff. Someone who can architect a solution from his broad experience of technology. Someone who isn’t afraid to learn new technologies if the solution so requires. Someone who can then communicate the solution and technologies involved to their teammates, and teach them how to implement it. Someone who first thinks about the problem to see if it can be solved without writing a single line of code by simply reimplementing solutions for other similar problems. You know, NOT reinventing the wheel (plenty of programmers easily fall into the “Not Invented Here” mindset and find themselves in a heap load of trouble trying to rebuild something that someone else took years to research and develop).

All of these things are not “Engineering” issues, they’re “People” issues. So we’ve adopted an interesting stance in hiring engineers by focusing on hiring good people. Sure we expect a certain level of expertise and knowledge in your field based on your level of experience, but what we’re really into is finding out if you’re the type of person we’d like to work with. Will you be the type of person we can have engaging and fruitful conversations with regarding the technologies we use and improving them? Are you someone who isn’t afraid of picking up a new language to mess around with it, just to see what it can do or how it works? Would you be able to then teach us what you learned, so that we too can improve?

So how do you go about finding good people? You talk to them. Get to know them. You give them the opportunity to put their best foot forward by providing them a comfortable, friendly environment where we’re all just trying to be the best we can. We try as best as we can to not make it some kind of interrogation, and instead try to guide the interview into a kind of discussion, open to input and questioning from both interviewee and interviewer.

Of course, we also have a technical portion to the interview, and that involves a 1 week “homework” assignment, that is meant to test a candidate’s ability to learn, develop and teach, all in one fell stroke. What we do is we get applicants to build a small, non-trivial app in a language she is unfamiliar with, and to then get her to walk us through it and teach us what she learnt about the language during the on-site interview.

This way, we get to see not just your ability to code but also find out how your mind works: your though process of coming to a solution, your ability to pickup new concepts and apply them, your ability to communicate this solution to others.

So what is the secret to hiring great engineers? Hire good people.

In another post, we might just explore HOW we go about this hiring process of ours to get good people(we’re still kinda working on it. Pei Yee Teh and Joey Cheng both feel strongly about amping up the technical proficiency testing to ensure we get real quality engineers, and Mohannad Saraiji and Berdikhan Satenov both feel our “take home assignment” is highly biased against mobile developers, so it’s not like we’ve got this stuff written in stone or anything).