How I Landed my Software Developer Job Before Graduation

I’ve always been the type to plan everything. Also as a computer science major, it was very common for students to land a full-time job before graduation. It was crucial for me to have a job before I graduated, so I didn’t have to worry about it later. It wasn’t an easy process. In fact, it was quite tough, but I’ll share my experience and some tips.

For some background knowledge, I attend a university in Canada with 20 months of experience from various companies as a quality assurance engineer to a software engineering developer. I also have a few projects that I’m quite passionate about. I graduate in May 2019 and was able to land a job in late October 2018.

Here is a general overview of the steps of landing a job:

1. Apply for Software Engineering Developer — New Grad roles.
2. First Screening — hackerrank, quiz, coding challenge…
3. Phone/Video Interview(s)
4. Onsite Interview
5. Offer/Rejection
6. Negotiation

Preparation

• Review data structures and algorithms — this is crucial. Knowing what data structure to use and when is extremely important.
• Read Cracking the Coding Interview — this provides a really good base of what you can be asked. I’d highly recommend going through some of these problems with a buddy!
• Leetcode/hackerrank/GeeksForGeeks practice — they’re all great resources, I prefer Leetcode because it really helped me prepare well for interviews. Leetcode had a great discussion board for each problem where people’s solutions were explained thoroughly.
• Practice coding on the whiteboard! Coding on a whiteboard is completely different from a computer.
• Know your projects and past experiences well. Be able to answer questions regarding any problems around it and how it was resolved.
• Get your resume critiqued/looked at by peers, ex-coworkers, etc… — by far one of the most important steps. If your resume is well presented with keywords, this can increase your chance immensely.

Applying for Jobs
Before you decide to apply for jobs, if there’s a specific company that you want to work for, try to see if you have any connections that can get you a referral. As cliche as it is, connections are very important. A referral will help you get your resume glanced at, at the bare minimum. It won’t guarantee you an interview, but at least it won’t be in the pile of thousands of resume accepted through the job portal.

If you don’t have a referral, try going to career fairs. Meeting recruiters in person could potentially get you an interview on the spot.

Lastly, apply online through their job portal. This can be time consuming. I’ve never had an issue with submitting the same resume to all companies, but if there a place that you’d love to work for, tailor your resume for them.

From my experience, I would email my previous recruiters (recruiters that I’ve previously interacted with for internships I’ve applied to) with my resume to ask if there are any new graduate position in software engineering available. Surprisingly, the response rate with this was 100%.

First Screening

Yay! You passed the resume screening, now you’ve been given a coding challenge/quiz/hackerrank. This can be in multiple different formats including:

• Coding challenge — you will be given a few problems and you will have to code up the solution (some have time limits, some don’t).
• Multiple choice questions — mainly to test your knowledge in your data structures, networking, operating systems, etc...

* Tip: If you have a referral, sometimes you get to skip the first screening and can jump right into the phone/video interview.

Phone/Video Interview(s)

All the preparation you’ve done beforehand will now pay off. It usually lasts between 45 minutes to an hour. Typically it is comprised of talking a bit about yourself and then one or two coding questions. Be comfortable in a coding language. Be prepared to talk about yourself and your experience. The biggest tip I have for doing well is always think out loud. What this means is that you explain everything that you’re thinking of while going through the problem. My usual structure looks something like this:

• Explain the problem back to them briefly to ensure that I’m not missing/misunderstanding any points.
• Ask any questions I have for clarification about the problem.
• State the brute force solution with the runtime and space complexity.
• Consider edge cases in the problem.
• Think of a better solution and start explaining the solution.
• Now start to code.
• Test your code with all the cases you can think of.
• Explain the runtime and space complexity.

At the end of the interview, I usually prepare two questions to ask the interviewer. Interviewing is a two-way process. You’re interviewing them to see if that’s a place you’d like to work for. They’re interviewing you to see if you’re a good fit for the company.

There’s usually two rounds of phone/video interviews, but sometimes there could be more.

Onsite Interview

You’ve passed the phone/video interviews, congrats! Now you’ve received an email from your recruiter to help you set up your onsite! You should be proud of yourself for making this far. From the onsites I’ve been on, the number of interviews typically vary from 2–6 interviews. On average, I would say 4 is the usual. You should expect one behavioural interview, and the rest are usually technical. Sometimes, it can be the case that there is an HR round as well.

These interviews are fairly similar to the phone/video interviews, except, you most likely will be coding on the whiteboard. If you messed up one interview, it’s not the end of the world because they look at your overall performance. Onsites vary from company to company. If it’s a bigger company, like the big four, you can expect to be taken around in a large cohort of around 50–70 people. A smaller company, perhaps a unicorn, will have a one on one interaction with you. Don’t be shy to ask as many questions as you have.

Offer/Rejection

The waiting game begins …

If you’ve gotten an offer — Congratulations! If not, it’s totally okay! You will be just fine, trust me. I’ve faced multiple rejections and yes, it hurts and sucks, but that just allows you to improve on what you didn’t do as well on. Think of it as feedback — I always ask for feedback from my recruiter to see what I can improve when I do get rejected. Continue to apply!

Getting the offer does feel great, but I was in the boat where there was a deadline and I still had a few other onsites scheduled within the next four weeks. I was quite stressed about it. When I received my first offer, I notified my recruiters right away to see if I was able to reschedule my onsite interviews earlier. I managed to expedite a few of the companies which worked well for me because I ended up getting offers at other places well. I was very fortunate to have multiple offers to choose from. Since I received offers from other places, I was able to push my deadline from my first offer to a week later. This gave me some more time to think about my offers at hand. There was quite a few things that I thought about before I made my decision. I can make another article about how I weighed out the pros and cons.

Negotiation
I was fortunate enough to have multiple offers to choose from. I’d highly recommend this article to help you with negotiation.

Tips/Things to Takeaway

• Don’t be afraid to ask questions — it’s a two-way conversation. You need to see if the company is a good fit for you and the company will see if you’re a good fit for them.
• Take rejection as a learning experience. The first one hurts the most, but as you go through more interviews, you learn more about what you can improve.
• Be honest. Don’t lie about anything, it’s easy to tell when someone lies and leaves a bad first impression on you.
• Reach out to your peers to see what the salary range is around.
• Practice with a buddy. This helped me the most to prepare for interviews.

I hope this article helped. If you have any questions about anything, feel free to message me.

You can do it!

Cheers,
Frances

Special thanks to Nicholas, Eric, Susan, and Carmen for editing this article.