Your first technical interview can be a stressful and nerve-racking experience. The pressure that comes along with a technical interview can make even the most seasoned coders choke. Luckily for me, my first technical was a mock online interview on the Skilled Inc platform. However, even though it was a mock interview I was dreading the experience all day, a fact that my interviewer and I joked about once the experience was over. So let's dive into a high-level overview of the process and my thoughts on the experience.
Skilled Inc's technical interviewing experience pairs you with a real Software Engineer that has been sourced from a top company to facilitate the interviewing experience. The interviewers on Skilled's roster are thoroughly vetted to ensure they have extensive industry experience and knowledge so you know you are working with the real deal.
For my interview, I decided to use Javascript as my preferred testing language as I felt the most comfortable with it at the time. Unfortunately, I am not going to go into the specifics of the problems I was given out of respect to their process. However, I do want to go over some points that I took away from the process that should hopefully help others when approaching these types of interviews.
- Understand the problem
I cannot stress this enough, it is imperative that you understand the problem to its core to ensure you can solve it correctly.
This means thinking of the expected inputs. What is the expected output and how should any edge cases be handled? These are things you should be discussing with your interviewer in depth before you even start to solve the problem. Ask as many questions as you can, they are not going to look down on you for doing so!
- Explore real-life examples
For a very simple example, imagine you're asked to reverse a string? What are the inputs going to look like and what is the expected output after running your code?
IN -> "Hello World!" OUT -> "!dlroW olleH"
Writing this out to see a visual representation of the expected behavior can help determine your approach.
- Outline your process
For me personally, this is very helpful as I can outline my approach at a very high level and step through my process to ensure I am not missing a step before diving straight into code.
Using the reverse string example from above an easy straightforward approach could be the following:
- Check the length of string..(don't forget your edge cases)
- Convert string into array use the built-in split function
- Reverse array, use the built-in reverse function
- Convert reversed array back to a string, use the built-in join function
- Return final value
Seeing what you need to do in plain English makes it easier to then code your solution. It also gives your interviewer insight into your thought process which is very important
- Be aware of performance constraints
You need to be consciously aware of the performance of your solution. For me, I don't know exactly what a built-in function like reverse() from the above example is doing under the hood. Built-in functions can often times have negative effects on the performance of our solutions when taking into account the worst-case scenario for our input.
- Refactor your solution
If you ended up using a brute-force approach to solve the problem and you're completely aware of this please make it known to your interviewer. Them knowing that you are actively thinking about the most optimal solution from a performance standpoint will definitely help you stand out. If you have time left in your interview use that time to optimize your solution, sometimes good enough isn't really good enough...
- Clever code isn't always good code
I'm not going to lie I tried to be pretty clever in my solutions and unfortunately under the pressure of the interview my clever code didn't quite work as expected. If you have spent any time on Codewars or any of the other similar platforms it's quite common to see one-liner solutions to problem sets. While these may give you the impression that the person who wrote the solution is a god among coders, these types of solutions are not optimal in a professional setting.
Writing code that is hard to understand requires more cognitive output from your other teammates when maintaining said code.
“Any fool can write code that a computer can understand. Good programmers write code that humans can understand.” - Martin Fowler
- Have Fun!
I love spending time on Leetcode, Hackerrank & Codewars. Everyone loves getting a win under their belt and those types of sites give me thousands of opportunities to do so. Don't let the pressure of the interview setting take the fun out of the process, I mean you love to code right!?
I hope the points outlined above can help you when approaching a technical interview as they have definitely helped me. Oh, and if you're wondering I did receive a pass on my Skilled Inc interview. I would recommend that platform and their process to anyone, although it is a little expensive. If the cost is out of reach at the moment try to link up with a friend or someone senior to conduct your own mock interview. You can never have too much practice.
Top comments (0)