Under non-COVID-economic-recession circumstances, doing your homework and acing your CS classes is not enough to land a job as a Software Engineer(ing Intern) -- you need to hustle way beyond that. And in my last article, I shared how its especially crucial to adapt your hustle in order to succeed when the world seemingly ruins your chances of becoming a Sofware Engineer.
So, let’s break down the out-of-the-classroom steps of preparing for, applying to, interviewing for, and ultimately getting an offer to be a Software Engineer.
Here's the hard part: ensuring you have substance on your resume that is relevant to what you’re applying for. Frequent Resume Question #1: Is shows me your resume this enough relevant experience?
Answer #1: Is there at minimum two to three (for internship applicants) or three to five (for full time applicants) items that reflect actual coding work? Work experience, internships, personal/class projects? Clubs, organizations, or other relevant honors, awards, grants, scholarships, or affiliations? If there isn't, then no that's not enough. If there is, great, you could probably add more.
Frequent Question #2: Do I include (insert non-coding summer job or work study here) on my resume?
Answer #2: No, do not include more than one irrelevant summer/part time job on your resume when applying to SWE roles. A lot of students need to work while in school (👋 former Jamba Juice and Six Flags team member here) and since its your most recent one (or three) work experiences you feel like you should include it on your resume. It's not that that work experience is a negative thing, it's that that very valuable space your irrelevant work experience takes up would be better utilized by relevant experience.
Frequent Question #3: How do I get more relevant experience to put on my resume before applying for jobs/internships?
Answer #3: Don’t worry, there are plenty of options to fill the gaps.
Personal projects are the obvious option, completed alone or with peers (showcased on your Github as well).
But what if you don’t have any project ideas, or are looking to diversify your resume by learning a new language, or perhaps want to specialize to be more relevant for specific roles? You can...
Apply for relevant paid or unpaid work, such as a CS department tutor, lab TA, grader etc. or IT team member, at your university.
Pick a class/boot camp project you are proud of and put it up on your Github, then list and link it on your resume (bonus points if you build out more functionality than the project required). But, out of 2-3 projects on your resume, don’t use a class project for more than 1.
Complete a project-based tutorial or course, e.g. on Udemy, Linkedin Learning, or Coursera, and take it even further by adding custom functionality to the project. (Here are some course suggestions if you’re interested in learning Python, Web Development, iOS Development, Android Development & Java, Game Development, AR, or AI). Bonus points if your school has a partnership with one of these sites to provide discounts to students.
Participate in hackathons (e.g. check out MLH’s schedule) and coding competitions or challenges (e.g. these online platforms) and list the resulting projects, awards, or high-scores/ranks on your resume.
Pass LinkedIn skill assessments for your technical skills.
Contribute to Open Source code.
Volunteer your skills (e.g. building a simple website or app for free for a nonprofit or local mom n’ pop business in your hometown).
Now the easy part: polishing and ensuring your resume up to date. Here are the most important do's and don't's:
Oh, and don’t forget to update your LinkedIn -- some recruiters/interviewers will look at your LinkedIn, and LinkedIn supports one-click applications for many job postings that rely on your profile. Your LinkedIn should have everything your resume has, plus the other relevant information you couldn’t fit on one page, like LinkedIn Skills assessments, specific coursework, recommendations, your study abroad school, volunteer work, other work experience, etc.
How, where, and the frequency at which you apply matters. Apply the front-door way (AKA the brute-force way) and the side-door way to cast a wide and strategic net.
Apply through the company sites and LinkedIn postings, flag your LinkedIn profile as “open to opportunities”, and try reaching out to recruiters on LinkedIn. Sure.
But I highly, highly recommend you apply via platforms that companies pay money to use, and that will highlight you to those companies. Such platforms I have personally had or seen success with:
Other similar platforms and communities I’ve heard positive things about through the grapevine:
However many applications you've sent, it's not enough.
Even applying through strategic platforms, it's possible you've got to hit upwards of 50, 100, or 200+ applications before getting your first offer. The "law of large numbers" applies here: the more times you apply, the more practice you get, and the more likely you are to get questions you can ace. Maybe try applying to 2 a day, or sit down for 2 hours with a peer and apply to 50 all at once. The high volume can easily become overwhelming, and since no two application processes are identical, it's easy to lose track of deadlines and timelines.
Stay organized. I used a Google Sheet to keep track of what positions I had applied to, as well as my status in their process (e.g. submitted, need to do a takehome interview by X date, submitted test on Y date, recruiter emailed Z date, waiting to schedule an interview, phone interview scheduled for an upcoming date, etc.), and if/who I knew at the company, as well as whom I talked to during the process, such as recruiter or interviewer names. This also makes it easy to follow up if a promising application falls through the cracks, like say you submitted their take-home test 3 months ago, are prettty sure you passed it, and still haven't heard back, if you keep track you can reach out again. (True story, this happened to me and because I kept track, I was able to follow up and be flown to a final round on-site interview in Seattle).
Before or as you apply, prepare for coding interviews. Tech interviews are kind of like standardized tests, the SAT, ACT, AP tests, etc, in that yes, you need to have knowledge of the subject (algorithms, data structures, object-oriented programming concepts, coding fundamentals) but you also need to know how to "beat the test". Just because you could read a prompt and write an essay under normal circumstances doesn't mean you could do so in under 45min in a high-pressure SAT testing setting -- the same idea applies to technical interviews. You need to know your data structures, for example, but also how to efficiently answer a question on them out loud in a high pressure setting in under 30 minutes. The answer to how you get better at both is also the same: practice.
There are many resources to practice, check out sites like Leetcode and Hackerrank, as well as Cracking the Coding Interview. Some people make a goal to do one Leetcode question per day or X hours of practice per week, while others may have a couple of peers join them in a virtual study group that meets regularly to practice. Experiment with different methods and see how you work best.
So what do I mean by..."practice"? For technical problems, I recommend first trying problems on your own by doing questions from Leetcode, Hackerrank, and CTCI. The online problems will help practice for coding interviews, so try doing the ones from CTCI on a piece of paper, Google Doc, or whiteboard to practice for whiteboarding interviews.
As you do questions on your own, this sounds easy to wing but it is crucial to practice: TALK OUT LOUD . A crucial, simple thing that interviewees do wrong is not articulate their thought process out loud. Half of the interview is just seeing how you approach the problem, and when interviewees are quiet, that means interviewers have nothing to go off of. Seriously, talking out loud is key, and it’s uncomfortable for a lot of people, so you need practice doing it or you won't do a good job trying it in a high-pressure situation.
Leveling up your interview question responses When you get more comfortable and find yourself completing questions on your own with less difficulty, set yourself a timer, and try doing so under time limits, say 15min or 20min.
Another way to up your practice: practice technical interviews with others. Here’s a great Google video that demonstrates what to do in technical interviews (and thus in your interview practice). Other companies like Amazon have very similar structures they look for in both technical and non-technical interviews (knowledge bomb: the STAR method is a requirement, not a suggestion).
Practice 👏 with 👏 other 👏 people 👏 You can practice with:
Peers, friends, classmates, and fellow computer science club members TAs from your CS department (see if they'll do a practice session for a group) Mentors who have gotten SWE jobs or internships, or better yet, who have conducted SWE interviews before If you’re low on practice partners or want to change it up, ask in groups or online communities like TechLadies and to see if people can volunteer an hour of their time to conduct a mock technical interview with you (this method has an added bonus of potential networking).
DO NOT FORGET TO PRACTICE THE NON-TECHNICAL STUFF How you introduce yourself needs practice.
With so much to do to practice for technical interview questions, too often interviewees forget to prepare for non-technical questions.
You will be asked to "introduce yourself" or "tell me about yourself" at job fairs, recruiter tables, and in interviews. Practice your response to this. Don't think you need to? Try recording yourself answering either of these two. It's probably not as short, smooth, or as strong as you think it is. The top three common mistakes for an intro are: saying too little and wasting the opportunity to highlight things about yourself, taking way too long and going into too much detail about something, and starting out strong but finishing really weak or by trailing off. The way to avoid those mistakes? Practice.
This is your opportunity to highlight the things you think make you relevant, qualified, and interesting, and lead the interviewer into asking further about those topics, all in about 30s-1min. For guidance, here's an example of what to include in your intro:
Practice this enough such that you can remember what points you want to include and deliver a strong intro in 30s-1 or 2 minutes. Don't practice it to the point that it sounds scripted.
Experience-based questions need practice too.
These are the "Tell me about a time when..." or other questions asking about your experience.
Before interviewing, consider what your two or three most valuable experiences (projects, hackathons, internships) are, and what the most important aspects of the experience was with each of them.
Now, when you are asked a question like "Tell me about a time when you had a disagreement with someone. How did you resolve it?" or "Tell me about a time when you had to learn something new." or "Tell me about a project you are particularly proud of", you aren't thinking "oh crap, let me sift through every experience I have ever had and try to figure out the best answer to this question". Instead you are mentally choosing between your two or three most valuable experiences, which you've already reflected on, and picking which one is the best.
When you have picked the experience you want to focus on, how can you talk about it in the way that is most valuable for your interviewer? I highly recommend utilizing Amazon's the STAR method to answer experience based questions. When you use the STAR method, your answer includes the Situation, the Task at hand, the Action you took, and the Results. Interviewees commonly spend waayyy too much time talking about the Situation and the Task, and don't focus enough on the Action they actually took and the Results it yielded.
Like technical questions, you shouldn't wing these. So pull up some experience based questions, like Indeed's list, or Cracking the Coding Interview's behavioral questions section, and practice your answers using the STAR method out loud to yourself and/or with someone else.
Congrats on getting your first offer! But your journey to get a job as a SWE is not over yet.
"But Vanessa, this is my dream company, of course I'll accept...I don't want to interview anymore...I just want to be done....It's a lot of money, I should just take it..."
NOPE. Even then, keep going. Why? Because you might get another offer, and if you do, you have a much higher chance of negotiating a better offer from either company by leveraging the offers against each other.
Hi [Recruiter], thank you for your efforts to provide the offer with [team/company]. I am excited about [why you are excited to join that team/company/product/tech stack]. Unfortunately, I just received a competitive offer from [other company] which is making me hesitate to accept this offer in its current form. As I mentioned, I am really looking forward to working at [company], but in order to accept an offer I would need to see a total compensation of [5-10k more than the total compensation of your current or competing offer, whichever is higher]. Thank you for your continued work on this, and I look forward to hearing from you.<
If you don't have a competing offer, then remove the text inside the ** ** and replace it with "I am hesitating to".
While you can propose total compensation or specific amounts for compensation types, it's important to be specific with a number: "people who are specific receive a greater increase in compensation than those who aren’t" according to a survey by LeanIn.
Some people like to include the following before ending with a thank you
If we are able to meet that target, I would feel comfortable signing immediately.<
As extra incentive or assurance to bring a higher offer, this can help and doesn't hurt, but only include it if you mean it.<
Other people like to include data from the industry regarding compensation for your role or experience level. I would recommend doing your research and knowing your worth to inform the amount you are asking for, but I recommend not including that information in this conversation.
Once you have final offers in hand, its time to make a decision holistically. Compare the offers and all of their benefits (mentioned above). For offers in different cities or states, calculate what your realistic take-home paycheck would be by considering cost of living and income tax (WA and TX have 0% income tax, CA is around 9%, NY is around 5-6%).
Ultimately, compare both the numbers and the important qualitative aspects like where you will be happy, challenged, in a healthy environment, interested in the work, and have opportunities to grow in your career, and make the best decision for YOU. Sign and accept the offer you decide on, and once it is signed and confirmed, let your other offers know you respectfully decline.
You should polish up your resume to get in the door, cast a wide and strategic application net, stay organized, and practice as much you can on your own and with others so you can succeed once you’re interviewing, and keep interviewing and negotiating until the digital ink on an offer is dry.
Don't just hear it from me though. Listen to other people's advice and notice the common themes, like this video on How to Get a Job at the Big Four: Amazon, Facebook, Google, and Microsoft. The road to landing an SWE role is not easy, but at least it's fairly straightforward.