Part of your coding interview preparation is mastering your coding fundamentals and skills.
But even more important is how you act during your interview:
How you come across.
How you’re able to show off your abilities.
Apply these 8 tips to leave a great impression on your interviewers during your coding interview.
Coding Interview Tips to Help You Get the Job:
Tip #1: Communicate Well
Be nice to your recruiter.
Be personable, be human, crack a joke. Show your charisma.
The interviewer is looking for for a great addition to their team. You would meet every day, solving tasks together, sit in the same meetings, probably pair-program, and spend most of your time together.
So it’s important to behave like a nice person: Be friendly, communicate in a clear way, do not frustrate the interviewer, and so on.
Point out your interests.
During the meeting, point out your interests, hobbies, and activities that have a connection with the company’s work style, team spirit, and culture.
This will demonstrate that you too care about being the right person for the job.
Don't argue, blame or make excuses.
Take responsibility for your own actions and if you don't know the answer, simple, say “I don't know the answer.” Or even better, say “I don't know the answer but I'll find out (and here’s how)”
Tip #2: ASK them questions
Come with questions prepared.
When preparing for the interview, write down some questions you want to ask—your proactiveness will add some bonus points to your application.
This tactic shows your interviewer your real interest in the position. It also gives you a clear picture about the opportunity and you can decide if you want to join them at all.
A win both ways!
Ask questions about the role.
Ask about the position, ask about the company, ask about the technologies they use. This is a great way to show that you understand what you’re doing.
For example, if you’re applying to be a Java developer, ask about the version of the language and the related technologies.
You may ask questions about the scope of projects, too.
Tip #3: How you can Buy Time in the Interview
Drink some water.
At the beginning of most interviews, you’ll be asked if you need water. It is good to say yes. You can buy some useful seconds during the interview by drinking some water. In the meantime, you can think about an answer.
Note down your thoughts.
If you quickly note down your thoughts as they're asking, you both buy time and create a structure that will help you give a better answer.
Ask clarifying questions.
They ask about a topic, and you ask back: “What parts of it would you like me to focus on?” This can buy you more seconds to formulate your answer.
Add introductions to your answers.
If you make the first part of your answer a short overview of the topic – obviously don’t make it long-winded – you have time to think about what you’ll say next.
Tip #4: When you get stuck on a question
Seek to understand the problem.
We have to find a way for you to understand it. And there's a couple of different things we can do, right? One of them is simplifying the problem down.
So we have that 50,000 foot view, how do we simplify that problem down now? Can we break it up into multiple points? Can we pseudo-code it out?
Think out loud.
Interviewers are not mind-readers. They don't know what you are thinking when you are scratching your head trying to figure out how to insert a new node into a linked list.
Just talk. When you’re trying to solve a problem, talk through it.
You do get bonus points for thinking about a problem the right way and showing your problem solving skills–even if you don't get the answer right.
Make the ugly solution happen.
People feel as though they need to get the best solution out every time in interview. But it’s not about being the most efficient in the world right away.
Likely when you're in the interview and you get the ugly solution working, the interviewer will ask you: “Is there a better way to use that’s more efficient?” Which will give you the avenue to refactor your code.
Too many people get hung up with trying to get that best solution so that they end up not even solve the problem. They're too worried about looking silly – when you should worry about solving the problem at all.
Tip #5: involve the interviewer
Ask questions first.
Don't just start coding the solution to a problem. Even if you think you understand it. Ask the interviewer some questions to confirm.
The point isn't to run off and code the right answer, the point is to simulate how you'd behave in a real-world environment. If you don't ask clarifying questions about your assignment in a coding interview, the interviewer will assume you wouldn't ask questions in a real-world situation either.
So, take your time, ask questions–make sure you understand what kind of code you are supposed to write, before you write it.
Ask them for feedback.
Especially if you don't know the answer to a problem and they've timed you out. It doesn't hurt to ask the interviewer their opinion on your code and your solution to the problem.
Show that you’re interested in learning – you don't just want to get the answer right, but you want to understand it.
I guarantee it won't make you look stupid. But it’ll make them feel important.
Tip #6: be confident
Your responses to questions during the interview are the best way to showcase your communication skills.
Speak clearly and slowly, enunciate your words, provide examples to back up every claim you make, and be receptive to following up on everything you say.
Have confidence in your answers.
Don’t make too many ‘maybe’ statements. Don’t flip-flop around in your answers.
Say what you know, and move on. And leave it at that because that's going to come off way more confident than anything else.
Don't give up so easily.
Try a little. Try a little more. An interviewer will respect you a lot more if you try hard.
No one wants a coworker who whines about how hard something is and promptly gives up.
Tip #7: Work cleanly
Name things cleary.
If you’re in a coding interview and you write code with one-letter variable names – like I so often see in coding interviews – the interviewer is going to assume that is how you normally write the code that you put into production in real-world applications.
It takes you two extra seconds to think of and write out a clear and meaningful variable name, so do it.
Test your code.
I can't believe how many software engineers, who would normally test every line of code they write, completely forget to do this in an interview or think it's not important.
Write a unit test to test it if you can, but if you can't, at least paper test it. (That means walk through the code with possible inputs, line-by-line.)
It's not a race. It's about being thoughtful, analytical, careful and accurate.
No one is going to be too impressed if you whip out code super fast, but do it carelessly. It looks like you just don't care and you are all about showing off instead of writing good code.
Be the guy who takes his time, tests his code and makes sure it works, before he throws it over to the interviewer and says he's done.
Tip #8: what to do AFTER YOUR INTERVIEW
Send a thank-you note.
After your interview, send a nice thank-you note to the hiring manager, and ask if they need anything from you.
Send messages to everyone involved.
The same goes for anyone working at the company you came in contact with during your interview:
Send them a thank-you note. That way you’ll stay top of mind with the team.
Do a debrief for yourself.
After every interview, go over the questions you didn’t perform well on, and do your best to figure them out later in a less stressful environment.
There’s a strong chance you’ll encounter the same concept (often the same question). You want to do better next time you are asked a similar question to the one you struggled with last time.
You want to see progress.
If you got rejected, ask for feedback.
Some interviewers are willing to help you out with a bit of feedback after you’ve failed to get the offer.
From this, you can learn what you need to study next or how to better present yourself at other interviews.
Being open to constructive criticism always pays off!