Share this post
I get approached daily and weekly by people wanting to hire me, on LinkedIn, email, and through various other means.
I really don’t mind it, and while I’ve been in software for quiet a while now, and I’m not claiming to be an expert on anything, I do believe I understand the engineer / geek mindset and, having successfully hired many people and been hired many times, I think there are a few key elements and success factors to hiring engineers that so many companies and people miss completely. I’m writing this post in the hopes of helping others improve their hiring process for the good of all of us out there. 🙂
The Wrong Cold Call Email
Personally I don’t mind getting cold call emails / messages. Everyone is doing their job and that is actually good! However, I know many people that hate this. I think the main problem here is that people don’t invest much time when they’re about to send an email to someone they do not know. Before you contact anyone you don’t know, spend some time making sure you understand why you’re contacting them. Here are two examples of horrible methods that will rarely get a response from anyone and if anything, might even get you tagged as spam and blocked:
It’s fine that you have a template part, many times your message has some core information that doesn’t change, so leave that in. But show the other person you know why you’re contacting them. These guys didn’t even bother, they are probably sending emails to everyone. The first person was impressed by my LinkedIn profile, which is great, but do I really believe her? What is she impressed by? My background, my Ember skills or my pretty blue eyes (they are really brown)? You get the picture. I had no doubt she didn’t even read my profile or find anything impressive on it – she is machine gun emailing. And the second guy was doing so much copy and pasting he missed getting my name in the template right. However, it’s also not always this clear. Sometimes I get emailed with a lengthy one or two paragraphs talking about who they are and what their companies is, etc, etc. Why do I care? Why does anyone at all care about that?
The Right Cold Call Email – 80%+ Response
If you’re going to address anyone, not just in regards to hiring but any cold call email, you need to spend time and construct it properly:
- Pre-approach – This will take you some time. Use Google, LinkedIn, Facebook, and research the person you’re contacting. Look for their personal site. Read about the companies they’ve worked for. Try to get a mental image of who they are before you contact. Make sure you actually do want to contact that person, and that he is the right person you should be talking to! Don’t just copy and paste stuff. Spend time in what is called the pre-apparoch. It will pay dividends, ensure you’re actually contacting someone you want to talk to, and will show the other person you care about them. In the same way you’re asking them to invest time, you’re investing time too!
- The opening paragraph – I always open my emails with highly personalized content. But not just any content – I try to find the reason and the basis to try to reach out to the other person on a personal basis! I try and connect on a personal and professional level. I try to understand the mindset and why what I’m offering suits their mindset and persona. For example, if I see someone that is an Ember fan I would talk about why I think Ember is great and why I’d love to contact them. If I’m looking to hire a developer I look at their Github and their stack overflow and see what they have been doing, do a little code review for them, and only then address them: “I checked out your Github, and I loved your angular auto-complete directive.” I always close this paragraph with a clear indication of why I’m contacting them. People have little time, so be precise and direct. People will breeze through your email / message. If they understand what you want – great! If they feel it’s spam they will mentally tag it and will not continue to read, but press delete instead.
- The info paragraph – This is where you are allowed to provide copy and paste info. If you’re looking for work, write about your background, provide links etc. If you’re looking to hire, explain about yourself, your company and what you’re looking for. If you’re looking for customers explain what you can provide, what other customers you’ve worked with, etc. Include links and information but try to keep it short and sweet. Too lengthy becomes lecture-like, and people don’t like that, they tend to skip it as spam.
- End with why now and a call to action – I like to end these emails explaining why I’d like to contact them now (currently hiring, just finished a job and looking for a new things, currently in two for two weeks, etc). Don’t make this generic, explain why the time-frame is real, it creates urgency and authenticity. Again don’t make this up, really explain why!
- Language – Long gone are the days of writing fancy emails with fancy language. They super quickly sound too hyped up and too pretentious. I’ve been using a tip I got from one of my co-founders. Think like you’ve having a normal conversation with a friend over a beer or lunch and write your email in the same language. Be modest and confident, stick to facts and talk on eye level. These tend to make people feel like they’ve received an email from a human and not an email sending machine. However, please do be passionate and alive, explain why and show that you care. People tend to respond to that. They see and read your effort and tend to appreciate your energy.
- Follow ups – If after 3-5 days you get no response, feel free to send a quick 2-3 lines follow up email. If that doesn’t work try again after 3-5 days. Most of the time people have either gotten it in a spam folder, or just have been too busy with other things, don’t take it personally. And if still no response, just let it go, you probably don’t want to do business with them anyhow, as they aren’t really mindful of you or your time. 😉
The Next Step – Initial Call
After you do get some interest to your email, I suggest you setup an initial call. This should be an intro call with someone that has some technical knowledge. Do not send out a test task right away! You want to get to understand the other person better, you do not want to put them off.
During this call, let them talk about themselves, what are they doing, who they are, what they want to do. Ask open ended questions and listen. It’s the first time they are talking to you, so let them feel at ease. Get a sense for who they are, only after that should you spend a little time talking about you, your company and what you’re looking for. After about 30 min introduction try to do 30-45 min of tech phone interview, just to make sure the person you’re interviewing does understand the basics.
The Joel on Software blog describes this call very well. Try to get in a few questions. Ask to describe some algorithms. Talk about the technology the person uses, and try to probe. If you don’t know the tech the candidate uses, try to get someone else on the call to probe about it. It’s not critical that the person has or doesn’t have the right tech fit, it’s important that he really understands the tech stack that he uses. If it’s JavaScript he should understand why == is not the same as === or what is prototypical inheritance and explain about certain gotchya’s! Feel free to also ask them to do something simple like write a function that reverses a string, etc.
You can also ask them what’s the different between pass by value and pass by reference. I really like to say something that is totally wrong and see how they respond: in C++ you cannot pass by reference. It shows how they respond to conflict. Try to get a sense of whether they do understand the tools they use and the basics of software. If this goes well, setup an in-person interview. If not, move on. So many times you’ll find that candidates that seem like they are amazing end up being total duds and vice versa. So try to get this right, the person on the other end will appreciate you for it too! Also it’s a good time to ask about salary expectations etc, to make sure you’re on the same page, or you can wait until after the interview / test task. This depends if you have a set budget or not, or if you don’t mind paying the market rates or not.
The In-Person Interview
The interview is a stressful time for most candidates – they want to impress but it’s not the natural environment for most of them. So start again but having some casual conversation. Try to find a quiet location and try to make the other person feel comfortable. It’s not about stressing them, they are probably doing that job very well by themselves. It’s about making them feel as natural as possible so they can really perform at their best and so you can understand what their best is!
This shouldn’t be a one sided discussion or an informal chat, you should have an agenda. Talk through, look at their body language and listen. They should be talking as much as you are talking. Ask them about their work history. About projects that didn’t work, about conflicts and how they resolved them. Get a sense for what their everyday job looks like. If they manage people, how do they deal with failures? What is their outlook on failures? etc. Be sure to tell them about yourself and about your company and role.
Then you should get into the technical side of the interview. Do not ask questions with a light bulb moment! You might love them and think they are clever, but they prove nothing to be honest, except that the person can solve your riddle. It is the same with complex algorithm challenges with one solution. Again they provide you with very little insight into how good that person will be as an engineer, and that’s the goal right? To find someone intelligent that can deliver results! So good questions are:
- Ask them to complete a simple code exercise, not too trivial but not too complex. Chances are that the other person won’t write optimal code and it might contain bugs. This is a great chance. Tell the person he has bugs and wait to see if he finds them and fixes them. Look to see if they didn’t write code to handle invalid input. They should ask you about it, or if not, they should notice that. Then ask them to optimize their code. Many times the code they write isn’t dry or optimal. Iterating together will show you a lot about the way that person handles not only code, but also do they persevere or do they give up? You want people that don’t give up! This is a great test for anyone you work with!
- Ask them to design a system. Any OO design question would be good here (Deck of Cards, Elevator System, Etc). These are good questions as they show how that person approaches development design, how they architect and how they think in terms of Objects. Again, this is a good question as you can ask them why they did it this way or that way and gain insight into their thinking.
- Then I always try and find some challenging task I had and give it to the candidates. Something I have already solved but thought it was complex to solve myself. This is another great example, as I’ve had people solve a complex problem faster than I did! They aren’t suppose to come up with a complete solution, just with the concept behind it, and maybe explain how it would work. This is very insightful!
I try to wrap up the inteview by thanking that person and tell them I’ll be in touch. Try to send out emails to everyone that interviewed with you showing that you value them and their time, and that you respect them regardless of what the outcome might be.
The Test Task
This is something that is so misused in my mind. On one hand it’s a great indicator and way to learn how it is to work with someone. You can see if they understand instructions and how it would be to work with them, but so many companies abuse this. Never send out a test task right away, it shows you don’t really care about the other person or even value their time. I’ve done a few test tasks, some as first point of contact. And while many did like my work, I never ended up taking work with companies that do this.
The proper way to do a test task is as the last step, to see how it would really be to work with that person. I like to find some block I really need, and to give that to the other person as a paid task! Yes, paid. Many times engineers will even agree to do it for free, but always offer a paid task. Just as you wouldn’t go to the doctor and ask for a free checkup, just to make sure he is the right doctor, don’t expect a good engineer to work for free, they have too many options. But with a paid task, I can see that the other people value my time and respect me, and I also do these very gladly. Yes there is a risk that the other person will write crappy code, but it’s better to pay a few wrong people than hire the wrong person. It shows me people are motivated to complete the task and it’s a great way to mini-test your working relationship.
Final Notes
I find that following these steps makes people feel at ease not only with leaving a current position and moving to work for you, but also for you. It ensures you find great candidates and hire only the best people that mesh well with you and your team. It’s not rocket science but it is a craft, and so many companies have such bad hiring processes that it frustrates the people they are trying to hire. So even if you don’t follow my suggested steps, please be mindful of the other person, show you respect for their time and try to treat them the same way you’d like to be treated!
Cheers
D.
