I have been doing a ton of candidate interviewing over the past year, and have formed some opinions about the process. So what does a software person of many years do when they have opinions? Write a blog article, of course!
I have tried to think of things outside of just having specific experience or knowledge. Even if you nail these it does not mean you will do well on the job. Conversely, if you are weak on either it does not mean you cannot do a job well. What can be communicated to let the interviewer know that you are capable and have strategies for handling different situations (or how can you judge how well a candidate will do)? I am still figuring it out, but I wanted to share a few of the things I have come up with over the years.
General
Learn to judge how detailed your answer should be
Not every answer needs to have large amounts of detail in them. The urge is to show that you really know something, but that may not be what the interviewer is interested in. They may have specific follow up questions, which they may not be able to ask if you give a mini lecture.
I have found balance by including enough information to cover what was asked (and maybe a little extra, if short), but then ask if that was enough or should I provide additional details. Sometimes it helps to mention you will shorten your answer in the interest of time.
It's ok to not know something, but don't make up an answer
No one knows everything and even if you do, you can temporarily forget. StackExchange would not be around if this was not true. If you do not know something, just say so but also say what you would do about that. You can say how you would find out or how it is similar to something you do know.
In any case, do NOT make something up. Your interviewers will most likely know you are trying to cover up not knowing. Doing this on the job leads to bad results and decreases trust in you. And in some cases interviewers are testing you to see what you do when you don't know something. Make a good impression.
Be honest about your level of experience with X
Everyone stretches their experience a bit on their resume, but do not give the impression you have much more experience with something than you do. Especially if it is something in the job description, you will likely be asked questions to ensure you do have the experience.
If you are only familiar with a certain technology, just state that. You can use this as an opportunity to bring up similar items you are more knowledgeable about. You can also segue to an example where you had to learn a new technology/skill quickly and your success. Like the previous point, showing you are enthusiastic and have a plan while being honest can work in your favor.
Technical And Coding Tasks
Talk through your thought process
The most important thing to do when tackling a technical exercise is to let the interviewers know what you are thinking. Silence is awkward but also does not give information to the interviewers. You can ask for a moment to think, but even if you do not have complete thoughts you should describe what you have and where you are going.
As you implement a solution, either explain as you go or produce a small amount of content and recap. Be sure to explain why you are making your choices in addition to what you are actually doing.
It's ok to make a mistake
Almost no one can produce a perfect solution the first time to reasonably complex problems. If you discover you made mistake, do not try to hide it. Admit the mistake and fix it immediately if you can. If the cause it not obvious, do some quick troubleshooting to determine if you can fix it in the remaining time. When in doubt, state what you think is the cause, then ask if you should keep troubleshooting or continue with the task as best you can.
Making a mistake in an interview is difficult. It throws off your flow and can cause you to worry about the consequences. Try to push that aside for the moment and remember an important part of the interview is demonstrating how you handle these situations.
Scope your solution to the time available
It is much better to produce a sub-optimal answer than nothing at all. Do not try to come up with the more efficient or bullet proof solution at first. Mention that this is your initial iteration and it can be improved as needed. You can also give the overview of your idea and that you will figure some of the details out as you go.
You can mention assumptions or leave out portions of the solution not directly relevant to solving the problem (ex: guard clauses to check parameter values). Of course, mention you though of it, but will skip due to time and an revisit if there is time.
Be sure to give a complete implementation
A continuation of the previous topic, you need to be able to deliver a complete solution within the time you are given. Maybe it will not satisfy all the requirements, but better than an incomplete solution that leaves the interviewers guessing how you would turn your ideas into something concrete. Time management is an important skill to demonstrate.
And if you do run out of time and are incomplete, quickly give an overview of what if missing. You probably do not need to say why you could not finish. If appropriate, you may ask if you can send a complete solution via email. However, this is typically not needed unless you were very close to finishing.
Conclusion
I hope these thoughts were helpful. Interviewing is difficult, but try to remember that how you convey your abilities is as important as your knowledge. Fortunately, just vocalizing your thought process, scoping your answers, and asking if more information is needed can help. And remember, no one is perfect. How you handle this is important information for the interviewers.
Good luck out there!
Top comments (0)