Job interviews. Yuck. No one likes them (especially not the people conducting the interviews). Both sides of the transaction are looking for quick resolutions to a sometimes overly long and stressful process. The interviewee is obviously looking for a job and a source of income. The hiring managers just want someone competent that can do the job without causing simultaneous collateral team damage. But the process is a necessary annoyance for the ultimate satisfaction of both parties. That’s why we’re spending some time today to discuss what we look for when hiring potential developer candidates.
Interviewing is stressful on both sides of the equation so it makes sense for it to be dreaded. Businesses only have a few hours with candidates to decide if that person will be a good for potentially years to come. How can a decision like that be made accurately? It probably can’t, but that doesn’t stop us from at least setting some bars for the candidate to reach. Since there’s really no way to predict if someone will be productive in the next six months or six years, we tend to focus on more conversational skills and lightly academic knowledge.
Let’s dig in.
Where does everyone start before doing something? By preparing. Sometimes it might feel like people didn’t prepare at all, but it’s impossible to be completely unprepared. At the very least, people schedule time to be at an appointment and get dressed. Sure, the scheduled time might be late and the clothes might be inappropriate, but there was some preparation involved.
Regardless, you don’t want to be that person. You want to be the person that shows up early, greets everyone appropriately, dresses for the occasion, has a clear understanding of the company’s mindset, has brushed up on at least some academic skills, and has brought necessary evidence and backup materials for your skill sets.
Show up early. This is a big one. Some people have this in them and some people don’t. You need to really work on being in the former category if you want to be seen as professional and serious. People are taking time out of their day to make room for your interview. If you show up late, you’re basically saying that you don’t care about the time of others and that the interview just isn’t that important to you. Don’t show up on time; show up early. Plan for delays in getting out the door, making it through traffic, finding the building, finding a parking spot, and making your way in to the office. All of these things can easily add up to huge delays if you aren’t careful.
Understand the company. Even if you’re applying for a job to get a steady paycheck, it pays to at least do minor research on the company. What are their main products? What do those products solve? What is the mission statement? How big is the company? Where are its main offices located? With the Internet as accessible as ever, it would benefit you to search around for the company’s web page and read through the highlights. This will give you something to answer when you are inevitably asked, “Why do you want to work here?”
Brush up on skills. Technical interviews have this annoying part where you’re expected to answer academic questions that you may not have visited in years. It’s easy to forget the fundamentals if you’ve been working a comfortable job for a long time in which you haven’t had to think about it. That’s why we suggest you, at the very least, briefly revisit basic programming skills. You should be able to discuss basic programming and computer science terminologies without sounding like you’re making it up as you go. But always remember, it’s not always bad to say, “I don’t know.” This is covered more in detail below.
Bring evidence. If you tell people that you actively contribute to open source products or main personal projects in your free time, you will need to be able to prove it through showing off something like a GitHub portfolio or being able to hold an in depth and confident discussion. If you’re a STEM student or an Information Technology graduate, you might not have enough work experience to pack into your portfolio. In that case, try to find some of your academic projects to commit or start up your personal projects in your free time.
During the interview process, we like to see how easy it is for a candidate to discuss technical and non-technical topics. Do they stumble over words or are they able to articulate clearly what they mean? Are the technical terms being used accurately or do they sound thrown in for no reason at all? If a person doesn’t know something, are they comfortable admitting that or does it sound like they are making up a sentence as it comes out of their mouth? Can they hold a conversation about their work experiences, their hobbies, and about what they’re interested? Does it sound forced, awkward, or annoying for them to have to discuss these topics?
As a software developer, it might not seem important to hold a conversation, especially if you’re the type of person that likes to put your headphones on and blast through a problem in silence. We understand that uninterrupted periods of deep thought are often necessary. But there are times that you’ll need to be able to discuss problems and solutions with your team. Even if you’re the most junior person on the team, your leadership will still expect some input. You can’t just sit back and wait to be told what to do.
Senior developers and developers in leadership aren’t always going to know the answers to problems. As a junior employee (or even if you’re another senior employee), you might have experience with specific technologies or algorithms that no one else in the company has. That experience could be critically valuable to the success of a project, but no one will know that you have that experience unless you’re able to communicate it!
Additionally, being part of a team inevitably leads to social and non-work related conversations at times. It’s beneficial to be able to read other’s verbal and physical language so that you’re not overbearing, upsetting, or ignoring their needs. We know, we know. Work should be for work, but trust us, you will be bombarded with conversations that have nothing to do with work because others are bored or need a break. Put on that conversational smile and make them feel good until you can escape. OK, so it’s usually not that bad, but the point is that being able to talk about non-technical topics is just as important as talking about code and computers.
Remember that this is just one of the categories we look at. We use this as one of the weights in the final determination of making a hire. Not everyone is good at holding conversations naturally. And we definitely understand that the stress and pressure of an interview can throw something out of their normal routine.
This is an extension of the conversational skills but applies more generally beyond conversations. The way in which you conduct yourself physically can be intimidating, compromising, inviting, or a mix of other emotions. People may feel more comfortable around you because you have a non-threatening posture. Some may feel threatened by your presence because you are dismissive or not making eye contact when having a deep discussion.
Here are just a few questions you should ask yourself:
- Are your hands clammy when you shake another person’s hand?
- Do you bounce your knee when you’re nervous?
- Do you sweat a lot under pressure?
- What do you look like when you’re explaining something?
- Do you gesticulate with your arms and hands?
- Do you make eye contact or do you stare at the ground?
The type of body language that you use while having a conversation can say a lot about you, your abilities, and your level of confidence in what you’re claiming. Here is some broad advice about how to handle some of the negative body languages.
Visibly nervous. Preparation helps with this one. If you’ve followed our advice in the preparation section, you’ll probably be less nervous during conversations because you’ll actually know what you’re talking about. Study the fundamentals, understand the company, and have some evidence to back you up. Your speech stutters, hand trembling, and nervousness will dissipate quickly.
Not making eye contact. This is important if you want to be taken seriously. Depending on where you’re looking while talking, people may feel as if you’re completely ignoring them, dismissing their questions, or even talking to someone else in the room entirely. When answering questions or asking questions of your own, make sure to look at the person directly. It’s OK to look elsewhere if you’re thinking about an answer, but when giving the answer, look at the person.
Shaking hands. We don’t mean trembling hands (see above for visible nervousness). Instead, we’re talking about greeting someone with a hand shake. In western cultures, it’s expected to be able to shake someone’s hand with “gusto.” Put a sense of purpose and confidence into your hand when you shake. You don’t have to crush someone’s hand, but you should at least firmly embrace your potentially future coworkers.
In all honesty, body language doesn’t factor greatly into the ultimate hiring decision for interviewers that look at someone objectively and holistically. However, you might run into people who weigh first impressions heavily. Your body language will most likely be the first thing another person notices about you (especially a hand shake). That’s why we want to stress the importance of preparation and practice to reduce your nervousness so that you can come across as more confident.
If you’re in school, fresh out of school with a brand-new diploma, self teaching yourself programming, or looking for ways to change your career path, one of the single best ways to get yourself noticed is through a portfolio of your work. Over time, through school assignments, coursework, and your own personal projects, you can amass a collection of projects to show off in your portfolio.
If the full process of becoming a software engineer is still foggy for you, go complete guide to becoming a software developer first. Then come back here and start building more personal projects on top of the ones suggested in that article. In fact, you should probably build more even if you have a lot of school assignments in your collection.
A big part of the satisfaction behind software development is the knowledge that you created something. Not only do you get something that you can call your own, but you also gain critical skills related to problem solving and thought experiments.
Hands on experience is almost always the best way to improve your skills. Academic knowledge can get you started, but having something physical (or in this case, digital) to touch, feel, and manipulate gives you real world experience and an eventual sense of accomplishment when you release your product to the world.
Academic projects. Remember all those weird programming assignments that you had to finish during your classes? Maybe you had to write a binary search algorithm or a basic version of a text-based poker game. You probably didn’t think you would ever need them again. Don’t throw away your previous work just because it was annoying and barely finished the night before it was due (apologies to any non-procrastinators out there).
Side projects. If you’re a self-starter trying to break into software development, the changes are likely that you’re actively writing code based on tutorials, guides, and experiments. Don’t trash these when you’re done with them! Commit them to a Git repo and push them to something like GitHub. These obviously won’t be glamorous pieces of software art that you’re trying to show off to the world. Instead, you’ll have at least proof of your dedication to learning on your own.
GitHub portfolio. Fortunately, using a platform like GitHub to build a portfolio is free, easy, and teaches you critical skills that you can apply for yourself and an eventual employer. Not only does a public portfolio give you some much-needed ammunition during an interviewing process, but it also gives you experience with tools that are used in the real world and just might get you noticed by others in the community. There’s literally no downside. You gain real world skills, help yourself during the job hunt, and have the potential to join teams in the open source world.
Between your personal projects, a GitHub portfolio, and a bit of confidence, you’ll have plenty to talk about and back up your claims during the interview process. Instead of just telling people you’ve contributed to an open source project, you’ll be able to reference an exact forked repository on GitHub with commits signed by you.
At last, we’ve come to the elephant in the room: your technical prowess. It’s notoriously difficult to determine how talented a developer is in a single day’s worth of interviews. We find that you don’t truly know someone’s potential until they’ve been on the job for 3 to 6 months. There’s an obvious problem there, though. The project and team doing the hiring needs people now and probably can’t afford to wait for an interview to be conducted over 3 months.
So we try to come up with various ways to sort-of-kind-of figure out who the best candidate is in a short period of time. This often involves brain teasers, interviews that last the entire day, complicated problem solving, and sometimes, unfortunately, “gotcha” questions that have you repeat sentences from a textbook you haven’t visited in years.
We try to be lenient when asking technical questions because we find it to be a lot like measuring blood pressure. People have different blood pressure readings at the doctor’s office because they are nervous. Similarly, people may perform poorly during an interview for the same reasons. Additionally, many people have “contextual” knowledge that is easier to recall when actively working on a problem rather than through a discussion. They may be highly productive with hands on the keyboard and digging in to a problem throughout the work day but may suffer during a compressed interview. Case in point: many people forget their personal passwords until the second they sit at a keyboard and start typing it in.
We’ve found the following broad categories to be the most popular styles of determining a candidate’s technical skills.
Puzzles and teasers. We consider these to be the least effective because they’re often irrelevant. Instead of focusing on answering “gotcha” puzzles that you might be asked, you should instead focus on being able to think critically and outside the box. This lets the interviewers know that you can 1) think deeply about a problem, 2) discuss that problem with others on a deep level, and 3) propose a solution to a problem even if it’s ultimately not the one they were expecting. We don’t ask puzzles in our interviews because we don’t believe a person’s ability to solve puzzles is a good way of finding a loyal and quality developer.
White boarding. This is the notoriously difficult part of technical interviewers. People start to panic once the interviewer hands them a white board marker. When we ask white board questions to candidates (and most of the time we don’t), we don’t expect them to regurgitate exact syntax on the board. Instead, we’re looking to see how a candidate works through a problem, admits when they need to backtrack, and how they discuss what they’re doing with the interviewers. We only ask our candidates to talk us through past work experiences or personal projects on the white board instead of having them implement a useless sorting algorithm.
Peer programming. Some companies are big on peer programming on the daily. We find it to be a great way to show off someone’s skills during the interview process. In a typical 1 – 2 hour interview, we will bring a laptop, keyboard, and mouse for the candidate to work together with us to solve a problem. Usually we have a prebuilt application that is directly related to what the person would be doing on a daily basis at the company. No useless brain teasers. Just real and practical scenarios to see if the developer understands how to use a code editor, understands the SDKs and frameworks we use, and can work well with another person.
Remote assignments. Be careful with this one. Some interviewers will send you “assignments” that are, in reality, work that the interviewer was asked to do by their teams or leadership. We’ve heard horror stories of candidates spending entire weekends finishing something that earned them nothing in the hiring process because the results were claimed by the interviewer. The problem with this approach to interviewing is that you’re asking for low quality effort. The candidate probably isn’t going to dedicate quality time to the assignment because they have a life. Instead, we use the peer programming approach to guarantee the developer will have a solid block of dedicated time during which we can watch in person.