Dragos Nedelcu

Posted on Apr 18, 2022 • Edited on Apr 21, 2022

10 Interview Mistakes that Make You Look Junior ...and Leave Money on the Table

#programming #career #productivity #javascript

In software development there is no real standard level for seniority.

For some companies what looks like a senior developer, for other companies would be a mid or junior developer at best.

This brings me to the next point, the way you perform in interviews will determine the level of seniority a company will assign to you.

So you better nail those interview questions!

Well in this article I compiled for you the 10 most common mistakes you want to avoid if you don’t want to look like a junior and of course leave a lot of money on the table.

1. Answering questions without thinking twice

The biggest type of behavior that will make you look like a junior is as soon as the interviewer asks a question, you jump right in with an answer.

I know you are nervous, and I know you are eager to prove how much you know, but being too fast in answering a question might lead to you missing key information needed to properly answer these questions.

By the way, you can watch all this on YouTube here, make sure you subscribe :)

It might also make the interviewer feel like you are not really listening to them. Instead of doing that, take a few seconds to think before you answer any question, particularly in an interview.

You should also follow up with further questions if you feel like you need more information to formulate an answer.

This brings me to mistake number 2…

2. Not asking the most powerful question you can ask in an interview

What really makes the difference between a junior and a senior developer, not only in the context of interviews but also in real-time on the job. Senior developers understand the importance of the question “Why?”.

And they understand that many times people will ask them things because they think they need something when in reality they want to achieve something else and they thought that was the best way.

Don’t take things for what they seem, dig a bit deeper.

In an interview make sure you ask a why a few times to completely understand what the interviewer is asking for and after that dive deep into answering it.

3. Attacking or blaming the interviewer.

You might be tempted to do this, particularly when you feel like you are being asked things that have nothing to do with the job (like fancy data structures…).

Look I know it might seem unfair, I know tech interviews might piss you off, but having an emotional reaction to this, or worse, questioning the interviewer's skills because of it will definitely sabotage the whole interview process.

Put yourself in their shoes, there is a reason behind why they are asking this. And if is a stupid question, if they are a developer, they probably know it anyway. Maybe, they just want to see how you react to the whole thing.

If the question catches you right off the bat, ask some clarifying questions as I mentioned before, or simply tell them the truth in a polite way: ”I am not familiar with this concept, could you help me understand this better?”

This thing alone will save you, and even if you might totally fail some questions, you will for sure still be on track for getting the position.

4. Thinking you are the hero.

Look, the interview is not about you. Let me repeat this, the interview is not about you.

Sure you are getting evaluated, but you are getting evaluated by them, they want to see if you can help them achieve their goals through your technical skills. That’s what is all about.

This means that when asked about you, you should keep it short and always point it back to them. Be interested in what they do and what are they trying to achieve by hiring you.

In this way you will easily stand out from the crowd of developers out there that think they are some kind of geniuses and companies are lucky to have them.

That story is great for the ego, but it won’t help you in winning them over.

And if you are not interested in winning them over then why the hell are you interviewing with them anyway?

5. Talking trash about your last employer

One of the things that damaged my ability to land a position, particularly at the beginning of my coding career…

When asked the magic question or: “Why are you leaving your current position?”, I would go ahead and ramble forever about how bad my last job was, how there was no automated testing, the expectations to deliver were outrageous and there was no training in place!

And the worse is, most of it was true.

Yet it did not help me, as it tagged me as someone who complains even before starting out and it brought a negative vibe to the table. A better strategy is number one to make peace with the past, as is not helping anyone.

Just tell them it’s been great but you are looking to grow in a different direction and that’s what made you interview with them.

6. Spelling mistakes in the code, readme, or documents you might send over

Back in my frontend engineering positions I was in charge of evaluating the code challenges we would receive and deciding whether we get them on an interview or not.

One of the biggest stoppers in passing people to the next level was the quality of their readmes, which included the way they expressed themselves and the grammar.

Unfortunately, at that point in time, those documents are the only way people can judge your abilities before inviting you over, they don’t know you. Before you send things over, make sure you double-check for grammar and spelling.

You can use a piece of software like Grammarly to put this on autopilot.

7. Worrying only about the code and losing sight of the big picture

Not only how to code this and that, but also the impact, the pros, and the cons that the solutions you provide will bring to the table.

This might be really hard if you never came in touch with making technical decisions your way and this skill takes years to develop, but you can use a simple trick to think about this. When faced with a technical problem, ask yourself this question…

What would my tech lead / my CTO do about this?

From that perspective, your brain will start looking for alternatives and you will most likely find several alternative solutions that will get you out of trouble.

8. Spending too much time trying to find the right keys on the keyboard.

This is particularly important for live coding interviews. You might find it unfair and maybe it is, but one of the ways to get a feeling of someone’s seniority is how fast they type.

It is a short heuristic for the human brain. But the subconscious image they have can be, the faster they type, the more they have been working with the computer(particularly when writing code in public).

Your typing speed matters if you are writing code for a living.

You can train this skill and it will actually make you more productive as a developer on websites like 10 fast fingers or typing club.

9. Randomly debugging your code instead of having a process

I see it all the time with junior developers.
They get a console error and instead of taking a few seconds trying to see what happens they either jump back to the code changing things randomly without understanding what they are doing.

Or worse, they copy-paste the error code into Google, thinking Stack Overflow will magically return a solution. When it comes time to interview, Stackoverflow won’t be there anymore but the bad habit is there and now is visible in front of the interviewer.

A better way to approach this is by having a simple process that you can use when faced with an error or exception. If you want me to write an article on this, let me know below in the comments.

10. Self-labeling yourself as a junior

Probably the most important thing that held me back when I was trying to get to a more senior position was my own self-image.

I would self-sabotage myself by letting all my insecurities and past failures consider myself less than I was worth it. This is particularly true when you are aiming for a position that is out of your comfort zone.

Your emotions will try to hold you back and tell you that you might not be cut for this. This leads people to undersell themselves, tag themselves with the junior label fail to progress and grow.

Working on building strong self-esteem in terms of your abilities as a developer can take years, again I have a simple hack for you.

Don’t ever label yourself. Instead, let them label you.

Go there, do the best job you possibly can and let them tell you at what level you are!

Well, that was it. Make sure you keep this article handy when you are interviewing for your next position or a promotion.

If you implement even half of the stuff I just mentioned you will get to that next level in no time, and this junior or mid-level thing will be just a memory!

And if you are truly serious about getting to the next level, here are a series of resources to help you get started on that journey. Follow the steps below to get access:

Find out your technical gaps with our free technical assessment
Watch this technical training where you will learn how to get to the Senior level faster by improving your technical skills effectively using a “Technical Mastery System”

If you want to gain complete confidence in your technical skills, get to the mid/senior level faster, and earn more as a developer I invite you to watch our free training and reach out to me.

We will understand exactly where you stand right now technically as a developer and draft a step-by-step technical roadmap for you to get to the next level.

And if you want our help putting it into action, we would be delighted to help you out!

Now click on that follow button if you want to get more articles like this and I will see you in the next one :)

Cheers,
Dragos