Your First Job Search as a Software Engineer

What to expect, how to prepare, and how to deal with the process

A year ago, I went through my first real experience looking for a job as an engineer after the small startup I worked in as a web developer was no longer financially stable. This is when I decided to move away from my comfort zone in Irvine (Southern California) to San Francisco. After a stressful (read: broke and rushed) couple of months of interviewing, I was finally done. Later, I met a couple of women at a workshop who recently graduated from their software engineering programs and were searching for advice before their first technical interviews. They wanted to know specifics about my recent experiences and what to expect for their first times going into their first interviews. After the workshop, I wrote them an email that offered tips, resources, and what to expect in their process. I copied the email below.

Note 1: There are so many shortcomings with the current system of technical interviewing, and I’m glad that there’s dialogue in the community about improving the process. This is mostly about how I dealt with the system I was currently in.

Note 2: I considered rewriting this to be in a format that’s more of a blog, and perhaps updating the information and cleaning up grammar here and there. In the end, I elected to preserve the tone and perspective of the original, younger version of myself.

I wanted to share this this because I struggled though many ups and downs and feelings of not being “good enough” making me feel inadequate and untalented at the time — don’t feel you’re alone in this. The takeaway here is that with some preparation and understanding of the process, you’ll be surprised with how much you can achieve. Give yourself a chance!

Here’s the body of my email:

Oct 2015

Hi ladies!

I’m sorry for this really LONG email.

Here’s my experience with my first round of technical interviews. To give you some context, I graduated in 2014 with a degree in CS, and I worked at a very early stage (first employees) startup for almost two years, but I had never had a “real” (non-early-stage startup, or bigger company) SWE job before. This was about to be my first real round of interviews. Because I only have one year of industry experience at very small company, I didn’t think many companies would be interested in me. Even though there were some that said no to me, there were also a lot that wanted to interview me, more than I expected, and even some I didn’t expect to hear back from. Although I thought that I didn’t have enough industry experience to interview (and I was no longer qualified for the “New Grad” postings), or land an offer at some of these “top-notch” Silicon Valley companies, I still definitely tried my best and got much further than I thought I would: on-sites and offers. So, if you’re coming right out from school or program, you’re in a LOT better position than I was! You have more time to prep yourself by the time you graduate, and you’ll know what to expect. So if I can do well, you can do better.

General thoughts and tips:

A prerequisite to all of this is to create the BEST résumé you possibly can, and maybe even a website. You can see my website* through the link in my signature and my résumé is on it as well. There are programs that companies use — especially if they get a lot of applicants — that automatically filter out résumé that are “bad” or don’t meet requirements. So make sure your résumé is clean, organized, typo-free and is specific.

1. Apply to as many places as possible.

If you look at some job descriptions, there are some that are very specific and list the technologies you need to know and use, and some that are more vague. If you feel like you roughly fit a job description, and requirements, even if it’s not exact: go for it! There is no reason not to apply for a job, just because you don’t necessarily fit the stack exactly. Many companies, not all, are fine with generalists and understand that good programmers can switch between languages and frameworks fairly easily.

2. PRACTICE.

You might think that being smart means you’re automatically able to answer algorithm questions and brain teasers. So you may think being smart is the key to passing a technical interview. That’s not the case. The biggest BIGGEST factor with how well you do in an algorithm-heavy technical interview is how much and how well you practiced. There are so many intelligent candidates, smarter than me, that fail to practice enough sample problems and aren’t able to solve the technical screen questions. For companies that make you go through a ‘solve this algorithm problem’-style interview, your best bet in passing is to have been exposed to similar types of questions before.

Let’s rewind for a second. Before practicing, make sure you know your basic data structures and algorithms. Trees, linked lists, hashmaps, sorts, BFS, DFS, time and space complexity etc. These specifically may not come up as a question itself, but a lot of questions will have you implement them or work with them in some way. But after you are comfortable, quickly move on to practice problems. Many algorithm style problems are all the same, maybe with a small change. For example, “How do you check if two numbers exist in an array add up to a sum k.”

I’ve been asked that question at least six times in six different interviews, but worded differently. You’ll start finding patterns with technical interview questions that repeat (use a hashmap, use a binary search, maybe recursion), so it’s important to be exposed to as many practice problems as possible, but also to understand the solution. If you memorize a solution to a problem but you don’t understand it, it’s obvious to any good interviewer. Being exposed to lots of practice problems also helps you build up your confidence.

3. More on practice:

Combining my first two points, don’t just apply to places you really care about. Practice everywhere, and be exposed to as many interview processes as you comfortably can (without being too stressed out). Apply to places that you wouldn’t care about if you get rejected, and don’t feel guilty about it. Remember this is a two way process. You are given a chance to show off why you should work for a company, and a company is given a chance to show off why you should choose them. There are plenty of times when I thought a company I applied to wasn’t super interesting, but after knowing more in depth information about their team, how they work, what they work on, it made me much more interested in working for them.

4. ON REJECTION: Do not be afraid of getting rejected.

This is difficult for everyone, including myself. Remember that it can happen for a lot of reasons. If you get rejected, then the biggest reason in your head may be, “It’s because I’m not good enough.” Wrong! This is not the case most of the time, or you’re oversimplifying it. Here’s some of the reasons companies might reject you:

1. “Culture fit”: This one is a bit controversial. Basically, it means that they’re not quite sure about your personality or how well you might get along with the team. This ideally shouldn’t be a problem unless you come off as disagreeable (or maybe they’re disagreeable), but it’s also very subjective (i.e. room for bias), which is what makes it so controversial. Just remember that you’re interviewing them as much as they’re interviewing you. If a company’s interview process or culture doesn’t seem right for/to you, then don’t feel like you need to impress them or act differently. Otherwise, you should practice being comfortable with being yourself, and being confident. I can offer thoughts on this later or as a separate topic :) Allow them to see how friendly and enthusiastic you are. Basically, put your best foot forward.
2. Not enough experience: Easily remedied by getting more experience. Wait a year or so and then reapply.
3. Other candidates matched the role better, or were more experienced than you in the role: If so, again, wait a year and come back. Improve your skills so that next time you’ll be the candidate that was better than someone else.
4. They received a huge amount of applications: If that’s the case, companies can afford to be choosy — they can lean towards getting the candidate with the experience they want, or the pay grade they want, or the personality they want, or the starting date they want, or that attended the school they think is better, or that matched their stack better. There’s nothing really here you can do because you’re trying to find the best match for you, and them the best match for them.
5. You don’t match their stack: Depending on the company, they might be okay with hiring generalists that have great fundamentals, but require a bit of learning or training time. Or, they might be able to be choosy (especially if they have a lot of applications), and decide to only interview those that match their stack completely. Don’t feel bad. Technology changes so much now, and it’s impossible to learn everything. You either have to learn a bit of everything, but not have a good grasp of any, or learn one but not have any experience in anything else. Aim to be somewhere in the middle: have a speciality or two, but explore and be curious about emerging technologies and frameworks.
6. You’re not familiar with their product: I’ve failed tech screens because I wasn’t familiar with the product. If they have two equally qualified candidates, they’re not going to choose someone who they feel don’t care about their product, because that means you might be more susceptible to leaving the company, and also it’s a tad unprofessional. Always be familiar with the company’s product before an interview.

The worst part of being rejected is that most companies won’t tell you why. I’ve only received a few emails that actually offered an explanation on why my résumé wasn’t chosen or why I didn’t pass the technical screen. Companies are like this so that it’s easier for them to send emails and also to minimize risk of legal issues. So, more often than not, you get a template “rejection” email that may or may not something to do with why you got rejected. Your best bet from here is to send an email asking for feedback, but don’t expect them to reply, as they’re not obligated to. Personally, I think it would be nice if companies had more than one rejection template (maybe one for “not enough experience”, one for “role has been filled”, and one for “technical stack mismatch”?)

Here’s a helpful picture about rejection, improvement, and your attitude from a cheesy Pinterest find:

I TOOK THIS IMAGE FROM A PINTEREST USER WHO ALSO TOOK IT FROM AN UNKNOWN SOURCE.

5. Algorithms and CS: A lot of people wonder if a company will ask you algorithms or more industry-type questions during the interviews. More often than not, companies will actually tell you what to review. I’ve gotten a lot of emails where I’ve been told to “brush up on my data structures and algorithms” and even got links to good resources on that. If they don’t tell you, you can ask during the phone call with the recruiter. In general, smaller startups that need people who can hit the ground running will ask you for more industry-related, application type of things (e.g. can you recreate this form in JavaScript?), while big companies with resources and time to train people can sometimes prefer candidates that can be generalists, and who have strong fundamentals or have more experience and can adapt.

Structure of Interview Processes:

This is the part of my email that will give you specifics on what to expect after you submit your résumé. This is the standard process, but it could be longer or expedited depending on where you live or your status with other companies you’re interviewing with.

1. Recruiter email

In this phase, a recruiter reaches out to you about your application, or, they’ll just reach out to you because they think you’ll be a good fit and found your résumé online. Thankfully, they usually email first before calling, to set up a time to call. Use a scheduling tool like Sunrise’s Meet** to reduce email back-and-forth, and to simplify your scheduling. Make sure to say something like, “To make scheduling easier, please feel free to pick out a time using this link or let me know if none of that works and I can figure out a better time for both of us” to ensure you don’t come off as ‘too busy’ for them. The main point you want to convey is: “I’d love to talk to you. Here, let’s use this so that we can both find a time that works for us ASAP.” This tool has saved me. I no longer need to manually add in every call and be afraid of missing them or writing them down wrong. I’m sure nowadays more recruiters have their own calendar links, which is great.

2. Recruiter call (pre-screen)

This is a call by (usually) a recruiter that isn’t necessarily an engineer (although I’ve gotten engineering managers before), and it lasts around thirty minutes. This is where you’ll get tired of saying the same thing over and over again. It took me a while to even actually stop being nervous about this part. Here are the common questions they ask you, so be prepared to have answers to:

1. Tell me a little bit about yourself: Have a short summary about yourself ready to recite a hundred times to about a hundred different recruiters.
2. Why are you looking to find a new opportunity? (If you have a job)
3. What are you looking for in a new role?
4. What are you making now and what kind if compensation are you looking for? Do your market research, use Glassdoor’s salaries as a resource. You don’t need to give specifics about your current salary, and you don’t need to give specifics about your desired salary. Wide ballpark is fine.
5. Sometimes, they might ask VERY basic technical questions, don’t be afraid of them as they’re super easy. Something like, “Why can’t you sort a list in less than O(n)?” (Don’t overthink it). I personally don’t agree with this practice, but I can understand why it’s done.

3. Technical Phone Screens

The recruiter will pass along your answers and then schedule a phone screen on a date convenient for you. At your phone screen, an engineer will call you either on the phone, Skype, or Google Hangouts and then ask you to type code or pseudocode to them using a code-collaboration website like Collabedit or Coderpad. They’ll give you one or two problems to solve.

Don’t be afraid to ask clarifying questions during technical screens. Asking questions is a good sign and sometimes an interviewer might ask you a purposely vague question so they can see if you will try to ask clarifying questions.

Don’t feel bad if you feel like you’re screwing up in a technical screen. You’re not, as long as you don’t freeze up. If you do freeze up, just take a breath and start your thought process over, or ask for a hint — they’d be happy to nudge you in the right direction.

Sometimes interviewers will also purposely ask difficult questions so they could see how your thought process works. Or sometimes interviewers are just not good at interviewing and they don’t make the candidate feel comfortable. I’ve personally experienced some interviews where the interviewer made me feel comfortable even though they asked a more difficult question. In those situations, I was able to answer it without much more help. However, some interviewers are just bad and did not make me feel comfortable, or it seemed like they just didn’t really care about what I was saying. So even though they asked me easier questions, I was not able to answer them completely because I felt rushed — like I was inconveniencing them — and discouraged because of their attitude. I ended up rushing my explanations so they can just get off the phone with me.

When solving an algorithm, have a process in your mind. This way, you don’t get stuck and you have steps to follow. Don’t underestimate the value of this. There are other more comprehensive articles about just this aspect of answering a technical question. Here’s a good one by Gayle Laakmann McDowell from CareerCup:

This one is from here: http://www.slideshare.net/gayle2/cracking-the-interview-skills-coding-soft-skills-product-management-handouts

If you’re a beginner at coding (or not), they’re not going to be very strict with you, so just RELAX and make sure you’re able to talk through your thought process. The most important part is to COMMUNICATE with your interviewer what you’re thinking so they can guide you towards the correct way, or they can think, “Oh, this girl is getting it.” The worst thing you can do is not speak and to just code in silence. Interview practice is half practicing to speak out loud and half solving the actual technical problem.

If you’re not a CS degree holder, it’s still important to get the basics of data structures and understand space/time complexity (sounds scarier than it is), but sometimes startups are actually more interested in you knowing your craft (JavaScript gotchas, front-end development, etc). Still, there’s no reason not to learn the technical names for certain concepts and ideas, and it makes things easier to explain to someone else as well.

4. ON-SITES:

A couple of days after your last (and sometimes first) phone interview with the company, they’ll let you know if you passed and invite you to an on-site. On-sites can be really long and tiring, but they’re not too bad. Just make sure you’re well fed and you slept well, it’s important (trust me). You’re going to meet a lot of people during your on-site so be prepared to answer a lot of questions and ASK a lot of questions. Make sure you communicate your ideas well to your interviewer. On-sites can last anywhere from 2–7 hours depending on the company. Sometimes, they will cut you off in the middle if they feel like you’re not a good fit. If that’s the case, good riddance, because you don’t want to sit through an interview for an extra few hours and not get an offer anyway.

Don’t make the same mistake as I did and schedule four on-sites back to back. It was incredibly draining. I didn’t have the luxury of time, but maybe you do.

5. Offer Stages: Yay!

(Note: I purposely didn’t go into offer stages and salary negotiation because I thought the email became too long.)

Resources:

Take advantage of the resources that are free online.

1. Read thoughts and opinions about the industry from people on Quora: https://www.quora.com/Technical-Interview-Questions
2. Algorithm Practice and Answers: LeetCode.com, HackerRank.com
3. Mock Interviews: Pramp.com
4. Job applications: LinkedIn.com, Glassdoor.com, Angel.co, Hired.com
5. Company culture and interview process reviews: Glassdoor.com has lots of them! But take them with a grain of salt.
6. Books: Introduction to Algorithms, Cracking the Coding Interview, Elements of Programming Interviews, and Programming Interviews Exposed

— — —

Sorry my advice got weak towards the end! I didn’t want to make this email incredibly long (even though it already is). Let me know if you have any more questions or want me to expand on anything here. Also, I haven’t proofread everything so I’m sorry if there’s mistakes, I just wanted to get it to you ASAP.

Best,

Bianca

One last thing I didn’t manage to include in the email:

The most useful skill to have in this entire process is to be able to judge yourself objectively and honestly — both the good things and the things that can be improved. Learn to understand when it isn’t your fault, and cut yourself some slack. This ultimately helps you with dealing with rejections, with difficult interviewers, with negotiations, and the competitive nature of the tech industry in general.

* Coincidentally my site is down as I switched domain name providers at the time of writing this.

** Sunrise has been bought by Microsoft and I’m unsure if they’ll still offer the Meet feature once they shut down and fully integrate. However, there are a lot of alternative products that provide the same capabilities.

Reflections:

Looking back, I wish I wasn’t so pressured for time and was able to take things a little bit more slowly. I had to travel from Southern California to San Francisco multiple times, switch hotels before going to my interview in the mornings, and worry about money. Also, I’m not an algorithms expert and am awful at answering algorithm questions under time-pressure — there were multiple times when I froze and had zero clue what to do. The biggest takeaway from my experience was that I gained a sense of validation and a lot more confidence. I also learned how to tell the differences between a good interviewer and a bad one, which is something try to remember when I’m conducting my own interviews.

Thanks for reading, and feel free to reach out to me on Twitter or on here for questions or feedback!