DEV Community

Cover image for Do Better in Coding Interviews by Being Confident and Humble
Lane Wagner for

Posted on • Originally published at

Do Better in Coding Interviews by Being Confident and Humble

I think we often do a great job of flogging the dead horse of whiteboarding problems when giving coding interview advice. Heck, that's what I've dedicated the entirety of to. While the hard skills you'll need to be able to solve technical interview problems are necessary, it's also critically important to work on your soft skills.

From a high-level, there are two qualities you really want to exhibit in a coding interview:

  • Confidence
  • Humility

Let's talk about why these two qualities are so important.

At the end of the day, companies don't hire people. People hire people.

Companies are a myth. If you don't believe me, read the "Sapiens" book. Anyhow, the point is that a company doesn't think for itself. Companies are made up of people, and the people in a company don't belong to a singular hive-mind. They don't do exactly what's in the company's best interest at all times. The people in a company are loosely aligned in their mission to make the company money, but each person has their own wants, needs, pains and incentives.

When you walk in (or sign in) to a job interview, remember that the people interviewing you are people. If they decide to hire you, it's not just because you're the candidate that they believe you're the best option for the company. Instead, it might be because you will:

  • Save them time
  • Make them look good
  • Make their life easier
  • Build out their team, giving them more authority and influence
  • Deliver the project that will secure their next promotion
  • Be fun to work with
  • etc

People want to hire people who make their job easier

This is the first point I'll make where confidence matters. When you're in an interview you're making a sales pitch. You're quite literally selling your services to your interviewer. Your interviewer is very interested in your skills because they want to know if hiring you will take some work off of their plate. Your interviewer will be wondering things like:

  • Will I have to hold your hand constantly?
  • Will you learn the codebase and be able to contribute quickly?
  • Do you bring new skills to the team?
  • Will you be able to quickly learn the things you need to know but aren't yet familiar with for this role?
  • Will hiring you make me look good?

By coming across as confident and self-assured you will naturally ease a lot of their concerns regarding your competence. Of course, false confidence won't help you - you need to actually know your stuff! That said, once you do know your stuff, getting yourself into a positive and confident mindset can help a lot.

I know, I know, it's easier said than done. That said, like Simon from Gurren Lagann, you can always believe in the me that believes in you.

People hire people who are enjoyable to work with

Being "confident" isn't the same as being a boastful goober. When I say "be confident" I'm saying that you should believe in your abilities, and if you don't know something, believe in your ability to figure it out.

However, competence is only one piece of the puzzle.

It's also very important that you have a fun, positive attitude. Remember, the people interviewing you are hyper-aware that they're going to have to spend hundreds of hours with you if they decide to extend you an offer. They want someone on their team that's fun to be around!

  • Don't complain. You had a bad day? I'm sorry about that, but save the story for another time.
  • Don't trash talk your past coworkers. It's safe to assume that if you didn't get along with many of your past coworkers you may have been part of the problem.
  • Don't mention that you were let go or fired. No one is going to hire you out of pity. Don't lie when asked, but you don't need to bring it up.
  • Be excited about the interview. Have fun, and try to relax. Treat the coding problems like fun challenges.
  • Collaborate and use inclusive language. When working on a problem in an interview, use words like "well WE could do x..." or "I'm thinking WE could try y". It puts you on the "same team" as the interviewers, and makes you look like a team player. Heck, they might even be more generous with hints and tips.

Be humble - know-it-alls are not fun to work with

Let's switch gears and talk a little bit about humility. Like the title of the article says, it's important to have confidence and humility. Confidence communicates to your employers that you can help solve their problems, but humility helps in a few ways as well:

  • Being humble shows that you're not an ass. You'll be more enjoyable to work with.
  • Being humble communicates that you will be teachable and learn faster.
  • Being humble means you're more likely to be willing to adapt to how the team does things.

How can you be confident and humble?

Humility and confidence can seem like a conflicting set of characteristics to be sure. I've chosen my words carefully; you should have confidence, not pride.

A confident person believes they are able to do something, or at least that they can figure it out. When they discover that they were in fact doing something wrong, or that there was a better way, they happily change their methods. Conversely, when a prideful person learns they weren't doing something well before, for example, maybe they receive some constructive criticism, they take it personally. Their feelings get hurt and they become stubborn; they may even refuse to admit that they had it wrong.

Be confident, but don't be prideful.

How do I "become confident"?

I don't have a good answer, but here are a few things that have helped me:

  • Make sure you know your stuff. Learn the hard skills. It's a lot easier to be confident in your abilities if you at least have the abilities in the first place.
  • Practice interviewing! Get as many interviews as you can. Don't expect to land a job in your first interview. I did about 15 interviews before I got my first coding job.
  • Realize that no one knows everything. The field of programming is enormous. You're not expected to know everything about computers when you go into an interview.

Anyhow, I hope this helps you a bit in your job search - Good luck!

Top comments (8)

jmfayard profile image
Jean-Michel (double agent) • Edited

Are you specifically talking about the coding part of the interview process? Then I would agree, humility with other engineers might be a good thing. I would counterbalance that by having confidence in your ability to learn things you don't know. And that's not enough, you also need to say that out loud. Like: "interesting, I will google that out/do the tutorial to learn about this".

But the whole interview process is also about something very important called salary negotiation. And you should enter that negociation without doubting an instant of your skills, else you are dead. Have you seen a car vendor explaining to you everything that's wrong with the car you are planning to buy? Because yes, you need to sell yourself. Yes that sucks for many of us. But so is life.

lexiebkm profile image
Alexander B.K. • Edited

" I would counterbalance that by having confidence in your ability to learn things you don't know. And that's not enough, you also need to say that out loud. Like: "interesting, I will google that out/do the tutorial to learn about this".
For instance, learning Kotlin for mobile dev, including its modern declarative UI toolkit : Jetpack Compose. I am just getting started, having read basic syntax in the doc and try example of Compose, although failed because my laptop's spec is not adequate.
When I am asked : "How long ?", how should I respond : 1 month... 2 weeks ... ?

jmfayard profile image
Jean-Michel (double agent)

The question taken literally is dumb and cannot be answered meaningfully.

  • I want to learn to write better
  • How long will that take?
  • Well I'm not sure what you mean by that.
  • How long?
  • I would say 5 minutes to get started, 42 lives to write like Victor Hugo.

But instead of telling the interviewer that he asked a dumb question,
I would redirect the conversation to something more tangible.
Because what he really wants to know is whether you are a good learner.
So in my case I would say.

Well, looking at the past, I remember that I was able to grasp the basics of Kotlin in one week-end by doing the Kotlin Koans. Basically writing unit tests, a great way to learn for me.
Now obviously I have refined my craft a lot since then.
In general I would say as a developer learning new things is probably the only thing I am really good at.
For example in my life I learnt aa, bb, cc, dd, ee, ff, gg, hh, ii, jj, kk, ...

Thread Thread
lexiebkm profile image
Alexander B.K.

Thanks for your fast reply.
You know that in some job requirements, it is mentioned :

  • a fast learner... or can learn new things quickly

So I assume they have certain measurement about this thing, hence my aforementioned question.

Thread Thread
jmfayard profile image
Jean-Michel (double agent)

They know it's important but I'm pretty sure they don't know how to measure it.
If you asked them how much time they would need to learn French 🥖 they would be exactly as embarrassed as you.

Thread Thread
lexiebkm profile image
Alexander B.K.

Thanks again.

"I want to learn to write better" .... I agree with this, so I don't really care for how long to achieve this for myself.

"In general I would say as a developer learning new things is probably the only thing I am really good at."
I agree, as developer, we learn new things, be it for a task given by the authority or because of our own initiative for own purpose/goal.

lexiebkm profile image
Alexander B.K.

"Will you be able to quickly learn the things you need to know but aren't yet familiar with for this role?"
How to respond when we are asked about the exact time : "How long ?"
For certain techs, we may give rough estimation, but for an absolute new thing, it's hard to estimate and give a reasonable, let alone acceptable answer.
I need to anticipate for the response by the interviewer whether my answer is acceptable or not, because it can effect the result.

Can you give some guideline regarding this ? For instance, say that we need to learn these following things that are specifically marked by words "preferable or is advantageous" in the job requirements :

  1. Mobile dev with Flutter or React Native
  2. Java/Kotlin
  3. Spring/Ktor
  4. Core (with C#)
  5. REST/Graphql
  6. Authentication with OAuth implemented in particular language/framework
  7. CI-CD with Jenkins
  8. Docker/Kubernetes
  9. Cloud with AWS/GCP
  10. Microservices
dagnelies profile image
Arnaud Dagnelies

Well written, I agree with everything.