10 Mistakes People make during an interview for a software role

Here are the top 10 mistakes people make during a coding interview for a software developer job.

#1 | Practicing on a Computer
If you were training for an ocean swim race, would you practice only by swimming in a pool? Probably not. You’d want to get a feel for the waves and other”terrain”differences. I bet you’d want to practice in the ocean, too.
Using a compiler to practice interview questions is like doing all your training in the pool. Put away the compiler and get out the old pen and paper. Use a compiler only to verify your solutions after you’ve written and hand-tested your code.

#2 | Not Rehearsing Behavioral Questions
Many candidates spend all their time prepping for technical questions and overlook the behavioral questions. Guess what? Your interviewer is judging those too!
And, not only that—your performance on behavioral questions might bias your interviewer’s perception of your technical performance. Behavioral prep is relatively easy and well-worth your time. Look over your projects and positions and rehearse your key stories.

#3 | Not Doing a Mock Interview
Imagine you’re preparing for a big speech. Your whole school, company, or whatever will be there. Your future depends on this. You’d be crazy to only practice the speech silently in your head.
Not doing a mock interview to prepare for your real one is just like this. If you’re an engineer, you must know other engineers. Grab a buddy and ask him/her to do a mock interview with you. You can even return the favor!

#4 | Trying to Memorize Solutions
Memorizing the solution to a specific problem will help you solve that one if it comes up in an interview, but it won’t help you to solve new problems. It’s very unlikely that all, or even most, of your interview questions will come from this book.
It’s much more effective to try to struggle through the problems in this book yourself, without flipping to the solutions.This will help you develop strategies to approach new problems. Even if you review fewer problems in the end, this kind of preparation will go much further. Quality beats quantity.

#5 |Not Solving Problems Out Loud
Psst—let me tell you a secret: I don’t know what’s going on in your head. So if you aren’t talking, I don’t know what you’re thinking. If you don’t talk for a long time, I’ll assume that you aren’t making any progress. Speak up often, and try to talk your way through a solution. This shows your interviewer that you’re tackling the problem and aren’t stuck.
And it lets them guide you when you get off-track, helping you get to the answer faster. Best of all, it demonstrates your awesome communication skills. What’s not to love?

#6 | Rushing
Coding is not a race, and neither is interviewing. Take your time when working on a coding problem. Rushing leads to mistakes and suggests that you are careless. Go slowly and methodically, testing often and thinking through the problem thoroughly. In the end, you’ll finish the problem in less time and with fewer mistakes.

#7 | Sloppy Coding
Did you know that you can write bug-free code but still perform horribly on a coding question? It’s true! Duplicated code, messy data structures (i.e., lack of object-oriented design), and so on. Bad, bad, bad! When you write code, imagine you’re writing for realworld maintainability. Break code into sub-routines, and design data structures to link appropriate data.

#8 | Not Testing
You probably wouldn’t write code in the real world without testing it, so why do that in an interview? When you finish writing code in an interview,”run” (or walk through) the code to test it. Or, on more complicated problems, test the code while writing it.

#9 | Fixing Mistakes Carelessly
Bugs will happen; they’re just a matter of life, or of coding. If you’re testing your code carefully, then you will probably discover bugs. That’s okay.
The important thing is that when you find a bug, you think through why it occurred before fixing it. Some candidates, when they find that their function returns false for particular parameters, will just flip the return value and check if that fixes the issue. Of course, it rarely does; in fact, it tends to create even more bugs and demonstrates that you’re careless.
Bugs are acceptable, but changing your code randomly to fix the bugs is not.

#10 | Giving Up
I know interview questions can be overwhelming, but that’s part of what the interviewer is testing. Do you rise to a challenge, or do you shrink back in fear? It’s important that you step up and eagerly meet a tricky problem head-on. After all, remember that interviews are supposed to be hard. It shouldn’t be a surprise when you get a really tough problem.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.