Thoughts on the Junior Developer’s Job Search | by Nina Loeterman | May, 2022

Tips and tricks for succeeding in software developer interviews

Photo by Sebastian Unrau on Unsplash

Some background on myself to preface this article — I’m a self-taught (bootcamp included) software developer with about one and half years of experience, mostly in the frontend JavaScript world. While I worked at two companies before this job search, I got to those companies through chance, never really having gone through a proper job search.

Even though this guide is aimed at less experienced developers, I think it can be pretty relevant across the board.

Feel like I’m leaving something out? Leave a note in the comments!

Before we dive into the interviews themselves, a job search takes some preparation.

Excel sheet

Create an Excel sheet of your opportunities. This is critical. I never thought that with so little experience so many companies would be reaching out to me. I never thought I would forget who I talked to and at what stage I was at in the process. Just stay organized — keep an Excel file.

I used the following columns in my Excel sheet:

  • Company
  • Salary expectations (Where I live, this is often discussed in the first conversation with talent acquisition)
  • Rounds — which interview rounds occurred (talent acquisition, technical interview, HR, etc.) and the outcome of each interview
  • My level of interest in the company
  • General comments
  • How I got the interview
  • Current status — in progress, rejected, stopped (When I chose to stop the process with the company), and received contract

My Excel sheet looked something like this:


“The greatest discovery of my generation, is that human beings can alter their lives by altering their attitude of mind.” — William James

In addition to an Excel sheet, it is critical to carry yourself with confidence. I really believe it’s a must have. Fake it till you make it — answer the phone confidently, speak about your experience with pride, and know how to highlight your strengths.

I found this to be easy with the first few companies I talked to, but having incredible posture in every interview gets exhausting pretty quickly. That being said, make the effort. Confidence is such a huge part of how we are perceived and in showing we are competent.

There’s no replacement for a certain level of knowledge of your tech stack and algorithms, but there are some tricks you can pull out to make it seem like you know your craft.

Keyboard shortcuts

Know a lot of them. It makes it look like you know what you’re doing.

In my job search, I was asked to do a lot of live coding. In fact, I did live coding for every company I interviewed at. Being able to easily navigate, highlight, and change things in your code through keyboard commands makes it look like you know your craft.

I found interviewers to be impressed by this and think it gave a feeling of me having more experience than I actually have. In addition, knowing some ins and outs of your IDE can give a similar impression.

Know your language

Companies really want to see that you’re fluent in your primary programming language. I’m a big JavaScript person, so this means knowing methods for arrays, strings, and objects, and generally having syntax at the tips of your fingers.

We all know that at our jobs (some entry-level jobs especially), we’re not always doing such riveting things with our primary language. Taking the time to practice all the methods and having them in the front of your head can be beneficial during an interview. I was asked at multiple interviews to handle dates with JavaScript — something I definitely needed to freshen up on.

Besides syntax, know how your primary language works. Is it single or multi-threaded? In JavaScript, for example, know closures, scope, and other complexities. Learn them not only to regurgitate their meaning, but as knowledge you can use when you’re explaining an answer to a complex problem.

The first time I was asked how JavaScript works, I failed horribly. I knew to say that JavaScript is single threaded but can make asynchronous calls, but I really couldn’t explain the process. I threw “event loop” out in the air, but it wasn’t enough. Knowing the foundations of your programming language will help along the way because someone will ask about this.

Cool syntax

Show you love programming by using cool syntax. Don’t overdo this! But throw in a spread operator, a ternary operator, object literals, and new cool syntaxes in your language. It shows you’re up to date and mainly that you’re interested in your language and its capabilities. Never compromise readability for cool syntax, but show fluency and an interest in writing clean, efficient code.

Practice talking about a major feature or project you built

At every technical interview I had, I was asked to talk about an interesting project or task I had worked on lately. Interviewers want to know how you think, and they want to hear that you have experience working on complex problems.

Take the time to sit down and craft an answer to this question, and learn to talk about your experience like it has great value. Even if you haven’t worked on such incredible features, make it sound like you did. I struggled with this question the first few times an interviewer asked until I crafted an answer that showed what I worked on, what impact it had had, how I it out, and what challenges I faced.

Know the company

Take 15 minutes before each interview and read up about the company. When the interviewer asks you if you know what they do, say yes and tell them what their company does. Doing this shows engagement and interest. I found that it was easy to read up on the first few companies I interviewed with, but I started to get lazy as the process went along.

Don’t slack on this; take the time to know the company before every interview. Companies want to see that you are engaged, that you have a spark, and that you will like working with them. The first step in that is knowing who they are and what they do. By knowing the company, you also show them that you value their time and investment in you.

Ask questions

Show you’re engaged, and ask questions. You can and should ask many different kinds of questions during an interview. From clarifying a question the interviewer has asked you to ask for elaboration on what the company does to those standard “Do you have any questions” at the end. Ask and engage.

One company I interviewed at was a bootstrapped company that had just raised a significant venture capital round, meaning that the company started not by raising VC, but existed by profits from the start. The current company I worked at was also a bootstrapped company. So when the interviewer talked more about the company than what I researched, this came up, and I asked more about it, which led to a great discussion about the advantages of bootstrapped startups.

I engaged. I told him my thoughts about how a bootstrapped company looks good in the market. It gave him the feeling that I’m involved in the startup world, and that I’m interested in how companies work and how a product finds its market. This was totally extra, but my interviewer liked it, and we had a great conversation.

Thinking and sharing your thoughts

After the introductions and general questions in technical interviews, the interviewer shows or asks some technical questions. This is always a tough moment because you just don’t know what to expect.

Take your time, repeat the question, and it’s okay to say “I’m going to think for a moment.” If it’s an algorithm question or some other nonstraightforward coding task, always repeat the question. Repeating shows that you want to understand what the task is, and it can be good for your own understanding as well. I always say, “I’m going to think for a moment,” and I felt like the interviewers appreciated that.

Solving an algorithm

At first, just make it work. Doesn’t matter if it’s terrible code. Once it’s working more or less, refactor for readability and efficiency. Express what you’re doing to the interviewer. Don’t be too shy to say, “I’m going to start by just trying to get something working,” then, once you’re there, say, “Now I’m going to think about how to refactor to make this better.”

Edge cases

Think about edge cases, and you can ask the interviewer about them as well. I felt like this was one of the main places where my lack of experience showed. I have trouble thinking of edge cases.

Depending on a function that takes three arguments? What if it only has two? What if your algorithm uses two pointers, but the array of nums has a length of 1? Are you assuming what types of values ​​you are going to be getting?

Edge cases are hard to practice through Leet Code because Leet Code will always tell you if it’s failing on some use case. When you’re practicing, try and beat the tests to it by imagining what practice input values ​​could create issues and then handling them.

Handling rejection

Rejection is hard. It can be really tough to hear someone tell you they decided to move on with other candidates. Ask for feedback where you feel it’s appropriate, and if you get feedback, reflect and try to improve. Always thank the person for their time, and if you had a positive interview experience, let them know that.

Keep it respectful, and hold your head high.

It’s easy to feel like no one will ever want to hire you or that you’re not smart enough or good enough. But try not to dwell. Brush your shoulders off, and focus on improving. Come to the next interview confident and better prepared.

The job search is exhausting.

So many things to excel at. So much to remember. You have to bring your best game to every single interview, and it’s a journey. I felt like each interview prepared me for the next.

The most important thing? Believe in yourself. You can do this :).

Leave a Comment