You’ve gone through all the difficult parts in launching your software career
Luckily you have now landed an interview.
This could be your moment of glory!
A chance to speak for yourself in front of a hiring manager…
A chance to convince them why failing to hire you would the biggest mistake they made to their business.
How you perform at the interview would determine whether you are hired or not.
Many people overthink the interview process and approach it feeling unprepared and nervous.
Confidence is key to having a successful interview, even if you don’t have all the skills required.
Depending on the company and their protocol, you might have between 1 to a couple more interviews before you finally got an offer.
I am particularly not a fan of a long series of interviews. After 2 or 3 rounds of interviews I’ll be able to know if it’s still prospective or it’s a waste of my time.
The more the interviews there are, the more people drop off on the way. Don’t be too scared to drop off if you believe the interview is headed for a dead end. I have had to take this decision many times and it saved me a lot of time.
Don’t just attend an interview to see if you are a good fit for the company, interview as well to see if the company is a good fit for you.
An interview might begin with an acceptance email, then phone screening to assess your language ability, then either an online or onsite interview.
Let’s see a few emails you might get.
This means the hiring manager is impressed with your portfolio and thinks you could be a great fit for the position they are looking to fill.
An email that acknowledges receiving your application and favorable consideration of your skills follow.
This is quite encouraging, especially if what you have been receiving is a series of rejection emails.
Usually the acceptance email would also be asking for your availability for a call with the Lead Developer, CTO, HR, Hiring Management or Owner of the startup depending on the company’s staffing pattern.
This is the email you want to respond to in time.
But you don’t have to be hurried. Take your time. If you are on the bus, relax. Wait till you get off the bus and you are settled in some suitable place and then craft your response.
Don’t send a reply from your phone!
Things are getting a little more serious now, huh!
Someone is picking up what you are putting down. They think it would be awesome working with you so they embark on the journey of wanting to know you more.
They then would like to know a little more about you.
This is not as hard or as complicated, usually the call lasts for 10 – 15 minutes.
Sometimes instead of a phone screen they will schedule an online interview. In some cases both might be used.
The online interview is different from the phone screen in that it will be
in order to assess some of your technical know-how as a developer.
There would be no coding, just questions.
If all goes well over the phone, the hiring team might be excited about meeting you in person.
In the event that you are applying for a remote software developer position, a physical onsite interview might not be necessary.
However, if it is recruitment for an in-house developer then a physical interview would be mandatory.
This is where your dressing style would come into play.
The way you dress will speak much about you, to the prejudice of many.
This is where your specific technical skills and ability will be tested.
Most software developers get intimidated with the technical interview.
The whole of your life as a programmer you haven’t had to write code while someone was watching every single thing you were doing and requiring you to speak it out loud to them.
The technical interview can be a terrifying hurdle between you and your dream job.
But don’t fear—just get ready to show off your skills.
And I will show you how right here with these tips.
Before your interview, start preparing.
Working through a preparation book will not only refresh your algorithms and data structures knowledge, but it’ll also put you in the right problem-solving mindset.
Most importantly, pick the right preparation book for your level and interests.
I personally use and recommend Codility.com to brush up my algorithm and problem solving skills.
It’s a free tool with a great number of questions that help you improve your algorithm skills because it runs your code against different environments and test cases and gives scores based on the efficiency of your code.
Practice Makes Perfect.
So start white-boarding whenever you can, even with really small problems.
The more comfortable you are with marking up that blank board at home, the less hesitant you’ll be at the interview.
Yes, get some sleep.
There are few things that will throw you off your game like sleep deprivation.
It’s comparable to showing up drunk.
If your portfolio is quite interesting and you are actively looking, you will be lucky to have a couple interview invitations at once.
When you’re scheduling interviews, be sure to leave at least a couple of hours in between each one.
Any time I had multiple interviews in a day, I didn’t perform as well as I could have.
I either worried about getting to the next one on time or I was preoccupied by the fact that I had already maxed out my logic hours before.
Ideally, I would only take one interview a day.
In some instances the outcomes from the previous interview may not be as impressive. This might rob you of the enthusiasm and energy to face you next interview with enough energy, if there was no significant break in between.
When you’re presented with a problem, think it through and make sure you fully understand what you’re being asked to solve.
If anything is unclear, ask questions early enough.
If there are edge cases, for example, ask how your interviewers want them to be handled.
Ask something like: Should I throw an exception, break out of a loop or exit code execution altogether?
Ask questions to understand what the interviewers are looking for and what your constraints are—for example,
And don’t make assumptions.
Even if you’re pretty sure it’s safe, mention out loud what it is you’re thinking so the interviewers can let you know if you’re missing something.
Once you understand the question you’re being asked, don’t be afraid to take a minute to think and process before you start solving the problem.
As long as you aren’t being bombarded with quick, knowledge based questions, pausing after being asked the question is a good thing.
Of course—make sure you’re NOT taking 10 minutes to solve it in your head without saying a word!
The point is to use your time up front to structure your approach, not to try to write all the code in your head before you touch the marker to whiteboard.
Think about the big picture of the problem first.
It’s fine to pseudo-code the overall structure, as long as you tell the interviewers that’s what you’re doing and that you intend to go back and actually code it later.
It’s a good way to offload the organizing of the problem so your brain has more room for processing.
This will also help if you run out of time in the end; the interviewers will at least know how you’d planned to finish out the task even if you didn’t get to the details.
DON’T worry at first about finding the most efficient way to solve the problem, unless it naturally pops into your head.
Nail a less efficient solution, and then discuss why it’s less than ideal. Then, if you have time or see a better way to solve it, move on to a more efficient algorithm.
Even if all you have time to do is finish your less efficient version and then explain how you would do it better, that’s just as great an answer.
Most importantly: Talk.
Bring your interviewers along with you in your problem solving.
This can be as simple as outlining what you’re about to do when you’re doing it (“So, I’ll need a for-loop to iterate through all the items in this list”).
Talking through your thought process gives your interviewers a window into how you think, and that’s ultimately the point of the interview.
Even if you think your solution is amazing, it’s better for them to know how you approached the problem and got to your answer than to see the full-fledged answer and not have a clue about what led you there.
It also gives the interviewers a chance to help you along if you’re stuck or going down a path that’s a DEAD END.
The fact that you are job hunting together with the thought that you might lose the job if you don’t nail the interview makes most developers go through technical interviews feeling the pressure, as if it was a matter of life and death.
Well, I don’t think so.
This makes you to forget about the most important experience for yourself – the learning and the fun involved.
Failing to get the job won’t necessarily mean you failed the interview – different companies use different metrics to gauge a successful interview.
Failing an interview doesn’t necessarily mean you are a bad programmer as well.
The opportunity will most likely be for one developer – so even if you were 10 awesome geeky coders, only one will have to be chosen.
Hopefully, you will
The more you think about your interviews in this way, the more valuable that time will be to you in the long run.
How did you approach your technical interview?
What are your particular hacks around this?
Please leave your thoughts in the comments below.
Found this article useful? Please share.
Geoffrey is an experienced software developer and open source evangelist. When not coding he writes and talks about current technology trends, small business tips and developer productivity hacks. He is no coffee addict.
25 Job Listing Websites for Finding a Junior Developer Job
Interview with Rob Percival – How To Land Your First Junior Developer Job
iOS Design Themes for Mobile App Designers
7 Tips for Landing Your First Client as a Freelance Developer
How To Ask For A Recommendation From Your Past Client