Interview Tips for Junior Developers

Image by U. Leone from Pixabay

As a senior developer I’ve found myself sitting on both sides of the interview table. Here are a few take aways I’ve gathered over the years.

You Will Fail Interviews

For every single interview your chances of NOT getting the job are greater than your chances of getting the job. It’s not personal. It’s just part of the process. There are going to be multiple candidates who all qualify. You could knock the interview out of the park and still NOT get the job. I have seen awesome people NOT get the job:

• The most senior
• The most qualified
• Industry experts

Often the reasons you didn’t get the job have nothing to do with you:

• The job was written with one person in mind but HR made them interview.
• Someone’s son, daughter, neighbor, old coworker, etc got a personal recommendation from in the company.
• You were the first / middle / last to interview in a long list of candidates.
• The job was called junior because they don’t have the budget for senior but found a candidate with more experience who would take the junior role.
• Your interviewer forgot their coffee / had a bad day / was distracted because their boss yelled at them / etc.
• Funding dried up and they can’t pay you.

So, don’t look at failed interviews as failures. Look at them as training. You aren’t just learning to code. You are learning to sell your skills.

All Interviews Are Sales Jobs

Every single interview boils down to one thing:

What can you do for the company?

I don’t care how junior the role is or how much training they will provide.
Your job is to sell your unique skill set. What are you bringing to the table that the company wants? Can you give examples where you learned things quickly on your own? Did you do a non-tech job that has skills that carry over to tech? Maybe you were PTA president? That might not look like tech but you probably did a ton of project management!

However, you can take it a step farther. The best sales people don’t talk about themselves when selling. They talk about their customer. Study the company that is interviewing you. Have questions and comments prepared about the company specific items that most excite you. Companies want people who are interested in them and not just in any job. Show you are excited about them and they will be more excited about you.

You Will Not Know All The Answers

One of my jobs when interviewing junior developers is to find out what range of knowledge they currently have. That means I have to ask questions they will not know. I will create lists of increasingly harder questions on several subjects and work my way down the list until the candidate can’t answer the question. They have NOT failed. They have just shown me where their knowledge drops off. I’m not trying to be mean. I just can’t do my job without asking questions you don’t know.

One secret with interviews is how you fail to answer a question is as important as how you succeed. Development is full of questions where even senior people don’t know the answers. Our trick is we know how to get the answers. When you don’t know an answer try these three steps:

1. Acknowledge that you don’t know the answer directly. Interviewers HATE it when someone tries to bluff them or change the subject.
2. Share anything you do know relevant to the same subject.
3. Say how you would find the answer.

For example:

“What sort routine should you use on data that you know is reverse sorted?”

“Good question! I don’t know which one. I know that bubble sort performs especially bad in this case. I would need to pull out my copy of ‘The Algorithm Design Manual’ and brush up on sorts to pick the best one.”

A Question Is Not Just A Question

And interview is not just about your technical knowledge. It is about how you approach problems and your broader understanding of working in a company.

Always pause before answering a question and ask yourself what other information do you need. Start your answer by asking for more details. Some possible questions might be:

• What is the purpose of this feature?
• What does the data look like?
• Do you care more about performance or memory usage?

Not only does this show you are thinking about the bigger picture, but it gives you a few moments to start thinking about your answer.

Beyond getting details, many questions have more than one right answer. I’m looking for candidates who understand and acknowledge this. As an example:

“How would you write a sort function?”

“Well, in most cases I would just call the sort function/library/gem/etc. I’d rather not reinvent the wheel. However, in specialized cases we might need to write something from scratch. Would you like me to implement a specific algorithm?”

Finally, some questions are designed to be evil on purpose. My favorite is, “Are you sure?” I have asked this independent of right or wrong answer. It isn’t about getting the perfect answer. It is testing how you handle being questioned. No one wants a coworker that either explodes or folds when you push back. Can you handle being questioned and explain why you are right or look at where you might be wrong?

Use Your Interview To Learn Something

Interviews give you two opportunities to grow as a developer.

First, after the interview is over write down everything you didn’t know. You now have a list of growth areas that are important to employers. Don’t just study the question you had trouble with but the entire area the question came from. If you can’t explain why bubble sort doesn’t handle reverse lists well brush up on all your sort algorithm strengths and weaknesses. Also, a little secret, the person who interviewed you might have had to do the same thing before they asked the question. Really don’t feel bad if you don’t remember all the answers. The internet exists for a reason!

Second, for a short time you have an experienced developer sitting in front of you. At some point they will most likely ask, “Do you have any questions?” Start with the normal questions about the job and company. However, save a little time at the end to ask one good general career advice question. Think of it as a mini mentorship moment. The best questions will be tailored to something discussed in the interview. Ideas include:

• Is there a book or other resource on subject X that you recommend?
• From our interview what would you suggest I focus my skill building on next?
• What do you wish you had known as a junior developer?

If they give you a specific suggestion make sure to follow up after you have used it in a polite, non-pushy manner, even if you didn’t get the job. Email your contact something like:

“Can you please thank <name> for suggesting <book> to me? I just finished reading it and found <idea> especially interesting. I really appreciated their suggestion.”

Senior people love to know when they’ve been helpful and you never know when you will be talking to them again.

Summary

In review:

• Accept failure as part of the process.
• Sell what you bring to the company.
• Share how you would find answers.
• Look at a question’s bigger picture.
• Learn something for next time.

Thank you for reading. You can reach me on twitter.