Coding Interview: Q and A

There is no hack for finding a position, please be honest in every interaction.

Question and Answer is often a part of the interview that can build anxiety for some people. This is an area where they are actually trying to find out what you know. There are right and wrong answers to many of these questions. But no matter what the question is, how you approach answering this question talks to who you are, and the employee you could be.

If you do not understand what they said, or fear you may have a lack of clarity on the ask, it is ok to re-iterate the question back to them before answering. Or clarify by re-asking the question in different words. This can allow you to communicate your desire to be clear and not waste anyones time, but also it will make sure you know what they are actually asking your for.

If you are asked a question that you know really well, Try to answer it clearly, and concisely. With these questions, we are usually so excited that we know the answer that it is easy to speak too quickly and jump around a bit. Make sure to keep breathing, answer the question that you heard. Then, it is ok to clarify with them if that answered the question they were asking.

If you are asked a question that simply don’t know the answer to. This is a moment to breathe, and be honest. “I actually don’t have experience with that, I do not know the answer.” Sometimes, if it is something I have heard of before, but don’t know well, I might ask, “If time allows, would you mind explaining it to me?”

If it is one of those questions that you know a bit, but there is a lot of stuff you do not know, think about our overarching principals to taking this interview. Be honest, be clear, and do your best. You could speak clearly to the pieces of the question you know, and sometimes you can even talk about the experience you have with them. Then you can also identify that you have heard about, seen, or maybe even started reading on other aspects to this question. This is good because it helps them to see that you are willing to learn, and you are aware of pieces that you do not know. And to me at least, this is a very endearing response. I value people who can tell you what they know and not presume to know everything. Personally, I have been coding for .. 23?.. years now… I still find new things I didn’t know about. It is OK to not know everything when you walk in.

Information on specific questions:

This is often to test your breadth of knowledge in the area. And identify where they could place you if you were to get a position. 

Questions could relate to:

• syntactical parts of any languages that are relevant to the position. 
• outside cases and pain points within a language(s)
• Data Structures & Algorithms. (It is worth taking some free YouTube courses on Data Structures and Algorithms so you have a basic understanding.) I hope these won’t be asked, but left for your actual coding test.
• I often like to ask questions here about specific pieces of a language or a recent release that have brought value to the engineers.
• Another question I like to ask is: “What is something that you really geek out about when you are programming?” I really want to know what is exciting for you about the work we do.

Questions to watch out for: Remember, you are interviewing them too.

• Questions that are asking about “What is better”. Questions like this can be answered, but should be prefaced with caveats. “I personally like React better than Vue because I have found that documentation in Vue is hard to locate as a solely front end language. It seems like the Laravel Community really wants you to think of them together.”
• Questions that seem like the interviewer has a bias they want you to lean into. I have often heard an interviewer ask questions like: “Do you prefer functional or class-based programming?” Notice this is already a question to watch our for because it is a “What is better” question. But this question often only comes up if the interviewer has found some reason they needed to care about, and is coming to you with a specific “correct” answer in mind. For these, I recommend an answer like above, with caveats, as well as clear non-bias response. And if you know about either side, it is good to elaborate. “I try not to decide on a technology before I understand the problem. For organizing large projects, I have found that a classes based design can really allow the application to be easier to maintain and the code is easier to trace due to the almost “built in” naming conventions of your objects. But for smaller or utility style problems, I have found that functional programming is a better choice because it runs faster and really lends it self to use pure functions.”
• Questions (From the coding or design interview) that seem to be solving a challenge for the company. I have had several interviews where my task to overcome was solving a problem they couldn’t figure out in their work. This should cause a MAJOR Red flag in your mind because your interview is not free work for their team.