Since finishing my software engineering bootcamp at Flatiron School last month, I've spent the bulk of my coding time getting ready for the job search, and last week that involved doing a mock technical interview through Skilled.
Despite reading all I could find about technical interviews, and going through whatever concepts the program and the articles I could find said to study, I wasn't quite sure what to expect.
Post-mock interview, these were my biggest takeaways:
1. Talk/write your way through it
One of the things my interviewer mentioned I did well in the interview process was that I understood what was being asked of me. I was able to convey this understanding by talking through the problem out loud and also writing down the steps of what I wanted my code to do. All I have read about technical interviews says that interviewers want to know about your ability to problem solve, and your process, and this was definitely my experience!
2. Knowledge of algorithms and data structures is helpful even when you're not asked about it
In preparation for my technical interview, I spent a lot of time studying things like different data structures, Big O Notation, and algorithms I hadn't encountered much of during my course but were recommended knowledge for interviews.
I didn't get asked about any of this directly during my technical interview--I had the whole hour to solve one (complicated!) JavaScript problem--but it was relevant anyway.
At one point, I came across part of the problem where I could have dealt with things by split()-ing a string into an array, altering each element separately, and then join()-ing them together as a string again. I decided not to, because that would further increase the algorithm complexity, and found a way to alter the string while keeping it a string instead.
When I explained this reasoning to my interviewer, they said it was a point in my favour: that I coded that part of the solution in a way that didn't increase algorithm complexity further, but also that I did it deliberately and knew why that choice was a good idea.
3. Find out in advance what the interviewer's policy is on asking for help/using the documentation)
Where I started to get tripped up in my interview was when I reached the point of the coding problem where I would usually think, "ehhhhhh drat I know there is a function that does this, I am going to google and find out what it is." I asked my interviewer if it was alright if I looked up the documentation, and they let me know that was fine, or I could just ask them. This was a big help in progressing through the interview, so I'm very glad I asked! With that said:
4. Stick to what you know (and brush up on your functions!)
I spent a lot of time during my interview trying to remember the right function to solve the problem, because I knew there was one, and it just wasn't coming to mind. While this was true, there were better functions than the ones I was using, trying to remember these functions wasted valuable time, and, as my interviewer later pointed out to me in feedback, it would have been fine to say "I know there are better functions to use in this situation but I'm just going to do this for now." So, there are two other key things here:
5. Prioritize
The interviewer wants you to solve the problem in front of you, or at least as much of it as you can. Another way I stumbled in my interview was spending too much time trying to figure out the specific right way to solve one part and not leaving enough time for the rest of the problem. Pausing to think more about what was important in the problem, and maybe a, "let's assume I have a helper function that does this" would have saved me a lot of time in my interview. And, finally:
6. Be confident (/you are a job seeker, not a student)
The main thing I forgot during my technical interview was: I'm not a student anymore. As a student it's alright to say, "I know there's a better function for this, can you remind me of what it is?", but as a job seeker, you need to project confidence. Focus on the parts of the question in front of you that you can solve, use methods you're confident with--overall, employers want to see your problem solving skills but they also want to know you can handle yourself without handholding. It's okay to admit to not knowing something if asked directly, or if it comes up, but overall, you'll look like a much stronger interview candidate if you can solve the problem in front of you showing off what skills you do have (and what things you do remember) instead.
During my mock technical interview I learned a lot of valuable information about what to do and what not to do during the real thing, and I have spent the past few days putting my skills to the test finishing my solution to the problem I was given during the interview--and then solving it again in a better and more efficient manner. (It was a tough one!)
The one thing I wish I did more of before the interview itself?
Practice, practice, practice!
As well as studying up on algorithms, data structures and functions/methods of whatever language you're interviewing in, a good way to prepare for a technical interview is to practice solving problems in that language. CodeWars has been helpful to me so far, I have heard good things about HackerRank and CodeSignal, and there are many others out there.
I hope this is helpful to anyone else looking at starting interviews, and good luck!
Top comments (0)