Stories & Tips: 50+ Interviews With Facebook, Twitter, Amazon & Others

2016-03-22 - By Robert Elder

Many of my students have been asking questions lately about how to do technical interviews, so I've decided to write about my interviewing experiences. I will start by giving a number of anecdotes because they're interesting to everyone, but the later parts of this post are mainly targeted at prospective students who haven't done any software developer interviews before.

Expanding On The Title

I had at least 50 (probably more I can't remember), interviews with various companies to secure internships during my undergraduate program at the University of Waterloo in software engineering from 2009-2014.
I did 6 internships across 5 different companies, and I got some form of full time offer/solicitation from every company I worked for.
All of the positions I applied to were for 'software developer', 'software engineer' type positions, mainly related to web, but also mobile and a handfull of C/C++.

Since most of my students are in hardware-based programs you should take note that my experiences are related to purely software based positions. I have never done an interview where a primary part of the job involved manipulation of physical aspects of hardware.

Co-op Term 1: ProductWiki

The first co-op term I only got 2 interviews. One was for a local startup where I could actually do coding, so I was excited for this one. One of my interviewers was Omar Ismail who later went on to found streak.com (YC S11). Omar is a cool guy to work for, and he's hiring. I forget what my interview questions were this term, but I recall mentioning that I liked watching programming talks on the GoogleTechTalks youtube channel.

The other interview was for a customer service 'tech support' type position that I didn't much care for. I forget the name of the company. Almost the entire interview was the interviewer talking about himself and his company in a monotone voice. I only remember one question from the interview, and the point of it was to realize that customers in Australia are in a different time zone and that this is important when considering interactions with users. I did not get an offer for this position.

Completely Bombed The Interview

I had an interview with a trendy silicon valley startup before I had taken my algorithms courses. The first question was a dynamic programming question where I had to find a sub-matrix that summed to a particular value. This was before I had even heard of dynamic programming, and I had no idea how to solve the problem at the time. We moved on, and the next question (if I recall correctly) was how to find cycles in a graph. This was before I had taken a graph theory course, so again I had no idea how, and I didn't even know what they were asking me at the time. This was the first interview where I did so badly that I felt like I completely wasted the interviewer's time and the interview had to end early.

Twitter

On one work term, I decided to get ahead of the game and start looking for the next co-op early. I secured an interview with Twitter. In total, I had 5 (or was it 6?) rounds of interviews with Twitter, and at the end they said they did not have any positions for me. During the interview process, I did get to stop by their HQ in SF for one of the recruitment events, and attend a talk from the CEO. The cafeteria looked amazing (there was bacon). After I left the event, I had to bike back to the caltrain in the dark. SF is a sketchy looking place at night, and there are one-way streets everywhere. I biked by a guy who was laying half out into traffic, and he looked like he was hot-wiring a car.

Co-op Term 2: Xtreme Labs

Xtreme labs was almost a rite of passage for everyone in my program: So many Waterloo students ended up working here, including me during my second internship. If I remember correctly, my interview question was "Given a long list of numbers, and a single target value, how do you iterate through the list in one pass to find out if there are two numbers that sum to your target value (in as close to linear time as possible)?" The solution was to take each number N as it is encountered and put an entry in some kind of hash table for the value TARGET - N. Then, for the rest of the numbers in the list, you first check the hash table to see if that number is already there. If it is, those two numbers add to the target sum.

TellApart

I'm pretty sure I interviewed with this company when they were only a few people (or perhaps a similar big data analytics type company). I got into a few rounds of interviews. On my last interview, I was asked to code binary search from scratch. I didn't do that well because I couldn't exactly recall the base case where the recursion stops (or equivalently the loop termination condition since it is tail recursive). I did not get an offer.

VMware

I had an interview with VMware and for the programming part, the interviewer gave me his laptop to code up the first question. I think the question was something about implementing a function that can concatenate two null terminated strings together in C. At the time, I had a habit of always creating a small make file for every project, so I could just do 'make', and I would see what the compile errors were (I like to check for compile errors very frequently). The interviewer asked what I was doing and didn't seem to be happy that I was spending time on this. The second interview question involved hash tables in some way (I can't remember exactly how). I spent a lot of time trying to explain a linear time solution that I thought was correct at the time. The interviewer didn't buy it, but I kept digging myself deeper. After the interview I realized I was completely wrong. I did not get an offer.

Co-op Term 3: OANDA

I interviewed with this company my second term and didn't get an offer. The interview question they had asked me was "How do you find out if there is a cycle in a linked list?". I didn't know of a good solution, so I didn't do well. The next term, I interviewed with them again and they asked the exact same interview question the next time I interviewed with them! This time, I had studied the solution, so I described it right away: You need a 'fast' pointer and a 'slow' pointer. The fast pointer will end up jumping over (or onto) the slow pointer if and only if the linked list contains a cycle. The company does FOREX market making, and I also happened to have opened a trading account with them as soon as I turned 19, so I already knew a lot about FOREX topics, currency pairs interest rate differentials etc. Because I got the interview question quickly, we ended up talking about tech in general, and got off topic about how hard it was to set up your own mail server. Eventually, the interviewer said 'So, what do we have to say to get you to come work here?'. This was where I did my 3rd internship.

I Don't Get Your Resume

During one of my interviews, it was clear that the person interviewing me was not the person who picked out the candidates to interview. After I came in and sat down, he scrambled to pull up my resume and try to think of some questions to ask me. I had made an interactive resume that was actually just a web page with images and colour, so it was different from what he was used to seeing. The first thing he said to me was "Umm... so... I don't get your resume." There was a long silence where he tried to think of questions to ask me, so I tried to summarize my work history etc. If you don't get someone's resume, why would you ask them to do an interview? I did not get an offer.

Zynga

I had an interview with Zynga back when Farmville was cool. During one of the group interview info sessions, the interviewer talked about how he met a woman on a plane who spent thousands of dollars on Farmville. Some of my friends told me that Zynga was evil. They did not give me an offer.

Pager Duty

I think I had an interview with this company on the same day that I did the 36 hour OS project, demo, interview marathon. Memory is very fuzzy here. Did not get an offer.

Co-op Term 4: NVIDIA

I applied for a position as a kernel software developer at NVIDIA, and during the interview the interviewer mentioned that I had a lot of web experience and that he knew another manager who was looking for exactly the experience I had. I never got asked any questions about C or kernel development, and instead they only focused on my web experience. I got an offer from them right away. I wasn't too enthusiastic about the position, and I sent an email reply to the offer asking if they could raise the compensation in the offer. I never got a response, but I eventually decided to accept the offer anyway because it was the best one I got that term. No one ever said anything about my asking for more money.

Facebook

I went to a 'meet your interviewer' for a Facebook interview that I had. There were a number of interviewers there who were each interviewing different groups of people. One of the Facebook interviewers there introduced himself as a Waterloo software engineering grad, who had been working at Facebook for 4 months. Since I took a break of a few years before going to university, this meant that this person was likely a couple years younger than me and had only 4 months more schooling in the exact same program as me, and 4 months of full time work experience. I was a bit surprised that they got people into conducting interviews so early.

I had interviews with Facebook for 2 positions. One was a 'data scientist' (or something like that) position. The purpose of the role was to look at raw data and use this to improve and monitor the product. The interview was not very technical, and involved a kind of 'debugging' session where the interviewer described the symptom of a problem, and I had to decide what questions to ask the engineers to find the root cause as quickly as possible. The problem he explained what a real one he encountered, where user interaction with poll questions had suddenly dropped. The point of the interview was to analyse how you think and how you would conduct a root cause analysis. I thought I did reasonably well, and never heard back anything on this position.

Another position I interviewed for at Facebook was a general software developer position. The first round of interviews was easy. If I recall correctly, the question was about finding duplicate elements in a list. The second round was a question about how to build a simple regex matcher. The regex matcher would support * (any number of) and + (one or more) and single character literals. I spent way too much time on this question and didn't get very far. The interviewer commented that my problem was that I was trying to find a linear time solution to the problem, but that this approach is wrong because the best case regex matching algorithm is exponential. It wasn't until recently that I ended up writing my own regex engine that I realized the interviewer was wrong, and that there is in fact a linear time worst case algorithm for this type of regex matching. Specifically, it is linear in O(mn) where m is the length of the regex, and n is the length of the string being matched. You can read more about this algorithm on this page.

I did not get an offer from Facebook.

Google

I sent in a resume to Google expressing my interest in having an internship related to the driverless car project. A week later, I was contacted by a Google recruiter. The recruiter said he had no idea what I was talking about when I mentioned the resume. We interacted a bit, but when I mentioned that I was looking for an internship, he said he was only looking for a full time employee.

Co-op Term 5 + 6: Amazon.com

I had 2 rounds of interviews with Amazon.com. During the first, my interviewer asked some questions that related to prioritising customer experience, and a couple technical questions: One was to write code that finds the set of all sub-sets of a set. I thought I did poorly on this question, but like always I just tried to maintain a good attitude and talk through what I knew and the interview helped me out a bit. I forget what the second interview was like. I got an offer from Amazon, and spent my last 2 co-op terms working on Amazon Redshift.

For the 6th co-op placement I was starting to get a bit tired of interviewing, so I decided to return for a second internship. Amazon was an interesting place to work, and I thought it gave me a unique perspective to work on an AWS product that operates at such a massive scale.

Electronic Arts

I think I interviewed with this company (it might have been a different video game design company). This was one of the few software development interviews I had that didn't have any technical questions. I did not get an offer.

Dodged A Bullet

There was a trendy mobile (or web?) games company that a lot of people interviewed at. I didn't get an offer from them, but a few other people from Waterloo did. After the co-op rounds were over, a Japanese company bought up this company and decided to cancel all new hires, and even get rid of some current employees (the interviewer too). Everyone who took the supposed offer was left high and dry with all the best co-op positions of the already filled.

Dashed Hopes

I interviewed with a gaming analytics company that seemed super impressed with my style of 'unique' resume. We talked very casually about our mutual interest in technology. They said they would definitely have a follow up interview as soon as possible and I felt that I had nailed the interview. They never reached out to me again.

Suits

During one interview, I was complimented for not wearing a suit.

Homework

For one interview I got, I was sent a large 'homework' question a day or two before the interview. Interviews typically fall on the same week as midterms, and we also still have assignments during this week, so I found myself in a position where there was no way I could complete the coding problem before the interview. I tried to inform them as politely as possible that there was no way I could complete this homework question in time, and it would be ok to disqualify me from the interview if they felt it was necessary.

Fizzbuzz

Fizzbuzz is a famous programming problem that you need to look up if you haven't heard of it already. If you get this question wrong, then the interview will tell his co-workers that you "can't even do fizzbuzz", and everyone will laugh. I'm pretty sure I got fizzbuzz once before I had ever heard of it. I think I might have done it incorrectly.

Latin

I had an interview where the interviewer asked "What is your favourite language?". My head wasn't in the right place at the time, and I said "Latin", and I went on to describe why I think Latin is such an interesting language. He was of course talking about programming languages. I didn't get an offer.

2 Minute Interview

At Waterloo, all interviews are conducted in the same building, and on one day I had one interview scheduled right after the other. The first interview was with TD bank, and the interviewers were late enough that I only had enough time to walk in and say hi before my next interview. I suggested we re-schedule and I never heard from them again.

What Is A Functor?

I had an interview with an anti-virus company who shall remain nameless. The night before, our group was working on an OS project and it looked like we would finish in about a half hour by 11:00pm. Unfortunately, it shortly turned into a disasterous all-nighter as we kept getting more and more tired, and breaking more and more stuff from being so tired. We also had to demo the OS at 8:00am, and my interview was a couple hours after the demo. I figured it wouldn't go well, but I thought it would be a fun challenge to see if I could hold myself together and do it anyway. During the interview, one of the interviewers asked me "How well do you know C++?", my response was "I know a bit of C++, but I don't know any of the advanced topics like functors and all that.". The 2 interviewers looked at each other confused and one said "Functors? That must be something from Java.". I got an offer, but I chose to pass on it.

How Much Time Do Companies Spend Reviewing A Resume?

I mentioned that I had a 'unique' resume because the resume system at Waterloo used to allow us to upload an HTML resume. My resume was just an iframe of my web site, and this allowed me to include Javascript libraries like jQuery, and also add tracking information that include IP address, length of visit, and screen click locations. In hindsight, this probably could have gotten my in trouble, but I guess everything worked out in the end. The cool thing was that I was able to do whois lookups on the IP addresses to tell which companies had actually looked at my resume, and how long they spent. Companies like Google, Facebook or Microsoft spent around 30 seconds to a minute looking at the resume. Some people spent as long as 2 minutes.

What Factors Determine If You Get Hired?

The most important factors that will decide if you get hired:

How badly they need people.
How many positions are available.
How many people applied to the position.
Whether they're hiring for this position based on talent or skill.
If they're hiring for talent and you happen to be talented (and you can communicate this).
If they're hiring for skill and you happen to have experience with the particular skill they want.
How good the interviewer is.

If you read the above list, you'll realize that the only things that are in your control are your ability to communicate how talented you are, and the skills you have. There are lots of other factors that you probably don't even think of, like how well the company is doing financially that will determine whether you get hired or not. I've heard of people being hired/not hired because of simple miscommunications where the interviewer confused the name of someone who was the worst candidate with the best candidate.

The 6 Secrets To Land The Perfect Software Job

There are thousands of things you need to know in order to be a good software engineer, but there are only 6 things you need to know to be able to pass 90% of software engineering interviews. Yes, I am exaggerating, but not by much:

1) Big O notation. Interviewers love this. Best-case, average case, worst case. Know this for common algorithms, and be able to explain why.
2) Hash tables. The solution to most interview questions is 'hashtable'. I'm not kidding (but you will be asked to explain yourself).
3) Binary Search Trees. Because O(Log(n)) is better than O(n) (well, asymptotically speaking).
4) Linked lists. If you can explain them, it demonstrates that you understand the memory model and have done more than memorize syntax.
5) Searching and sorting algorithms: Merge sort, sort stability, quicksort, O notation of each.
6) Graph Theory: Adjacency lists, Dijkstra's algorithm, Cycle finding.

If you look up these topics without ever having seen them before, it will seem overwhelming, especially since the interview questions are never the vanilla versions of the problems above. They almost always include some twist that requires you to understand them. After a while you keep seeing the same problems over and over, (and over and over and over) and at that point it becomes a bit less intimidating.

The Most Important Thing

If you take a step back and consider what the most important thing is when interviewing, I would say that your emotions and attitude are going to have a larger effect on your success than your intelligence. The main reason for this is that most people just don't bother doing lots of interviews because it causes them emotional anxiety. It is also a very ambiguous task that requires you to be disciplined and self-motivated. You have to spend hours searching through poorly written job descriptions on job sites that don't work properly. Many of the online applications have annoying 'signup' forms that force you to create an account for every application and ask for your last 20 home addresses. A lot of companies will get you to do work sample questions. Even after all of this, many of them will never get back to you so the benefit is uncertain. You feel like you might never get a job, but then you do multiple rounds of interviews thinking you did well but don't hear back? This gives people anxiety, so they just don't do it. It feels much more comfortable to spend years working for half of what you're worth in a place where people tell you what to do, than to spend a couple months filling out forms by yourself that may never be read, and getting your hopes up for the job you might not get.

The other aspect to the importance of your emotions is related to having a growth mindset. During your interview, your interviewer is likely to be testing the limits of your ability, and not just whether you meet a certain bar. Naturally, they will pick a problem that they think they know better than you do. If they stump you, or point your mistakes, the way you react is likely more important than the fact that you made a mistake. Someone with a strong growth mindset might appear happy that you've found something new that they can improve themselves on. Someone who feels devastated and insecure that there was a mistake found in their work might try to blame the problem on something other than themselves (the problem wasn't clear enough, not enough time etc.). It is a fact that you're going to have to work with other people who make mistakes sometimes. Would you rather work with someone who has a growth mindset, or someone who always feels inferior and insecure? By definition, the growth mindset people are going to grow into people who make less mistakes, so where they start out at is less important. The people who are 'never wrong' are never going to find anything to improve on, so they're just going to stay the same forever.

What should I Wear To The Interview?

Generally, you probably want to wear the same thing during the interview that you would wear after you get the job. It is currently commonplace to dress in relatively casual wear as a software developer, with two exceptions:

The banking industry
Places that are very old-fashioned

If you dress like you would at a fancy family dinner that's probably a good hedge. You can always ask the recruiter. I have heard of someone at Waterloo dressing as Batman to an interview before. If the interviewer is the same kind of weird as you, that might work out. I wouldn't count on it though.

What Should I Do Before The Interview?

I would recommend doing something social before the interview. Engage in some small talk, ideally just before, while you're waiting to start the interview. The ultimate goal of the interview is to communicate yourself well, and you'll probably be more nervous for the interview if you spend time alone. I think exercise would also be a good idea. Go do some dead lifts for an hour before the interview, and you'll feel a lot calmer and confident than if you sit in your room studying alone and drinking coffee.

What Should I Bring To An Interview?

Bring your resume, and personal cards with contact info if you have them. You may also want to bring a water bottle, and a pen/pencil with a sheet of paper. You probably won't need the pencil and blank piece of paper, but it sure feels great to have it right in front of you so you can just start writing down anything important that the interviewer says.

This might just be me, but if you take note of something the interviewer says by writing it down, I think it 'feels' much more engaged than if you pull out your phone and start typing it. The interviewer can see that you're not texting a friend on a piece of paper, but they can't see this when you pull out a phone. When someone pulls out their phone is a common social cue that this person is no longer listening to what you're saying because they're usually checking all their Facebook notifications, and if you do this during the interview you're likely to make that same cluster of neurons fire in the interviewer's brain. It's a small detail though, so it might not even matter that much.

Some Interviewers Aren't Awesome

Most interviewers are very nice and reasonable people. Some are jerks. Some are jerks because they were nice for the previous 10 hours of interviews, and you are the last interview of the day and they have a head ache, and are suffering from jet lag. Some interviewers say unprofessional things that could get them in trouble. Some interviewers are very hard-core and have no tolerance for small talk. I've gone to interviews where the first thing they say is "Ok, let's get right to it, so you have a binary search tree..." and they'll hand me a pencil and a sheet of paper. Some interviewers won't share your sense of humour. Everyone is different, and that's just the way it is. Sometimes you'll feel like you've made a new friend after the interview, and these are the places you want to work at.

How Many Interviews Will I Have?

For a technical position, it is common to have 2 rounds of interviews. A few companies do as much as 5 or 6 rounds. Some just do 1. It would not be uncommon to have a short 15 minute non-technical interview with a recruiter before doing the real interview that basically just formalizes your interest in the company, and allows them to figure out what you're applying for, and who would be best to interview. You can also ask questions like compensation or benefits, general questions about the company. Early in the interview process they are usually evasive in answering how much to compensate you because they don't know what you're worth yet. At this stage, you would want to confirm important stuff, like whether you're looking for an internship, or full time work. If there are any deal-breakers for you or possibly the company, you'd want to discover these in the pre-interview. Some hardware positions might require that you drive a company vehicle to multiple sites. You'll need a valid driver's license for this. Also, make sure the position is in the same country and town that you think it is in.

What Is A Programming Interview Like?

During a typical programming interview, you'll usually be asked about 2 technical questions related to one of the 6 topics listed above. The interview may start with 5-10 minutes of small talk, and then you will be asked to write code on a piece of paper, whiteboard, or on a laptop. If the interview is a phone or Skype interview, you will often write code in http://collabedit.com/ so they can see and interact with what you're typing.

The problems are often deliberately vague and don't have enough information to be solved as they are presented, because they don't really want you to solve the problem, they want to know how you approach solving problems. Asking for clarifications and confirming assumptions is exactly the right thing to do at this point (before you start writing lots of code and realize you did it wrong).

On the topic of asking for clarification, this one can be extremely important. There is a common interview question that I was asked in two different interviews: "Given two nodes in a binary search tree, return the common parent node." You might wonder what the desired result is if one of the nodes passed is the parent of the other node. I asked for clarification in both interviews, and each interviewer gave a different answer, which changes the solution. One interviewer clarified that the 'parent' node should never be one of the two nodes that were passed, and the other interviewer suggest that it should simply be whichever node was the parent one.

Every interviewer is going to be looking for their own (possibly pretentious) thing that they believe is the sign of a good candidate. Most won't care about syntax, and you should definitely start by writing pseudocode before you write a nicer solution. You can declare beforehand that you're going to write pseudocode to make the interviewer less likely to cut you off and complain about syntax problems as you're writing. Some interviewers will let you work on your own for a bit, and some will constantly pick at what you're doing before you have a chance to fix or explain it. Either way, just keep focusing on making progress and think out loud a lot. This will let the interviewer know that you're not stuck. When I say progress, I don't necessarily mean writing out perfect lines of code. Progress can be just drawing some representations of the problem. Even if you don't think it will help you, draw something. If you sit motionless in silence for long enough, many interviewers will assume that there's nothing going on in your head, and try to move on to something else. This is true even if you've making a lot of progress thinking through the problem. Unless you verbalize it (or draw it) the interviewer can't tell the difference between this and someone who has no clue. Start by re-stating obvious facts that simplify the problem that were specified in the question. This isn't a waste of time because it shows you know the difference between irrelevant and important information in the question.

If you come up with a solution, a common follow up is "Is there any way you can improve on this to make it better/faster?". This is an open ended question. It doesn't necessarily mean that there is a mistake hidden in your solution (although there might be). They just want to see where the limit of your knowledge is. If the question involves linked lists, you could talk about how caching changes the efficiency. If the solution involves hash tables, you can talk about collision resolution etc. You'll usually get asked about the asymptotic complexity of your solution here.

The Most Likely Reason You'll Fail The Interview

If you haven't interviewed a lot before, your first instinct is probably going to be to stop and think about the problem without doing or saying much. You need to practice thinking through problems out loud, and by writing them down. This is probably the most important thing you could do in preparing. Probably even more important than having a perfect understanding the algorithms. In the first 30 seconds after seeing the problem, you should say something like "Ok, so we know that X and Y, so we can do Z etc."

When to schedule the interview

Don't schedule before lunch (when the interviewer is hungry) or at the end of a long day (when the interviewer is tired). Studies show that people find the first and last item in a sequence is the most memorable. Picking a slot that is right after lunch or early in the morning is probably a good bet.

How Do I Pitch Myself

I'm going to divide all job positions into two broad categories: Skill based, and Talent based. Each position is going to be some combination of both, but I think this idea will help you make your resume and pitch yourself:

An example of a skill based role would be if you need someone to translate a live speech from French to English. You'll look over the resumes for someone who knows French. That's it. It doesn't matter if they are the most skilled linguist in the world, or that they can learn a language in 2 months. You need the speech translated right now and that's it. Even if they're not that great at it, you need that skill and you need it now.

On the other hand, if you need to translate an ancient language that no one currently knows, you probably want some who is talent based. You want someone who is intrinsically interested in the subject matter, because the task at hand is not well defined. How do you start the translation with no reference material? If you hire a skill based person who studied dead languages in university, but isn't interested in the task, they'll come in and put in 9-5 without making much progress, but it won't bother them. They just apply the skills they have, and if it doesn't work out, meh.

Some positions are seeking talent, and some are seeking skills. If you don't identify which they're looking for, you'll be at a disadvantage. I will claim that startups (say less than 20 employees) are more likely to be seeking talent. The tasks are all ill-defined. They need someone who can be a generalist, because there are only a few people doing everything, and nobody doing only one thing. As the company matures, the roles become more commodity like. Management stops caring as much about how much initiative you have, and just wants you do what they tell you and do it well and quickly.

Another perspective is the time-horizon of your employment. If the company wants to hire a contractor for 4 months, they don't have time to train a generalist in 10 different tasks. They are probably looking for someone who can just solve a temporary problem for them, so they would only consider you if you fit the keywords in the description. However, it is also true that companies will often start people out as contractors with a fixed term, and hire you if you do good work in the initial contract period. This makes it easier to fire a new 'hire' that doesn't work out because their contract ended anyway. If they are good, suddenly there is more work for them and the contract is extended (or they offer you full-time). There is also a sketchy area where companies try to keep 'employees' on as contractors for as long as they can to avoid compensating certain benefits, and because of tax advantages. The CRA is very likely to side with the employee in these cases.

If you're applying to an internship where the company's goal is to hire you long term, then they may tend more toward looking for talent than skill. Of course, after your internship ends, you might not come back, so the time they spent training you might not give them any long term benefit. Again, you'll have to figure out which they're looking for and in what proportion: Talent or skill.

How Should I Make My Resume?

Disclaimer: This is my opinion, your results may differ.

With reference to the previous section, if the position is talent based:

Unique resumes may be do best here, and doing something non-standard may help you stand out in a positive way. Having resumes with color, having a web site, side projects, being a free thinker, inventor, idealist etc. etc. The person looking at the resume, is more likely to be a founder, CEO, or a manager interested in building a team for the long term. They will appreciate someone who likes to challenge the rules, engage in healthy debate, take reasonable risks, and initiates tasks without being asked to do so.

If the position is skill based:

You have to have the required skill and have experience in it. Your resume MUST contain the keyword they are looking for, and it should as close to the top as possible. If you don't have that specific keyword, they'll move onto the next one. In this case, the person looking at your resume is more likely to be an HR (human resources) employee who is not personally invested in the success of the company, but they know they need to find someone who has specific skills. If you try to do something unique and different here, you might annoy the person looking at your resume, because they have to work harder to find the keywords they're looking for. The resume should be more standard, use standard fonts, standard headers, and be a standard file format. They are looking for someone who follows the rules, looks both ways before crossing the road, and doesn't talk back.

Some companies also put your resume into a database, and they will try to strip out all the text and put it in a database. This is so they can search through the resumes for the specific keywords you listed later. If your resume is formatted strangely, this process won't work properly.

Do I Need An Objective Statement?

If you write an objective statement like 'I want succeed at being successful and be excellent at...' then I would claim you're wasting precious resume space. A better use of that space is to list what your actual objective really is. Be specific. For example: "I am seeking a 4 month internship at <Company Name> as an embedded software developer beginning in early April 2016. I am interested in work at both your Waterloo and Toronto offices." This might sound like you're stating the obvious, but from the company's point of view, you need to be clear about what type of work you're actually looking for, when you can start, and which office you can work at. If you do a bunch of interviews only to find out that it is for a 4 month contract, but you thought it was full time position, then you'll waste a lot of time.

You might think that being vague would help you cast a wider net, but people who are decisive and know what they want are taken much more seriously. Knowing exactly what you want (and what you don't want) is a sign of maturity and experience.

Make Custom Resumes

A custom resume for every company is much more likely to be effective than a generic copied and pasted one. One term, I made custom resumes for 6 different companies: Facebook, Google, Twitter, Microsoft, A9 and SpaceX. Here is the one I sent to SpaceX. Looking back at it now, it has a typo in it, and a couple badly worded sentences. You'll probably miss mistakes too, but it's better than not even trying. Every one of them started with a similar opening statement where I tried to express how I was legitimately interested in the mission statement of that individual company. After I printed them, I had them laminated at an office supply store with the thickest laminate I could buy. Then, I Fedexed them to each of the companies. This cost me about $120 in total. That's a lot of money for something that might get thrown in the garbage, isn't it? It is, but when you think of the risk/reward it almost doesn't make sense to not do this. $120 is less than what you'll make in one day of work at a big tech company. If this gets you a job one day sooner, then you've already made back your money. Now consider the long term effects of higher salary, the better experiences you'd have, the better people you'd meet, and how much further you'd be ahead in your career. If you spent one day working at Google, in the worst case you can now be called a "former Google employee". Next time you hand out resumes, you can just hand out a blank sheet of paper that says "I worked at Google" scribbled in crayon and you'll still get interviews. Before you go spending lots of money on trying this, you should probably start experimenting small first, and see what gives you traction. Do something different that gets you noticed in a positive way.

So did it work? I never heard back from Microsoft, A9, and SpaceX. I didn't expect to hear from SpaceX because as a Canadian I'm ineligible from working in the US rocket industry, but I figured I'd try anyway and see what happens. I did get contracted by recruiters from Facebook, and went on to do the interviews above. I also met some of the people at Twitter who had received my resume, and they said that it really stood out and they liked it. This lead to the 5 or 6 interviews I mentioned earlier. As stated above, I think that the recruiter from Google reached out to me as a somewhat indirect result of the resume. I'll never know for sure. Although it didn't result directly in a job, it did help me get the interviews. I think it was definitely more effective than being found amongst the pile of traditional paper resumes.

What Else Can I Do To Help Get Software Jobs?

Have an online presence that is up to date. The interviewer is very likely to Google you, and if you don't have a Github page, Bitbucket, Linkedin, or personal web site, they may consider you to be extremely novice. Even a Github page that has a couple school assignments is better than nothing.

What Are Some Sites To Find Jobs?

Here are a couple:

Finally, events can be a good source of leads on jobs, but it really depends on the event. I've met both incredibly awesome, and incredibly sketchy (crazy) people at meetups. The sketchy ones usually take the form of people who think they're Steve Jobs #2, but don't have any revenue, funding, traction or users, and also they don't listen to feedback. They've usually been building the product for 10 years, and they mention this like it's a good thing. Take a bit of time to figure out if they are legit or not. Having said that, a good startup is probably one of the best possible places you can work.

Don't forget about your social network too. Go through everyone you know on Facebook, teachers, relatives, etc. and ask if they know anyone who could recommend you.

Where Else Can I Learn More About Software Jobs?

Read Hacker News frequently.

Conclusion

If you found this helpful, or there is something you'd like more information on, feel free to reach out to me:

info (at) robertelder.org

The Regular Expression Visualizer, Simulator & Cross-Compiler Tool Published 2020-07-09	$35.00 CAD Alan Turning, Ada Lovelace, Kurt Gödel Portaits	Why Is It so Hard to Detect Keyup Event on Linux? Published 2019-01-10	Myers Diff Algorithm - Code & Interactive Visualization Published 2017-06-07
Interfaces - The Most Important Software Engineering Concept Published 2016-02-01	Regular Expression Character Escaping Published 2020-11-20	How Do Regular Expression Quantifier Work? Published 2020-08-18	Overlap Add, Overlap Save Visual Explanation Published 2018-02-10

Why Bother Subscribing?

Free Software/Engineering Content. I publish all of my educational content publicly for free so everybody can make use of it. Why bother signing up for a paid 'course', when you can just sign up for this email list?
Read about cool new products that I'm building. How do I make money? Glad you asked! You'll get some emails with examples of things that I sell. You might even get some business ideas of your own :)
People actually like this email list. I know that sounds crazy, because who actually subscribes to email lists these days, right? Well, some do, and if you end up not liking it, I give you permission to unsubscribe and mark it as spam.