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!
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:
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:
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:
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:
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.
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.
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!
One of the snippets I found - the majority of my scraps were on random pieces of printer paper that I never actually keptIn 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.
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.
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 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.
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:
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.
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.
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.
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.
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.
“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 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:
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.
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:
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.
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