Debugging the Tech Recruitment Process
July 09, 2020
Categories: interviews, career
Word count: 5465

Resumes, technical interviews, and coding challenges - oh my!

When I completed my summer internship at Apple, I received a full-time return offer, and I really wanted to accept right away. However, I have always felt insecure about my technical interviewing skills. I felt like the interviews I'd done before weren't as vigorous as I expected, so I wanted to push myself out of my comfort zone and do some job hunting before accepting an offer.

I dedicated about a month to applying, preparing, and interviewing for a couple positions that I was interested in, and ended up with offers from different-sized companies, including startups and unicorns. I won’t be discussing the interview process of any specific companies, but rather some general observations from going through quite a few of them. Although I ended up accepting my return offer back to Apple, this process gave me more confidence in my own abilities and allowed me the opportunity to learn more about the tech industry recruiting process.

I'll be discussing some of the tidbits of knowledge I picked up while preparing for my interviews, and talk about some of the resources that helped me in the various stages of recruitment. This all took place around August to October 2019, so it may be slightly different in the future (especially due to the Covid situation), but hopefully reading about my experience can help you out a bit and you can get the gist of what to expect!

Table of Contents

Resume and job applications

I began applying for several software engineering and development positions through a mixture of personal referrals, career portals on websites, and through recruiters on LinkedIn. I actually had quite a bit of success, with most responding within one or two weeks to schedule an initial recruiter call.

The resume is the most important part of this step: it will often be the only thing a company uses to decide whether or not to give you an interview, and you really only have around 30 seconds to catch a recruiter’s eye. I would highly recommend polishing up your resume and asking for feedback from trusted friends and people who review resumes.

Over the summer, I received an invite to attend Facebook’s Intern Summerfest, an event at their Menlo Park headquarters. Aside from the free food, there was also a resume review opportunity. I received some excellent advice:

  • Use a format that is clear and easy to find the information needed. Spacing is really important so don’t try to squish a lot in if it sacrifices readability.
  • When talking about confidential projects, as well as your work in general, emphasize its impact rather than just a description of what was done. This is something I’m not that great with, but I’ve heard this piece of advice a lot.
  • Put the GPA on unless it is terrible (< 3.0). A lot of reviewers will just assume that it’s not great if you don’t have it on the resume. If your in-major GPA is higher than your cumulative GPA, you can elect to put that on instead.
  • Rearrange the order of your sections. If you have relevant work experience, you can put it above your education (if you’re using a one column approach). Make sure that your resume emphasizes your strengths, and that it’s the most eye-catching parts that are the important ones.

My resume consisted of my two Apple internships, a computer science teaching assistant position, and my first co-op position as a test engineer. I also included my involvement with the Capture the Flag team to demonstrate an interest in computer security, as well as my leadership with UBC Hacks and nwPlus. I purposefully chose to put lower level projects on my resume as well, because I was aiming for work relating to operating systems or networking, but I put a full-stack web application for variety’s sake. Here’s what it looked like at the time:

Debugging%20the%20tech%20recruitment%20process%20resumes%20tec%2072b5df8fbb8546638d18db2652df5d63/FC54C6BE-ABFF-4C2A-B248-C0C7F7477FB0.jpeg

Try to craft a “story” with your resume. What I mean by this is: design your resume for the job that you want. If you are looking for web development roles, make sure that is emphasized in as many parts as possible. With my resume, I wanted to be an engineer on a lower-level project, with opportunities to develop skills in leadership and security.

My resume at the time was by no means perfect. In fact, I kinda dislike it now, but this tends to happen whenever I look at something I’ve done for more than two months. I did recently redo my resume to make it more simple and clean, and added in more projects that I felt showcased my skills, such as a compiler and operating system that I built for classes.

If you’re looking for more in-depth resources on resume writing, check out these ones:

  • How to write a killer Software Engineering résumé: Aimed specifically at software engineering resumes, there’s a lot of detailed information and examples on the sections you might want to have. There are things in here that can be debatable (for example, I don’t put a phone number on my resume anymore), but there is a lot of great advice.
  • The Resume That Got Me Into Google: Video where a software engineer goes over the pro’s and con’s of his own resume and discusses things that were effective and things that could be improved.
  • Show us the resume that got you the job (Reddit): I like to look at examples of other people’s resumes, whether it be on Reddit, Facebook groups, Twitter, etc. When you look at a new resume, you can quickly evaluate whether their layout and writing is effective by quickly skimming and seeing what “story” is crafted by it. By doing this, I learn about the best methods to drawing attention to certain skills, through layout or descriptive bullet points.

Recruiter chat

The first contact I had with most of the companies was through a chat with a recruiter. Typically, these were short (under 30 minutes) and quite casual. The recruiters are merely looking to learn more about what you’re looking for, your background, and tell you about some next steps in the recruitment process.

That being said, I do remember having a recruiter ask me some rapid-fire trivia-like questions like:

  • What does object oriented programming mean?
  • Name some data structures.
  • What is a binary search tree?
  • What is the observer pattern?

The questions weren’t difficult, but if you’re not prepared, it can catch you off guard. The recruiter may also ask you for salary expectations. I did not disclose any specific numbers I was expecting, and merely said that I’d be flexible if the position is a good fit. They’re asking this usually to make sure that you’re both on the same page so no time is wasted for either party through the multiple interviews you’ll probably have to do.

Recruiters want to help you! So don’t be afraid to ask questions, whether it be about the company, position, or the interviews.

The technical interview grind

Aka Leetcode. Lots and lots of Leetcode.

I knew that doing coding problems during interviews was one of my weakest skills. I get really anxious, and especially in such a high pressure situation, I knew it would be hard not to panic when given a problem I wasn’t familiar with.

I approached this similar to how I deal with examinations at school. To try to eliminate the jitters, I practiced a wide breadth of problems. This way, I would be familiar with a large variety of problems, so the likelihood that the question given in the interview was similar to one I’d seen before was pretty high.

I have pretty good foundation knowledge on algorithms and data structures through my classes at school, so I didn’t elect to review the topics before diving right into the questions. Like studying for my exams, I prefer to do practice questions to test my knowledge and only use conceptual studying of the theory to fill in any holes that I find while working through the questions.

However, if you are rusty on the topics, I would recommend picking up a copy of Cracking the Coding Interview. The chapters focus on topics like arrays, strings, and trees, with an explanation of the data structure or algorithm, and then practice questions. You can also find solutions to the questions in a variety of programming languages online, such as Python.

I used Leetcode to find practice questions. I did pay for the Premium account that I shared with a couple friends, mainly so that I could access the top questions for each company. Since I had a Facebook interview scheduled, I focussed on the “Top Facebook Questions” and sorted them by frequency. I then worked from top to bottom, but if there were questions that were too similar to the ones that I already completed successfully, I skipped them.

Debugging%20the%20tech%20recruitment%20process%20resumes%20tec%2072b5df8fbb8546638d18db2652df5d63/4B5D0B29-EF55-4CCF-A19E-992B80943B82.jpeg

I did the questions on paper (or with the iPad and Apple Pencil). This might be surprising since the format of the first round technical interviews are usually via Coderpad, so you’d be typing your answers; however, I prefer being able to draw out diagrams, scribble down examples, and write down code snippets to try and understand the question.

When I’m doing questions directly in code, I find that I tend to skip a lot of the thought process that I find essential for solving the problems efficiently, and focus too much on syntax and “nice looking” code. Writing on paper is also similar to working on a whiteboard, which tends to be common during the final round. I actually purchased a whiteboard and put it up in the apartment to practice in an interview-like environment, but this is optional!

Debugging%20the%20tech%20recruitment%20process%20resumes%20tec%2072b5df8fbb8546638d18db2652df5d63/FB3561E4-45DB-49DE-BE06-99389271E623.jpeg

One of the snippets I found - the majority of my scraps were on random pieces of printer paper that I never actually kept

In the next section, I discuss how I approach any coding problem. I follow these steps while practicing Leetcode, Hackerrank challenges, Coderpad interviews, and in-person whiteboard coding problems as well.

Steps of doing a technical question

  1. Read the question. Then read it again. Make sure you understand the question fully, or else you might start working on a solution before realizing you completely misunderstood an aspect of the problem and have to start over.
  2. Write down some examples of the input to output expected while re-reading the question. Make sure to think about the edge cases and some of the trickier examples. I start with the simplest example possible, and then try to work on larger ones. By doing this, I can quickly see if the question can be solved with recursion/iteration if there is repetition. If the question gives examples, work through the example input, and try to figure out how they got to the output step by step.
  3. By completing the previous step, you should have a general concept in mind to solving the problem. If not, I would work through some different examples. Because my boyfriend was nearby, I would talk to him to try to solidify the concept. Although he usually had no idea what I was even saying, I found it helpful to vocalize my thoughts. In addition, this is good practice for the interview, since interviewers will expect you to be able to speak about your thoughts while you’re doing the question.
  4. Write out the solution in pseudocode. Don’t worry about syntax errors or efficient code. Just try to get a working solution, and you can clean up the code later.
  5. Work your simpler example inputs into your solution, and make sure that it’s producing the output you expect.
  6. Try to make your code as efficient as possible. Try to find ways to reduce the runtime.
  7. Write out actual runnable code. If it’s faster, you can type this out directly into Leetcode.
  8. Run the code and see if your answer is correct. If it is, great! See if the runtime can be improved. If it isn’t, look at the examples and try to see where they failed. Are there certain cases that you haven’t accounted for?

If you’re stuck: I wouldn’t spend too much time pulling out your hair if you feel as though you aren’t and won’t be able to make progress. This is a good time to take a peek at the solution. Preferably, you shouldn’t be reading the entire solution — only enough for you to get unstuck. If you’re studying with a friend, it’s more helpful for them to read the solution, and for you to explain your thought process so far. They can then tell you if you’re on the right track, and give you just the right amount for you to get on your way.

Resources for programming questions

I’ll list some resources here that I used to study for coding questions. Some of these I had studied beforehand (like the textbooks) so I didn’t use them in the grind for interviews, but I had already read them before and found it helpful.

Hackerrank and coding challenges

Hackerrank challenges are going to be really similar to Leetcode problems. There will be some unit tests that you'll have to pass - usually only a very few of the input/outputs of these are shown to you; the rest will be hidden, so it's your best bet to add your own tests and not rely on the given ones.

Some companies will send these, some won’t. I actually really dislike these coding challenges because you can be really close to a solution, but because of a small thing you overlooked, you fail. And there’s no way to explain your thought process and the progress you were able to make. In addition, with the time limit, it puts a lot of pressure on perfect code, which for me, means I will make more mistakes.

When I’m doing these, I follow the same steps as Leetcode practice, except sometimes I’ll skip the pseudocode if I’m running tight on time. I would still put a lot of focus on thoroughly understanding the question before working on any code.

Sometimes these questions are hit and miss. Some companies send challenges that are pretty basic and quick to do, so it’s not that elaborate of a question. These are generally just to test that you can actually code and that you know very basic concepts like arrays or strings. Some challenges, however, can be pretty novel concepts that may be hard to understand fully before the time starts running out. These can take over an hour to do! Essentially, these will be similar to a take home assignment, but you’ll have the ability to run your code via the Hackerrank interface.

Don’t be too hard on yourself if you can’t pass all of the Hackerrank challenges. I definitely did not pass all of the ones I got, and it can be very frustrating. You will have many more opportunities, so it's not the end of the line even if you fail a few.

Take Home Challenge

I didn’t see too many of these, but I did get a few take home assignments. These are generally used in replacement of the Hackerrank stage. They’ll give you a problem with specific constraints, item actions that you’ll have to complete, and you’ll submit your code to them when you’re done. Usually, you can take as much time as you want on it, but some companies will give you a guideline as to how much time they expect you to have to spend.

Here is an example of a take home assignment from Cloudflare for the Summer 2020 Systems internship:

Debugging%20the%20tech%20recruitment%20process%20resumes%20tec%2072b5df8fbb8546638d18db2652df5d63/AEA788F3-D70C-437A-BD8F-572814137833.jpeg

I believe that these kinds of assignments focus on clean, readable code. Most are evaluating how well someone can work with your code, so I try to write good comments and name variables and functions well. Generally, just have good coding practices so that you won’t give anyone headaches while reading your work.

You can also submit, along with your code, an explanation of some of the design choices you may have had to make. This is a good opportunity to show that you can evaluate the pros and cons of different approaches, and talk about some alternatives that you could have taken for certain advantages.

I prefer take home assignments to Hackerrank challenges, because there’s less pressure and the projects can be pretty fun sometimes. But they can be quite time consuming, especially if you’re a perfectionist and want to do the assignment as well as possible.

Virtual technical interview

The next step is usually a technical interview through a video call, via an online collaboration coding environment such as Coderpad. This will allow the interviewer to watch while you code, and also sometimes work on the code themselves. They will usually paste in the question into the Coderpad so you can read it, or they will verbally state the question.

It is important to ask clarifying questions! Sometimes interviewers are looking to see if you can ask good questions to understand the problem, so don’t be afraid to ask about anything if you’re confused.

As usual, I follow the same steps as listed above. Try to talk through your thought process to your interviewer. When you’re working through examples, you can try to explain how and why your example input creates the output you’re expecting. Feel free to write down those examples in comments, and then turn them into unit tests if possible. By having these unit tests, you’ll be able to see the output of your code right away, and save you time in the long run when you’re debugging. Plus, interviewers love seeing good test coverage. Make sure that you’re thinking about the edge cases as well!

One thing to keep in mind is that even though you’re in a coding environment, it’s still good to think generally about the problem rather than jumping straight into the code. I like to write pseudocode in comments first, and then write the code once I run my examples through the pseudocode and I’m confident that the solution works for most cases.

I usually explain my pseudocode out loud to the interviewer, running through the solution generally. If you’re lucky, you’ll get some feedback straight away — most interviewers will let you know if you’re on the right track, or if there may be some issues you want to think through before writing running code. Sometimes, the interviewer can be not as receptive as preferred (and literally not say anything), so I usually just try to brush it off and continue with my solution.

There’s usually one or two questions within a one hour period, with some time at the end remaining for your questions. This is a good time to ask about engineering questions, such as engineering practices or methodologies, if your interviewer is an engineer in the company.

On-site interviews

If you successfully pass the interview call, the next and final step usually involves an onsite interview (sometimes a couple of them). The company will fly you out to their locations for interviews lasting from half a day to a full day, where you can expect to speak with engineers and managers. Depending on the company and position, these may be your coworkers, so be sure to make a good impression!

Onsite interviews can have a variety of different formats. I have gone through around 3-5 of these interviews (or a combination of them) for each onsite. I’ll discuss some of the ones I’ve personally experienced here. For each interview, I tried to figure out what kinds of skills they were looking to evaluate, so I wrote some of my thoughts here.

Coding Questions

This will be your typical technical interview with a coding question, similar to the one mentioned in the virtual technical interview section above. Most companies will expect you to do this question on a whiteboard rather than on a computer, although some may allow you to work on your own laptop that you’re accustomed to (or they’ll provide one if you prefer).

I actually prefer working on questions on a whiteboard rather than in a dev setup, since it reminds me to not tunnel vision on syntax. You’re also free to draw diagrams and examples if you feel like that would help you out! For example, I find it useful to write out various example strings if the problem involves string manipulation.

Objective: To see how if your coding skills are as good as they expect from your resume and experience, but also to see the way you approach novel problems. They also want to see how you think about a question before the coding starts, such as your willingness to ask clarifying questions, thinking about edge cases, and writing tests. You will also want to write efficient code and consider the runtime of your algorithms.

Debugging

One of the most interesting interview formats I had was a debugging exercise. I was given a repository to clone on my laptop, and a short explanation on the expected output of running some tests, which are currently failing right now. I was then told to debug in order to make the tests pass.

Before doing anything, I theorized about areas that could be problematic in causing the wrong output. This demonstrates an intuition about how the code works and how you think of the system as a whole.

Using the IDE, I clicked to the function that was being used in the unit tests. After reading the function name, I said (out loud) what I expected the function would do. I find that this lets me be less biased when reading the actual code, so I don’t just read it, glaze over it, and kind of “assume” it’s doing the right thing without looking at the entire picture as a whole. Then, I read each line of the code and think about why it’s doing something a certain way. I made sure to verbalize so the interviewer can follow my thought process. By doing so, I was able to locate certain areas of the code that was “suspicious”, as in maybe they held the bug.

From the feedback I received for this interview, I think this was my weakest one, although I still passed (and got the offer). It took me some time to find the error, but once I got a small hint to where to look, I was able to fix it pretty quickly.

Objective: To see how you work with large projects, which is going to be very extremely common in industry. They want to see how well you pinpoint where bugs are located, and how you go about doing that. Be sure to be thorough but efficient in stepping through the code. You also want to demonstrate that you are able to read the code and understand what it's doing.

Behavioural & career goals

“Tell me about yourself. Where do you see yourself in 5 years? What are your hobbies?” These questions are the types you can see during behavioural interviews. I find that these interviews most resemble a pretty casual chat, and I’ve had most of these done with the hiring manager or an engineering manager if the position is a general new grad role.

Questions will be aimed at genuinely learning about your style of work and what you may be interested in. You may also be asked career questions, such as the dreaded “Where do you see yourself in X years?” You can also be asked questions like “Why do you want to work at this company?”, so you may want to research the company’s values, engineering theories, work environment, etc. so you can be prepared to talk about it.

I don’t think there is really a way to prepare for these other than rehearsing answers if you think you might be too nervous to come up with on the spot. I never really practiced these since I feel pretty comfortable having these types of interviews - I really just treat it like a chat. Plus, you are evaluating the company just as much as they’re evaluating you. If you’re still feeling nervous, I’d recommend using Glassdoor to see if there are some common questions being asked in interviews at the companies, and thinking of answers to those beforehand.

Objective: To decide whether you’re a good fit for the team or role, based on your personality, career goals, interests, etc. This can be evaluated pretty subjectively; you want to have a good impression and make sure that you come off as pleasant to work with. I find that you yourself should also be evaluating whether the team or role is a good fit for you. If this is your hiring manager, you want to make sure that you’re able to have good discussions with them, since 1 on 1s will be very common once you start work.

System Design

System design interviews are also pretty common. I’d say it’s about the most common interview type after the coding questions. They are very similar to brainstorming sessions, and seldom actually have a 100% correct answer. Instead, the interviewer will talk about a goal of building a complex system, and you work through various components in that, usually collaboratively with the interviewer.

Some examples I’ve had to do usually relate to building a product of the company on a smaller scale. For example, building a simplified billing system for Stripe. I would recommend being familiar with the general gist of products that the company builds, since the system design interviews may likely be a project very similar to one of those. It’s also good to demonstrate that you’ve done your research in the company, and makes a good impression.

This would be a really long section if I went in depth into solving system design questions since they can be quite varied in their depth and breadth. Instead, I’ll link here to some other resources that I found helpful in studying for these:

  • System Design Cheatsheet: Some more thorough steps to take while thinking about the design, along with questions that you should be asking at every step. There are also topics in here that you should try to get familiar with, such as security, load balancing, concurrency, networking, etc. I’d highly recommend giving this a read and memorizing the general steps and topics to mention, so that you aren’t confused about what to talk about next during the interview.
  • System Design Interview Questions - Concepts You Should Know: A variety of different topics you can get familiar with. I did learn quite a lot of these in my computer networking and operating systems classes, but I will confess that I am not extremely familiar in depth with all of them. It would, however, be nice to be able to discuss the trade offs in relation to some of these topics at least. For most entry-level or new grad positions, I find that they don’t expect you to know all of them.
  • Crack the System Design interview: Great tips and tricks to tackling the system design interview, with examples of questions and responses.

Objective: To evaluate your experience working with large-scale systems and how well you can discuss the trade offs of the various options you may come up with. You want to demonstrate how well you can think about the scope and space of the problem. You also want to show that you can think about the bottlenecks in the system and how you could possibly mitigate them. This interview is a good opportunity to show your knowledge outside of just programming, and bring in your experience with computer networking, security, operating systems, etc. There’s really a lot of topics you can discuss during system design interviews.

Offer

If you’ve done well up to this point, you’ll probably receive an email from the recruiter (sometimes hiring manager) asking for your availability for a call, where they will extend you the offer verbally. Congratulations!

An offer (at least in North American tech companies - unsure about other places) will usually consist of the followings components:

  • Base salary: Usually paid annually, although it is possible for it to be an hourly salary especially for new grad roles.
  • Signing bonus: One-time amount that you will get usually a month after you start work. Typically, you’ll have to stay employed for a certain number of months in order to keep the full amount, or else you may be responsible for paying it back.
  • Restricted stock units / equity: Companies will offer stock in their company as part of your offer. You can read more about the differences between RSUs and stock options in this article.
  • Discretionary bonus: Some companies will give bonuses (ie. 10% of salary) annually based on individual or company performance.
  • Relocation bonus & package: You may be eligible for a lump sum payment for relocation, as well as a relocation package that could include temporary housing for when you moved, a rental car, furniture allowance or moving service, advisor to help with house hunting and logistics (ie. applying for driver’s license), or tax consultation services. You will also want to know about the company's plans for work visa and authorization. In the US, you'll need company sponsorship for this.
  • Benefits: Each company will have different benefits, including free lunches, 401k matching, health & fitness stipends, discounts, etc.

Negotiation

Even with the offer in hand, your work isn’t done. You definitely want to try negotiating. I know this can be difficult, especially if you didn’t expect to get the offer at all. Some people may also worry that their offer can be retracted if they try to negotiate, but this is highly unlikely, and if this does happen, the company probably isn’t a great one to work for anyways.

I highly recommend searching for offers from the same company or similar ones. I consulted with friends, and also looked on levels.fyi, which is where you can see the offers obtained by people in various levels and pay bands. Keep in mind that these offers are for particular locations, so it can differ if your location has a different cost of living.

I read an article called Ten Rules for Negotiating a Job Offer by Haseeb Qureshi to learn about offer negotiation. This is a very comprehensive resource and extremely helpful. He talks about how he was able to negotiate his offer from Airbnb, as well as how to handle to various scenarios you may encounter, such as exploding offers.

You can negotiate more than just the salary - be sure to look at the offer as a whole. If you’re unable to raise the base salary, try negotiating for more RSUs or a larger signing bonus. I know it can be difficult to ask for more (especially on what you believe to be a good offer already!) but it's very important to at least give it a try.

Wrapping Up

Wow, this was a really big post.

One final piece of advice I can leave here is that it’s okay to fail interviews, or not get callbacks. It happens to everyone! I find that when I stress and think that “it’s my only chance!” I get really anxious during the interviews and do poorly. I think it’s normal to have good days for interviews, and some bad days. It also really depends on the interviewers, company, and so many other factors that it’s really not helpful to get caught up about a poor interview result. In the tech industry, we’re pretty lucky to be given quite a lot of opportunities, so one failure is not the end of the world, and you will get through it.

Good luck with your job search and interviews! I really hope this helped someone out 🙂 If you have any questions, feel free to reach out to me!

Thanks for reading! If you enjoyed this, feel free to connect with me via