55 Best Hiring Strategies for Companies and Startups
This blog explains the 55 best hiring and interview strategies for a company in 2019. And also explains several Technical and Analytical Skills used in the Interview process. Let’s discuss some of the trickiest parts of making a successful hire, and what you can do about them.
Hiring Strategy No 1:
Agreeing on a Strategy
One of the most important aspects of your interview strategy is that each interviewer knows what they’re looking for, and how to determine whether they’ve found it.
Technical interview: Algorithms and computer science fundamentals
In this interview, you’ll want to assess the basic mathematical skills and logic that are essential to being an effective developer. You may also, however, want to find out how well the candidate can learn unfamiliar concepts and quickly develop an understanding of them.
Perhaps they couldn’t reverse a linked list right away. But after the interview, do you feel confident they could do it now?
Technical interview: Database design and practical skills
Similar to the first interview, you’re looking to understand this person’s ability to create and interact with a database. In addition, you could be looking to test their ability to find information to solve new problems. Given an unfamiliar task and access to Google, are they able to make good progress?
Hiring Strategy No 2:
Talk to the candidate about how they view your product. How thoroughly do they understand it, and how much effort have they made? Do they have any ideas to make it better? In general, is this person going to help your company innovate, or would they prefer to simply code to someone else’s spec?
Hiring Strategy No 3:
Similar to the first interview, in this session you’re looking to understand this person’s ability to create and interact with a database. In addition, you could be looking to test their ability to find information to solve new problems. Given an unfamiliar task and access to Google, are they able to make good progress?
And so forth. Throughout all of these interviews, you should be looking for signs of a cultural fit, and developing confidence that your team will enjoy working with this person.
It’s also useful to look at whether the candidate applied information or discussions from earlier in the day to subsequent interviews. Did they keep making the same mistakes? Or were they paying attention, and showed that they can pick things up quickly and make use of them?
Hiring Strategy No 4:
Getting to “Yes”
It’s almost always easier to decide No on a candidate than Yes. It’s a safe choice. It doesn’t disturb your status quo and doesn’t create the risk of making a bad decision and dealing with the consequences. Furthermore, nobody’s perfect, so there will always be something you can find for criticism.
As much as you would like your hiring decisions to be unanimous and straight-forward, it just doesn’t happen that often. Even if someone is outstanding technically, there might be concerns about their enthusiasm for your company.
On the other hand, someone might be a perfect cultural fit, but have some question marks in, for example, problem-solving ability.
One of the most important, and trickiest, skills you can develop as a manager (in a small company) is knowing how to guide your team toward the right decision.
You should not be looking to make a unilateral decision, but rather to encourage the proper discussion that helps your team see candidates in the best light. And clearly, you need to know when to back off, when it’s just not headed the right way.
In general, this means
Preventing discussions from depending on negative topics
Considering the big picture—what will it mean to have hired this person, 3, 6, or 12 months from now?
Detecting cynicism when it creeps into your team, and changing things up appropriately
Making sure your interview process is gathering the correct information
Hiring Strategy No 5:
Candidates Are Crafty
Once your team is a Yes on a candidate, you can shift into all-out sell mode. Focus all of your available attention on the candidate, and make closing the deal your top priority.
Getting to this point took a long time, a team-wide effort, and a lot of false starts, so don’t shortchange this part of the process. Here are some strategies and techniques for sealing the deal.
Hiring Strategy No 6:
Keep Moving Fast
As with all parts of the hiring process, speed is critical. Your responsiveness and expeditiousness are keenly observed by candidates, and can strongly affect their impression of your team.
Getting an offer out quickly can absolutely improve your chances of having it accepted. Perhaps the chances increase only a small amount, but you’re looking for any edge you can find.
Once the offer is out, your job isn’t done. You need to stay in close contact with the candidate all the way until they make a decision. How often should you communicate? In my experience, once a day provides the right balance of demonstrating commitment without scaring people away.
Other ways you can keep moving fast:
Answer questions immediately.
Provide any necessary revisions as quickly as possible.
Update the candidate on all the great things happening with your team, just during the time in which they’re making a decision.
Finally, one of the most important reasons to be quick and responsive at all stages of hiring is that you can more realistically expect the same from the candidate. This can be very important.
Hiring Strategy No 7:
How Tight Should Your Deadline Be?
The quicker your offer gets a response, the more likely that response is positive. Conversely, the longer it takes for a candidate to decide on your offer, the more likely they’ll decline.
Therefore, you have an incentive to push for a quick decision. Push too hard, however, and you risk losing the candidate by making them feel uncomfortable or rushed.
Here’s where your expediency throughout the hiring process is valuable. When you are quick and responsive at every stage, the urgency to accept an offer is much more authentic.
If your team has taken five weeks to get through its interviews, an offer deadline of 48 hours is downright obnoxious. It suggests you don’t value or respect the candidate’s time.
If, on the other hand, you’ve managed to get through everything in just a few days, and have consistently answered questions within an hour or two, it doesn’t seem so crazy. You make things happen, and the candidate gets that.
So, how much time should give them to decide? If you’ve been quick through the process—and you should have been—two business days isn’t unreasonable.
What if they ask for more time? I’ll say this: In all my years of hiring, I can’t recall an instance where giving a candidate more time to consider an offer led to acceptance.
My preferred approach, when a candidate asks for more time to consider an offer, is to respond by asking what additional information would help them make a decision. (And then to make sure they get that information right away.)
If they’re waiting for other offers, learn as much as you can about those offers, and in particular the ways in which they’re better than yours.
Another way to head this off is to ask the candidate about their timeline at the beginning of the process. If they indicate they’ve already planned to interview for a few weeks, consider delaying your interviews with them until they’re closer to the end of that period.
You want to engage the candidate when they’re ready to act, so your impression is fresh and you can maintain positive momentum.
Finally, be up-front about your desire to get a quick response, so it doesn’t come as an unwelcome surprise at the end of a promising discussion.
Hiring Strategy No 8:
Hiring managers can benefit greatly from studying the art of negotiation, but be careful; hiring someone isn’t like selling a car. In most sales situations, the relationship ends there. With the hiring, however, you’re creating a relationship that will (hopefully) last for many years. You’re going to see and work with this person every day.
Talk to the candidate to find out their true decision points. It may take a while, but it’s worth it, as their top criteria may not be what you think. A lot of people are motivated to find the highest possible salary—but not everyone.
At IBM, I was once about to lose a candidate to another startup. It wasn’t quite a done deal yet, so I tried to learn why our offer didn’t stack up. Was it money? No, that was competitive. Our product? No, education technology was appealing.
Our team? No, the candidate would enjoy working with us and thought everyone was friendly. Only after ruling out these possibilities, and many others was I able to uncover the crucial item:
This person wanted to work on technically challenging problems, in order to develop, academically, as a computer scientist. After setting up a conversation with one of our engineers to go over some of our machine learning research, the candidate felt more comfortable about the opportunity and joined us soon after.
[Note: You can free download the complete Office 365 and Office 2019 com setup Guide for here]
Hiring Strategy No 9:
Have No Regrets
Athletes talk about “leaving it all on the playing field.” Not to push a sports metaphor too far, but I think the same applies to hire.
In hiring, as in most negotiations, it’s tempting to strive for the best “deal”— to hire somebody for the least cost possible. This feels like “winning” the negotiation.
I think this is a risky way to play it, and that the best approach starts with figuring out what your absolute best offer is. Hiring is too critical to whittle away at the margins. Get the right people in, as long as you can afford it. You’re building the foundation of your company’s future.
You don’t have to put everything in the first offer. Sometimes you can tell that a round or two of revisions is likely, such as when the candidate informs you they have other offers. But have your best offer in mind and be prepared to give it. It’s not a question of if you make your best offer, but when.
Set aside any regrets that you may have overpaid, and replace them with optimism that this new employee will exceed all of your expectations.
Hiring Strategy No 10:
Hire at the Limit
Hopefully, you’re always trying to hire people who make your team better. If so, you’re constantly pushing the limits of the caliber of candidate you can successfully hire, which in turn means that the candidates you like are going to be a tough sell.
Don’t be afraid and don’t get discouraged. Aim high and do everything you can.
Your Job Doesn’t End with the Offer
You’ve got the idea by now that your work does not end when you send an offer. You need to stay in close contact with candidates until they make a final decision.
Hiring Strategy No 11:
Build a Connection
Once you decide that a candidate should be part of your team, consider ways to help them see what that would be like.
A great way to build a connection with a candidate is to set up an informal conversation with someone on the team. The two of them can discuss the day-to-day details of how you do things, what projects are going on, and answer any questions the candidate may not have been able to ask in an interview.
If possible, choose someone who came into the company via a similar process—relocating from the same area, for example, or a graduate from the same school—to make the candidate even more comfortable with the idea of joining your team.
Another option is to invite the candidate to join your team for work or informal activity. For example:
Observe (or even participate in) a product meeting, to see what projects are active and how decisions get made. (Obviously, be careful about sharing confidential information.)
Join your team for lunch, to see how friendly and welcoming you are.
Participate in a team off-site activity, to start building relationships with others on the team.
The better a candidate gets to know you, the more they’ll be able to visualize life in your company, which will only help them feel comfortable accepting an offer.
Hiring Strategy No 12:
Connect with Students
Building a connection with college graduate hires is especially important. Students are unique in that they typically take longer, and interview with more companies, than other candidates. They also tend to be less sure about what they’re looking for, and enthusiastic to just get started and see what they like.
The techniques listed previously work well with students but may require more time and effort. Introducing a student to recent graduates on your team is helpful and effective.
And once an offer is accepted, don’t stop there—stay in touch and try to create a bond, so that their excitement builds as they finish their studies.
Hiring Strategy No 13:
Even before your candidate accepts an offer, it’s not too soon to start preparing for them to join your team. Great people want to hit the ground running, and by discussing these topics, you’ll get a better idea of how truly interested this person is in your company.
Enthusiastic candidates will be excited to talk about these details, whereas candidates who aren’t likely to sign will become quiet.
Here are a few specific ways to prepare:
• Ask the candidate for a start date. This question makes the decision very real if it wasn’t already. It also gives you an idea of how much time you have to get ready.
• Ask the candidate what kind of tools they need or want. What kind of laptop? Would they like any additional hardware? Get them to start envisioning their dream setup—in your office.
• Some candidates will ask what they can do to prepare. If this happens, be ready to respond with some ideas. This is a great way to get them more engaged.
• In some cases, and with the candidate’s permission, it’s helpful to introduce them to some or all of your team. They may want to learn more about how you do things, get advice on their upcoming job transition, or ask questions about the company.
The more you can get a candidate to think and act as part of your team, the easier you make it for them to join in earnest.
The final stages of the hiring process are the toughest, full of a variety of pitfalls as you try to successfully convince great candidates to join your team.
By crafting a realistic and effective strategy, learning how to negotiate, and seeing things through all the way until an employee’s first day on the job, you may not guarantee success, but you can at least tip the odds a bit more in your favor.
The Myth of the Ninja Rockstar Developer
The high-stakes environment of Silicon Valley has, for many years, built up the premise that you must find the absolute best, the most elite technical minds of the world, in order to succeed.
This emphasis on finding exceptional developers has contributed to culture and vocabulary in which it’s not enough to hire someone proficient or competent—they need to be “rockstars” or “ninjas.” Not only is this terminology arbitrary and elitist, but it’s also not even accurate.
For the best results building your technical team, stop thinking about mythical characters and spend your time focused on people who actually exist.
The history of “rockstar” as it pertains to software development is a bit harder to trace, but probably less benign. Referring to anyone as a rockstar connotes a type of behavior that doesn’t always fit well in a team dynamic—brilliant, but high-maintenance; productive, but seeking individual glory.
There are other theories on the use of these terms as well. Some people believe that they’re used as a cheap appeal to one’s ego. Lauding a developer with honorifics may reduce their requirements in terms of actual influence or even compensation. This is certainly a cynical interpretation, and in most cases, such an effect would be short-lived.
Similarly, the language around rockstars and ninjas may reflect an attempt to make software development more cool or fashionable.
As the profession has become more central to our modern economy, there’s a growing need to attract and retain those who are skilled at it. You could argue we need more people to aspire to be rockstar developers than, well, actual rockstars.
What’s the Big Deal?
Okay, so maybe a few engineers or other startup folks are feeding their egos by being called rockstars or ninjas. Whom is this really hurting?
It’s hurting you, the person trying to build a team. Here’s why:
It creates a false expectation of someone’s ability or potential for impact. Rockstars—actual rockstars—capture the hearts of millions, bring in tons of money, and affect the culture of an entire society.
(They also tend to trash hotel rooms and flame out quickly.) It’s not accurate or even fair to suggest the next developer you hire is going to have an impact on that scale. It’s setting you and the developer up for disappointment.
These people don’t really exist. Rockstars are literally one in a million, or even fewer, and ninjas have barely existed outside mythology for hundreds of years. It may be difficult to find a software developer, but the odds are still orders of magnitude better than one in a million.
These terms create a false feeling of scarcity, further feeding the preconception that you can only hire truly exceptional candidates—mythical characters who don’t actually exist. Developers, by contrast, do exist and deserve your attention and consideration.
These terms artificially elevate people out of proportion to their contributions, which can damage your company culture of trust and collaboration.
People who truly act like rock stars and ninjas might not be the best for your team. Remember, rockstars are known for their flamboyant disregard for the property and feelings of others, and ninjas, well, they kill people. Even if your people don’t internalize these characteristics to the extreme, it’s still a message that can be counterproductive.
You’re trying to assemble a team. Do even the most successful rock bands have how many stars—one, maybe two? The Beatles and The Rolling Stones, arguably the two most influential and successful bands of all time, were unique in the way all of their members became stars in their own right, but even in these cases, there were only four such people.
At the time of this writing, IBM’s Engineering and Design team have 28 people, and I can’t think of any rock bands with 28 identifiable star personalities.
It may seem harmless, but indiscriminate use of the terms “rockstar,” “ninja,” and others like them can undermine your efforts to build a quality software engineering team.
Hiring Strategy No 14:
Better Terminology for Software Developers
Hopefully, you’re now convinced that you shouldn’t call your developers “rockstars” or “ninjas.” But what should you call them instead?
Most developers, especially the ones you want to hire, are perfectly content with a description that matches what they actually do, such as “Senior Software Engineer,” “Mobile Developer,” or “UX/UI Designer.”
Keep it simple and you’ll be fine. This will also make it easier to have an open conversation about the expectations of the role and the things on which it’s important to focus.
Hiring Strategy No 15:
The Hiring Decision Checklist
Startups experiencing rapid growth have a lot of hiring meetings. In fact, these meetings may be the single largest use of meeting time in your company.
In my early days at IBM, hiring meetings tended to be long, drawn-out discussions that often went in circles. We debated topics that were often too open-ended and general to be useful. For example:
Is this person smart?
Do they match our requirements?
Do they fit in with the culture?
At the end of the meeting, we had a hard time making clear, confident decisions.
Over time, we’ve refined our discussions to be much more efficient and decisive, and one of the biggest improvements has been to articulate a specific, actionable checklist of characteristics to discuss:
What is this person’s ceiling?
How does this person make us better?
Is this person teachable?
What exactly will this person work on during the first 30/90 days?
Will we like being around this person?
We don’t always discuss every item for every candidate. Knowing which ones to focus on with each candidate is an important skill that you and your team will learn over time.
Let’s discuss each question in more detail.
Hiring Strategy No 16:
What Is this Person’s Ceiling?
Growing companies are looking for people who have a lot of potentials. As a leader in such a company, you need and expect people to expand into new positions within the company, take on bigger challenges, and generally unlock new skills and talents. You want each new hire to be a great long-term addition, not just fill a short-term need.
Senior candidates are probably closer to their ceiling already, which should come through in the form of strong job skills. But in every case, we want to find someone with the potential to be outstanding. If you look forward, beyond where this person’s skills are right now, what do you see?
The definition of “ceiling” depends on your company, role, and culture. In general, however, you might want to:
Compare the role you’re considering for the candidate to one that’s more senior. For example, for a junior engineer, this might be a senior engineering role. Are you confident this person will be able to hold that role someday?
Consider whether the candidate has shown a consistent track record of improvement and learning throughout their career. Does that growth or learning appear to have tapered off or hit a plateau?
Consider how quickly and enthusiastically this person can learn new things.
It’s worth spending the time to decide how your team evaluates someone’s ceiling, in order to make these discussions more productive.
Hiring Strategy No 17:
How Does this Person Make Us Better?
It’s far easier to find reasons why you shouldn’t hire someone than make a convincing case that you should, especially when one negative opinion has veto power.
I’ve found it helpful to flip the question around and ask the team to look for specific ways this person will improve our team. For example:
What skills do they have that we don’t?
What can they do better than anyone here?
What can they teach us?
What changes to our culture or process will they lead or precipitate to make us better?
With junior candidates, it might be less obvious, but there should still be some potential. For example, will their creativity help us brainstorm new projects? Will their ambition drive us to accomplish more? Will they bring in new, fresh ideas?
If you can’t come up with at least one specific way that a potential employee will improve your team, it’s probably not a good match. By contrast, if you find that you’re learning new and useful things from the candidate during the interview, you’ve probably found a great addition to your team.
Hiring Strategy No 18:
Is this Person Teachable?
For any hire, we’re going to be investing precious time helping them succeed. For a junior hire, this means on-the-job technical training, mentorship, and patience as they learn the skills to be effective.
For a senior hire, it means helping them understand our code base, practices, and philosophy so that they can start contributing and improving what we do.
In all cases, we want to be confident that there’s going to be a great return on that investment. For example:
Will they learn something the first time, or will we have to keep reminding them?
Will they be able to extrapolate new skills and ideas into problems they haven’t seen before?
Are they open-minded about how to do things?
In a growing company, it’s also important to have people who can themselves grow—who can learn new things, take on new responsibilities, and solve the increasingly complex problems that your organization will face. Being teachable is a critical characteristic for achieving this personal growth.
What Will this Person Work On?
It’s important to discuss the specific projects on which you anticipate a new hire will work during their first 30, 60, or 90 days. If this is difficult—if you can’t come up with a good list of valuable tasks that you’re confident they can handle—that’s a bad sign.
Create a detailed roadmap of projects for this person and then ask the following questions:
Is this work worth the cost of hiring someone?
Will we be happy in 90 days with these results?
What does this free other people on our team up to do? This topic can bring a lot of clarity to the hiring discussion.
Will We Like Being Around this Person?
Sometimes called the “Airport Test,” it’s important to discuss how you’ll feel about spending several hours per day with this person. You go through a lot of good and bad times as a team, and it’s a lot easier to do so with people who generally make you happy.
One way to help assess this quality of candidates is to include interview questions that test self-awareness and emotional intelligence. For example:
Tell me about a time when a project went off track. How did you know, what did you do, and what did you learn from the experience?
What do you enjoy about your work?
How will this position help you achieve what you want?
People with high emotional intelligence—who understand how their actions affect those around them—are likely to be great teammates and generally pleasant people with whom to spend several hours solving hard problems each day.
At IBM, we’ve managed to cut our hiring meetings from an average length of one hour down to about 15 minutes. This is a valuable saving since we’re doing more hiring than ever. We’ve also adjusted our interview approach to making sure we get answers to these five hiring questions.
The specific questions you use may be specific to your team, but answering these types of questions, as a team, will help focus your hiring decisions.
Hiring Strategy No 19:
Making Interviews Fun for Your Team
Interviews should be fun. Think about it… You get to meet people, learn new things, and hear about interesting experiences. Why wouldn’t it be an enjoyable experience?
Unfortunately, the interview process in many companies is mundane, mechanical, and, frankly, joyless. Conducting interviews is considered just another obligation that contributes to an engineer’s “overhead”—time spent doing things less fun than building a product.
You’ll get the best results if your team truly enjoys conducting interviews. They’ll be more enthusiastic, more engaged, and more insightful. Candidates will notice the attitudes of your interviewers as well, and they will respond positively to a team that appears to love their work. This perception can be critical for landing the best hires.
Finally, some personalities are simply better suited to being an interviewer. Look to build a team that possesses, in addition to the necessary technical and analytical skills, the ability to connect with people, a deep empathy for others, and consistent enthusiasm for your company and their work.
The Importance of Fun Interviews
You may be thinking, “Isn’t this kind of silly? Interviews are serious business and too important to worry about being fun.” Actually, the importance of the interview is exactly why it should be fun for everyone involved.
Fun for the Candidate
You’ve probably heard that an interview is a two-way street—while you’re interviewing a candidate, they’re simultaneously sizing up you, your team, and the opportunity.
Obviously, you want them to have a favorable impression of you, and one of the best ways to accomplish this goal is for them to enjoy their time with you. There are many ways to make an interview more enjoyable for the candidate. For example:
Start with a tour of your office and the best benefits of working there. Sell them on your company from the very beginning. Candidates know they’re going to get grilled, so taking the time to pitch them up front shows optimism that they’ll do well, which can rub off on them.
Give the candidate some goodies to take home, such as a company T-shirt or mug. Again, it’s a sign of faith and confidence in their ability, which creates a positive impression.
Bring candidates into team activities. Social events such as team lunches are a great way for a candidate to meet and learn about a lot of people in your company, not just the ones interviewing them.
When possible, meetings about engineering design or product development are also highly engaging ways to help a candidate envision life in your company.
Select and train interviewers to be engaging and personable. Your interview team is representing your company to the candidate—put your best foot forward.
Compose your interviews of interesting and novel questions and challenges. If your interview questions are the same tired ones that candidates have been hearing for years, they won’t think of you as a dynamic engineering team with a forward-thinking culture.
Some of the best interview questions are derived from problems your team is actually facing. Such questions also give candidates a better picture of the work they might do at your company.
Every candidate who visits your office should come away hoping to work there. Resist the temptation to lower enthusiasm for candidates you know aren’t going to succeed—keep selling until the very end.
Look at it this way: A candidate who doesn’t get an offer from you is going to be disappointed, of course, and probably going to be thinking one of two things:
Eh, I didn’t like that place anyway.
Darn! That place is awesome.
You definitely want them thinking the latter, for several reasons:
They may be more qualified in the future and worth considering again.
They might recommend your company to friends or colleagues.
A prospective candidate, upon hearing of their interview, may ask for their opinion of your team.
Every time a new person walks into your office, including job interviewees, you have an opportunity to sell and promote your company to the world. Take advantage of these opportunities, as you never know to what they may lead.
Fun for Your Team
An engineer who dreads interviewing candidates will look for excuses not to participate, provide feedback veiled in cynicism, and represent your company in an unfavorable light.
It’s critical to find ways to make the process enjoyable for your engineers, and a process in which they value being apart. Tolerating interviews isn’t good enough—you want your team to look forward to them.
What makes an interview fun for an engineer?
Hiring Strategy No 20:
First and foremost, the interviewee must be a high-quality candidate. Engineers are intellectually curious and creative people and enjoy talking with others who share these traits.
Some of the best interviews are those in which the interviewer feels like they learned something useful or important. This experience makes a strong impression that hiring the candidate will lead to lots more learning and growth.
By contrast, an interview with a poor candidate will feel like a waste of time. If this happens too many times, the engineer will start trying to figure out how to get out of the interviews altogether. Who could blame them?
In order to make sure your team is only spending time with high-potential candidates, perform rigorous screening at the start of the process. For most engineering positions, this will mean a focus on technical aspects of the job, particularly coding, as this tends to be the most difficult requirement to meet.
As a rule of thumb, aim for at least a 50% success rate for candidates in the next interview round. For example, once you’ve advanced a candidate to a full on-site interview, they should have at least even odds of getting a positive decision from your team.
If you don’t think a candidate’s chances are that strong, you probably shouldn’t invest any more time with your team.
A high success rate ensures that your interviewers will treat each new candidate with optimism and excitement. They’ll be looking for good reasons to hire this person, rather than excuses not to.
An Example from IBM: Conduct Interviews in Reverse
Most teams start their interview process with an engineer. If that goes well, the candidate typically comes in for several more engineering interviews. And then, only after all the engineers have given a collective thumbs-up, does an executive or manager come in for the final assessment and possibly make an employment offer.
At IBM, we flip that around
Our interviews start with me, the executive in charge of the engineering team. Here’s why:
I prefer to assume that an engineer’s time is more valuable than mine. Even if that’s not always true, the time of five or six engineers definitely is. It’s better to lose an hour of my time than several hours, combined, from the team.
I also want to make sure that our engineers generally have a good experience in their interviews, and it’s a lot more fun to interview a great candidate. By making interviews something that the team looks forward to, we get the best results and collectively give the interview process the priority it deserves.
Finally, this process helps me to keep thinking like an engineer. As my own job has progressed away from writing code on a daily basis, the regular interaction over the code in our interviews helps me stay at least somewhat connected to the craft. It’s usually the only time of the day I get to write any code, even if it’s just pairing with the candidate.
I don’t do the typical executive interview. This is mostly technical—after a few questions about the candidate’s interest, motivation, and other details, we jump right into some coding and design.
I want to be confident that anyone passing the interview has a good chance of succeeding with the rest of the process. We can always meet again to discuss high-level topics, if necessary.
Being the first interviewer also lets me start selling the candidate on IBM from the beginning. Interviewing is truly a two-way process, and if you do nothing but grill a candidate for several hours before discussing the merits of your company and the position, you risk pushing them away.
A motivated candidate is probably going to perform better, and it’s in your interest to have everyone trying their best.
Hiring Strategy No 21:
Owning the Process
Your interview process is just as much a work product of your team as the code you write. If you don’t practice top-down, waterfall project management for product development, you shouldn’t apply that technique here either. Your interview team will do their best if they feel some personal ownership of the strategy and responsibility for the results.
One of the best ways to involve your team is to have them craft their own interview questions. The overall composition of the entire interview needs to carefully planned, but this can be done with a bottom-up approach. For example:
Give each interviewer an area to test (for example, SQL and relational databases), but let them devise the actual questions.
Encourage your engineers to derive their interview topics from real-world problems, so that the interview results are a good predictor of job performance.
Construct and review the overall interview strategy with input from all members of your team.
Discuss and review your list of hiring criteria and requirements with your team.
You’ll know your team feels ownership of the process when they start to suggest unsolicited improvements or, even better, recruit candidates on their own.
How to Make Interviews Fun: Screen Out All But the Best Candidates
Interviewing engineers, like engineering work itself, is a creative process, and people perform better in creative roles when they’re happy. How can you make interviews fun, overall?
For engineers, the most enjoyable interviews are generally conducted with high-caliber candidates. For example:
It’s satisfying to have someone solve problems effectively with you.
You can start to imagine how much better your team will be with this person on board.
You may learn new things during the interview.
It’s just generally fun to converse with a bright, friendly person.
Here’s the key insight: If you screen out all but the very best candidates before your team even talks with them, you ensure that nearly every interview they conduct is going to be fun.
Furthermore, as they learn that interviews are fun, they become more enthusiastic about participating, which leads to better interviews and a better representation of your team to the candidate.
Many teams share the load of screening candidates. It’s certainly easy to see why—initial phone screens, resume reviews, and other early phases of the recruiting process are arduous, repetitive tasks. Under the weight of this responsibility, it’s tempting to divide and conquer.
If at all possible, however, you, as the manager of a team of busy engineers, should try to shoulder this burden yourself. Sharing the difficult parts of recruiting and interviewing will just make everyone equally frustrated with the process.
Your job is to make everyone else more productive, and ensuring that your engineers only interact with exciting, high-quality prospective new teammates is one of the single biggest ways you can do this.
Hiring Strategy No 22:
Who Makes a Good Interviewer?
In general, it’s good to involve as much of your team as possible in your interviews. Participation in the process and in the decision-making builds a sense of ownership and responsibility, which will help bring out the best in those taking part.
Not everyone is born to be an interviewer, however. One way to help make interviews fun for your team is to select interviewers who naturally enjoy the process. It’s also important to select and trust the people on your team who perform the function well.
Here are some qualities to look for in your interview team.
Hiring Strategy No 23:
Technical and Analytical Skill
Technical skill is probably the first thing teams and managers consider when selecting interviewers. It’s not the only consideration, but it’s certainly very important. In order to determine the breadth and depth of the candidate’s skill, an interviewer needs to be at least as strong.
Don’t forget: The candidate is testing you as well. Most engineers care deeply about the ability to learn from their colleagues, so they’re looking to see if your team has the knowledge and skill to teach them new things.
Hiring Strategy No 24:
Empathy for Others
Only people who actually have emotional intelligence can test for it in others. A growing body of research indicates that this type of intelligence—which includes self-awareness, the understanding of motivating factors, regulating one’s own emotions, and empathy for others—is highly influential in individual and team success.
You may need to learn more about emotional intelligence yourself so that you can identify it in your team. As with technical ability, this quality will be noticed and judged by your interview candidates.
Just like you, they want to work with people who understand and care about them and will be helpful allies as they confront difficult challenges.
Hiring Strategy No 25:
Enthusiasm for Their Work
Not everyone loves their work, but you only want to hire people who do. For someone to be excited to join your team and bring their energy and excitement to your company, they absolutely need to feel that this enthusiasm will be reciprocated.
Your interviewers, and in fact everyone in your company, should be selling a candidate on your company’s merits at every opportunity. Even if they don’t get the job, you want them to wish they had. They’ll talk with friends and colleagues afterward—whether it’s three days or three years—and you want their impression to be as positive as possible.
It’s difficult to fake enthusiasm for something for an entire hour or more. Be sure that everyone on your interview team is truly excited about what they do and the opportunities ahead.
Conducting an interview is more than just asking questions and writing down the answers. It’s a chance to connect with a new person, discuss interesting ideas, and make an important decision affecting the future of your company.
If people on your team, or the candidates you interview, don’t seem to appreciate being part of this process, something’s wrong. By planning an enjoyable experience for the candidate, aggressively screening out all but the best candidates early on, and sharing ownership and responsibility with your team, you can work toward a process that everyone enjoys and embraces, ultimately leading to better results.
Hiring Strategy No 26:
Why We Don’t Allow Java in Job Interviews
An engineering interview process should be designed to quickly and accurately select the best candidates. As each team is different, the requirements and criteria for hiring will vary.
What’s important, though, is that your process helps you increase your precision and make the best use of your time. Don’t be afraid to challenge conventional wisdom or industry standards along the way.
At IBM, we’ve taken the very unusual step of removing Java, one of the most widely-used and widely-known programming languages in the world, from our coding interviews. It was a difficult decision to make, and one that we debated at length, but the results have been excellent.
Whether or not such a policy is right for you and your team, it is my hope that our experience will help you think of ways to examine and question traditional interviewing methods and discover more accurate predictors of success.
Hiring Strategy No 27:
A few months after I joined IBM, we instituted an important, and somewhat unusual, change to our interview process. We no longer allow candidates to use Java.
For all parts of the hiring process that involves writing code (which is most of them), candidates are free to choose any language they like. Except for Java.
None of us, myself included, has any personal issue with Java as a programming language.
It’s unquestionably one of the most powerful, versatile, and influential languages ever devised. Like many software engineers, I’ve written countless programs and architected myriad applications, large and small, in Java.
IBM is an analytical company, and we’re always looking at data for signs of improvements to be made. Hiring is no exception. After my first 40 or 50 phone screens at IBM, I was beginning to notice a pattern—candidates who chose Java for their interviews tended to fare poorly.
At this point, I wasn’t looking for a reason why that might be the case. I just wondered if the data was trying to tell us something. I asked the other engineers who conduct interviews, and they said that now that I mentioned it, it seemed like a pattern for them as well.
We do a lot of interviews, so I’m always looking for something that will help us a separate signal from noise, and I was starting to think we were on to something. I next looked at our recent hiring history, to see what language had been chosen in those successful instances.
Of the last 14 engineering hires, only two had used Java, and both people indicated another language would have been fine too. (The most frequently chosen languages were PHP and Python.)
Now we were really on to something. Java was almost never used by people we ended up hiring and was frequently used by people who fared poorly.
In coding interviews, we let the candidate choose the language, while keeping the questions or challenges the same. The candidate is also free to change languages at any time, so it’s unlikely that Java is simply a poor match for our interview questions.
With this analysis, we were ready to cut Java out of the picture but wanted to be thoughtful about how to best make this change. Since many of us still like programming in Java, we also discussed and debated why this poor performance could be happening.
What’s Wrong with Java?
Why have we moved away from Java? This is really just a data-driven decision. Candidates who have chosen Java in our interviews have fared poorly, on average.
And, of the ones who did well (and those who we subsequently hired), each person indicated they would have been just as comfortable in another language. But this experience also got us thinking about why this phenomenon might be happening. Here are some possible explanations.
Java for Web Apps
IBM is a web startup, doing web development. For this type of work, Java is not as frequently the tool of choice for people using modern practices and methodologies.
For example, some of our coding challenges require parsing and manipulating strings of text—common tasks when dealing with millions of user-generated text documents. Python, Ruby, and PHP have handy built-in methods that make these manipulations simple, whereas Java requires a bit more complicated approach.
Java Is Just One of Many Tools
For web development interview problems, Java is often not the best choice for creating a clear, concise solution. It’s tough to watch someone write 20 lines of Java for something that can be done in one line of Python. Being aware of the capabilities of multiple languages and being able to select the right one for a particular task are important skills.
We’re looking for candidates who can learn quickly and apply that learning to new problems. For this reason, we prefer to conduct the interview in a language well suited for our work, even if it’s less familiar to the candidate, to see how well they can pick things up with our help.
We frequently find that candidates prefer to use familiar techniques, especially in Java, even when they’re not the best choice for a particular problem.
The technology industry changes quickly, and it’s important to build a team of people who can change along with it. A desire to learn and play with new development tools correlates positively with a strong performance in the rest of our interview process.
Hiring Strategy No 28:
Another strong indicator of creativity and energy in a software engineer is the presence of side projects. Many of the best engineers I’ve worked with are constantly tinkering with new ideas or tools.
They’re looking for better, more powerful ways to build, and no responsible engineer would kick off a large project with untested, unfamiliar technology. And in many cases, these side projects are done in new languages, as a way to learn.
I believe—and I know many will disagree—that you’re less likely to find a creative, diligent, forward-looking engineer who has done side projects only in Java.
People Start with Java
Java is the most common language used in computer science instruction and has been for many years. Any computer science degree completed in the past 15 years likely included a lot of Java for projects and coursework.
To succeed in a startup, however, you need the drive to learn new things and a wide variety of skills and someone using only what they learned in class probably hasn’t shown that drive yet.
Startups need engineers who aren’t satisfied with the basic skills that everyone is taught; they need explorers and creative, curious minds who are always looking for better ways to solve hard problems.
Classes focused on web development do tend to use a wider variety of languages, such as Python and Ruby. Students who have moved past the basics and begun to specialize in software engineering for the web are more likely to have skills in languages other than Java, and these are typically the students were looking for.
Just because Java can be used for nearly anything doesn’t mean it’s the best choice for everything.
Results: Has this Policy Worked?
At the time of this writing, IBM’s “No Java” policy has been in place for nearly a year. During this time, we’ve screened and interviewed hundreds of candidates. Here are some of our early findings.
Hiring Strategy No 29:
Interviews Are More Focused
As mentioned, Java isn’t a perfect fit for many of our interview questions. Working on solutions in Java is a bit more convoluted and makes it harder to see and discuss the important logic underlying the candidate’s implementation.
By using a better-suited language, we’re able to more quickly and consistently hone in the actual problem-solving ability of the candidate. Perhaps more importantly, we’re more confident about our analysis of the interview and our ability to make decisions afterward. The results are more clear.
Hiring Strategy No 30:
Sometimes We Give In
Occasionally, we relent. For a variety of reasons—for example, when the candidate pushes unusually hard to use Java, or the candidate is a new grad and has little experience outside Java—we sometimes give in and let a candidate proceed in Java.
Seemingly without exception, the candidates for whom we allow Java to fail to meet our expectations. They don’t have the technical skill, creativity, or ability to learn quickly that we need.
Interestingly, many candidates who prefer Java end up doing better in another language. I recently conducted an interview with a young candidate who clearly preferred Java, but was a good sport and agreed to give it a try in C++ (his second choice).
Although he was rusty, he showed a lot of good traits—he took suggestions well and made use of them, learned new concepts quickly, and came up with multiple approaches to hard problems.
Halfway through the interview, it was painfully clear he was frustrated in C++, so I offered him the chance to switch to Java for the second half of the session. He gratefully accepted. Once in Java, however, he reverted to familiar habits, whether they were a good solution or not. He stopped listening as much to suggestions.
He was less creative in looking for alternative solutions. In summary, he may have felt more comfortable, but his overall interview performance suffered noticeably. Based on our results, we’ve become more insistent about the “No Java” rule.
Hiring Strategy No 31:
Restricting the use of Java has filtered out more than just technical skills. It has also helped us screen candidates who don’t have the desire and capability to push themselves and learn new things.
To our initial surprise, people rarely raise a fuss when they learn they won’t be able to use Java. Some are clearly anxious, but our experience so far is that they do just fine in the interview.
Very few, however, are upset to the point where they lose interest in the opportunity. We often have an open discussion about the policy and why we believe it’s important.
Most people understand our goals and are happy to proceed. In the rare cases where somebody declines to continue, we’re confident it wasn’t going to be a good match, and if anything, we’re grateful to have figured that out more quickly.
There’s no denying that carrying out this policy has been, at times, socially awkward. An interview may be off to a great start—developing a good relationship with the candidate, starting to understand the depth of their skills and experience, and feeling optimistic about their overall chances—when you have to throw in this unusual wrinkle.
It’s so unexpected that it typically takes people back. The question is, for how long?
We have two basic choices when it comes to enacting the policy:
Tell everyone about the No Java policy at the very beginning of the interview process, to prevent confusion when we get to coding interviews.
Wait until it’s time to write code and see what language the candidate chooses. Only if they choose Java will we have to discuss the policy.
We’ve decided to go with the first approach. We’d much rather clear up any confusion or concern early in the process, rather than during the most important part of the interview when the candidate is about to showcase their coding skills.
No matter how you carry out a policy like this, there’s going to be some social awkwardness. In order to have such a policy, you need to be willing to enforce and defend it in a variety of circumstances.
At IBM, we’ve made a somewhat unusual and controversial decision to exclude Java from our software engineering interviews. The results have been good for us so far, even if we can’t fully explain why, or what it means.
Such a policy isn’t necessarily right for you and your team, but don’t be afraid to think differently. Everything about a startup should be considered for experimentation and innovation, including how and why you conduct your interviews.
One more note: We’re definitely not suggesting people should stop learning Java! It’s a powerful and useful language. What we are suggesting, though, is that if you’re interested in fast-paced, modern web development, you should have a few more tools in your belt.
Hiring Strategy No 32:
Career Advice for Software Engineers
Before I became a manager of engineers, I was an engineer. This appendix contains advice on a variety of topics to help software engineers find a great job, fulfilling work, and growth in their careers.
Career Paths: Silicon Valley vs. Traditional Technology Companies
Silicon Valley venture capitalist and Google/YouTube veteran Hunter Walk once posted a tweet that prompted me to more deeply examine something I’d been thinking about for a while—something I wish people had told me when I was starting my career in technology.
I started my career by working in two big companies, Xerox (at the famous Palo Alto Research Center, or PARC) and Hewlett-Packard (at HP Labs). The career path for a software engineer at a large tech company such as HP, IBM, or Intel typically looks something like this:
Senior software engineer
Staff software engineer
A senior staff software engineer
Principal software engineer
Master software engineer
Chief software architect
Similar progressions exist for other types of engineering as well.
Typically, there’s a parallel track for management that diverges at some point, and leads to positions such as these:
Senior engineering manager
Director of software engineering
Senior director of software engineering
Vice president of software engineering
Senior vice president of software engineering
Executive vice president of software engineering
In both cases, you’re “working your way up” (my list is upside down), in the way that people in the United States have thought about career advancement since at least World War II.
After living and working in both worlds, I now understand that the Silicon Valley startup career path looks a little different:
Here’s the key difference: in the traditional path, your career success is defined mostly by your individual advancement. In the Silicon Valley path, however, you may have different positions at each company, depending on what you like to do, but your career success, especially in financial terms, will likely be dominated by the overall success of the companies.
Ask any of the first 1,000 employees at Google, no matter what their title. Therefore, it’s vitally important for you to work with the people who are most likely to succeed and maximize the opportunities for doing so.
If you work at Company B with an outstanding team, but the concept didn’t quite make it, your chances at Company D will be much better if you can work with some of them again.
Furthermore, your opportunities at subsequent companies will come from the people at the previous ones. Otherwise, your fate is in the hands of recruiters and HR departments. If the all-star team from Company B is reassembling for another try, you want them to be thinking of you.
This can also apply to projects—within companies or open source, for example,
Even if you’re not switching companies, look for projects with great people. I certainly met some at both Xerox PARC and HP Labs and did end up working with some of them later. I just wish I had known how important that was going to be.
In summary, here are the lessons to share from my experience:
Do everything you can to work with great people.
Figure out who’s on your team—the people you want to work with again, and build your career with.
Go where the great people are. (They may not be where you think.)
If there aren’t great people where you are, leave.
How to Find the Best People to Work With:
To build a successful career in Silicon Valley, it’s important to find great people to work with. How can you make this happen? A good place to start is to examine that question from the other direction. Namely, “How do I make sure others think I’m one of the best people to work with?” It’s a two-way street.
Let’s face it. Not everyone may want to work with you. Even if you find the company, group, or project of your dreams, they may not accept you in return. I haven’t gotten an offer for every job for which I’ve interviewed.
So how do you get yourself to the top of the others’ lists of people with whom I’d like to work again?
Hiring Strategy No 33:
Be Good at What You Do
It may seem obvious, but it’s worth stating—you should be a strong practitioner of your craft. A mobile app startup doesn’t want an iOS developer; they want the best iOS developer. Companies don’t want someone who can perform all the functions listed in their job descriptions; they want someone who can do them all and then some.
Keep your skills sharp and current. Don’t coast. Just because you can do your current job with the skills you already have, doesn’t mean you should. Learn new skills. Try new techniques. Look to do your work better. Here’s a test: are you always asking others for help, or do they come to you?
If you’re not the expert, strive to get there. And asking others for help is a great way to start.
Know What You Do
People have different skills, and most teams require a wide variety. Understand where you create the most value—where you can provide the most improvement over the next best alternative.
This may not be as simple as you think. Drawing again on my experience in software, if you describe yourself as, say, a Ruby developer, your ability to write Ruby code is only the beginning.
How versatile are you? If your team needed to build something using C++, would you be able to help? What if they needed someone to learn Hadoop for a new project?
Would they ask you first? Does your code need much maintenance? Do your colleagues read your code to learn the best way to do things? This topic probably merits an entire post of its own, just for software development.
At this point in my career, I contribute more value as a software manager than as a developer. This obviously means that some opportunities aren’t right for me—if good management is already in place, or the team is too small to need it yet.
For example. But if you have a growing team that’s having a hard time keeping up with the competing demands of product management, reliability, development speed, and overall employee morale, I want to be the one you think of first.
Stay in Touch
This is the easy part. Don’t lose contact with the superstars in your life. There are plenty of tools with which to do this—the best choice depends on your contacts. Go where they are, and stay in touch.
Hiring Strategy No 33:
How to Get Ahead: Document Everything
If you’re looking to advance in your career—to get new opportunities, responsibilities, authority, and, yes, paid more—I have a simple but invaluable piece of advice.
Write down everything you do
Every day, week, or month, add to a running list of your accomplishments at work. Include as much as you can think of, no matter how big or small.
As much as you might like to think that your manager, peers, and colleagues appreciate and remember all of your wonderful contributions, the fact is that they don’t.
They have their own busy lives to worry about, their own projects, and their own interests to consider. It’s not intentional or antagonistic—they simply don’t remember everything. That’s why you need to give them a little help.
If your company performs annual reviews, there’s probably a part of the review process to go over your accomplishments during that time. You might be asked to provide a list.
Coming up with a summary of your accomplishments for the past year is difficult and time-consuming, and you’re certain to miss some important things. It’s much easier to add to a document, incrementally, throughout the year.
Even if you’re not asked for such a list, it will still be valuable. Someone’s going to be figuring out what you did, and if you can easily spot omissions, it only makes your overall case stronger.
What if your company doesn’t even do regular reviews? (This is a bit of a warning sign about your company, in many cases, but would understandable in early-stage startups.)
Well, there’s still probably going to come a time when you would like a raise, promotion, or freedom to work on new projects. You’re going to be able to make a stronger case for yourself, in any discussion, by having a comprehensive document of your accomplishments handy.
Finally, this list gives you the chance to create a positive impression. It doesn’t have to be fancy. Open a document in Google Docs, Microsoft Word, or your favorite text editor, and just start typing. You’ll be glad you did.
The Most Important Quality for Software Candidates:
In discussing and preparing for software interviews, people typically focus on the technical aspects: algorithm design, data structure selection, performance and complexity analysis, and so on.
As our interview process has evolved and matured at IBM, however, the factor that probably rules out more candidates than any other is this: teachability.
Everyone is going to learn and grow into a new position. Nobody is a perfect fit when you first meet them. The question, therefore is, How much of an investment do we need to make in this person, and how much will it pay off?
Junior candidates will require more mentorship than senior ones, but in both cases, some will be required. Even for people who already are skilled programmers, they need to learn our process, code base, and conventions. In our interview process, we’re looking for signs that this mentorship will be productive. It really boils down to two questions:
Is this person interested in learning?
Is this person capable of learning?
There are a few ways to demonstrate that you are teachable in an interview setting:
Receive and incorporate feedback from your interviewer. If they suggest a way to approach a problem, listen. They’re not trying to trick you. (If they are, I suggest you interview somewhere else.) Respond to that feedback and try to incorporate it into your work. You might know a better approach, but if you decide to say so, you need to be right.
Apply things discussed earlier in the interview to subsequent questions or problems. This is a great way to demonstrate that you’ve learned something.
Communicate and have an active dialogue as you work through things. Good communication is an indication that people will be able to have productive work sessions with you.
Talk about projects where you’ve tried to learn things, beyond strictly what was asked. Show that you’re self-motivated to learn, improve, and share knowledge with others.
Presenting yourself as a teachable team member can really set you apart — in your next interview and throughout your career as well.
By nature, being teachable means that you are receptive to testing and trying new approaches. Your mentors and colleagues will be eager to share their unique perspectives, and you’ll learn how to attack projects from a variety of angles.
This experience — and your willingness to learn — will be invaluable at your current position and beyond.
The Most Common Mistake in Startup Job Applications
As someone who has managed technical teams for several years, at large and small companies, I’ve received and read hundreds, maybe thousands, of e-mails from applicants. You certainly learn some heuristics to help identify the good ones quickly, but you also spot frustratingly common mistakes.
In my experience, the most common mistake for people applying to startups, the one that has undermined the chances of some otherwise qualified candidates at my company, and certainly others as well, is as follows:
You didn’t tell us why you want the job. If you haven’t spent any time learning about us and what we need, why should we do the same for you?
Every candidate that gets to the interview stage requires us to do hours of preparation, interviews, and discussion. If your introduction is generic, I’m led to believe that you’ve contacted dozens of other companies as well. If we’re going to invest our time in getting to know you, we’d like to know you’re serious about us.
It’s different for bigger companies, which have hiring processes that involve more people and put your information through some normalization (a huge hiring database) anyway. But at a startup, every hiring decision is so important that it takes careful consideration.
Here are some specific manifestations of this problem, which you should avoid in your own communications.
Send an introduction or letter that has no information specific to the company or position
Write “let me know if you have any good opportunities for me” — you should be explaining that to us
Apply for a position that clearly does not match your background, without any explanation why
By contrast, here’s how you can stand out. Do:
Tell us why you want this job, specifically
Demonstrate that you’re interested in our company and products
Explain how you would be able to do the job, to the best of your ability
Describe examples of past work that would apply
And always include an up-to-date resume. It may seem quaint, but a resume is still one of the most concise, portable summaries of a person’s skills and experience you can find.
The Most Common Mistake in Startup Job Interviews
This happens way too often:
Q: “Tell me about this recent project on your resume. What was your role, and what did you contribute?”
A: “Well, we built a tool to…” Whoa, stop right there.
Any interview response that includes we are not useful. We’re not interviewing your whole team. We’re interviewing you. Tell us what you did.
If you’re able to talk only about what we did, it, unfortunately, sounds like you didn’t do anything. For example:
Bad: “Our team refactored the order-processing system to improve performance.”
Good: “I reimplemented an existing Python library for order processing in C++ and added multithreading to improve performance.”
Great! You’ve just given me a half dozen things to ask about and dive into. The more detail, the better. Don’t be too modest — this is your time to show off. Since you’re here in our office, you’ve convinced us you want the job; now convince us you can do it.
Four Ways to Improve Your Next Job Interview
Job interviews can be stressful, confusing experiences. Here are four simple tips to increase your chances for success and enjoyment of the process.
Hiring Strategy No 34:
Learn About Your Interviewers
The team interviewing you has almost certainly looked you up on Google, LinkedIn, and probably Facebook and Twitter too. You can do the same.
For example, search their company on LinkedIn for the type of role for which you’re interviewing. Even if you can’t find people specifically, you can get an idea of the culture and skills that are important.
Come with Suggestions
During the interview, show that you’re really interested in this opportunity. They’re investing time in you, so demonstrate that you’ve done the same. Show that you’ve thought about why this job, in particular, is so important. Show that you’ve taken the time to research what they do and try to understand it.
One of the best ways to prove your interest is to offer suggestions on how to improve their product, process, or some other part of the company. They may disagree with your idea, but they’ll appreciate that you took the time to try.
Don’t Call It Resume.pdf
Properly naming a resume file is evidently still a widespread problem.
I currently have 14 files called Resume.pdf in my default download folder alone. Put your name and something descriptive in the file name, so it’s easier to find and remember.
Five Minutes Early Is Much Better Than Five Minutes Late
Obviously, it’s better to be early than late, right? But let me explain some reasons why that you might not have thought of.
First, it might come across as rude. You’re taking this seriously, right?
Second, if you arrive early, your interviewers might not be fully prepared. This gives you a tiny psychological edge.
Finally, if you’re late, you’re possibly shortening the time available to impress the team with your skills. If you’re fortunate, your interviewers will have extra time to run late. But they might not.
Remember, your interviewers have to start by assuming you’re not going to get an offer. The interview is your time to prove you should. Don’t short-change yourself.
Deep-Link to GitHub: Make Your Resume Stand Out
Many software engineering resumes, cover letters and job applications now include links to personal repositories on GitHub, the popular code hosting site, which is great.
For software developers, this is your portfolio. Unfortunately, though, it’s hard to find the important information there — most projects have layers of directories, boilerplate code, and lots of stuff written by other people. It’s not useful, for example, to see that you were able to generate the default scaffolding code for a Rails app.