My First Technical Interview Experience + Tips!

#career #computerscience #firstyearincode #beginners

Hi everyone! I was so excited to land my first technical interview with a large company that I thought it'd be super cool to share my experience with all of you!

Honestly, I've been dreading the technical interview for a while. I've been studying data structures and algorithms as much as I can (as you know, I feel like data structures are all I really post about! haha) but I still haven't felt truly prepared for a real interview.

I also do mock interviews with some of my old classmates from Flatiron School which is sooo helpful and I could not recommend that more. Being able to simulate an actual interview, even if we are more comfortable with each other than we would be with strangers, is still extremely useful and good preparation.

But on to the actual interview!

It ended up being very casual and was half work-style questions and half technical. The question was meant to just test my thinking and problem solving abilities and ended up being a leetcode easy question.

I ended up actually solving the wrong problem, which the interviewer told me after finishing my solution 😂 But it was a good lesson to learn and after clarifying I was able to come up with a correct solution to the actual problem.

The interviewer was very nice and told me I could ask for tips and he could give me hints, but I was a bit too nervous and just debugged most of the problems myself. I did not get the chance to run the code but he had specified that I wouldn't be able to.

I used the technique that has been outlined by many others online and I find to be an awesome way to approach problems:

Ask clarifying questions
- Honestly I feel like this step is half so that I can ensure I am fully understanding what the question is asking (because that's super important!) and half buying myself time to think of a solution.
Think of good edge cases and ask for multiple examples
- If you can, edge cases are a great to start before you begin coding and they're pretty important. It's okay if you don't come up with any right away, but it's good to keep in mind throughout the coding process.
- Also it's just my personal preference, but I like to ask for multiple examples because I feel like it helps further my understanding of what the question is asking. Totally optional though!
Take some time to fully think of solutions and get ready to discuss the best one you can come up with. I always felt awkward before being very quiet during this time, but if you just ask the interview for a minute to think, they usually don't mind.
Discuss your solution with the interviewer and write some pseudocode
- Now that you've thought of your solution (don't worry if it's not the most optimal), describe your thought process and step by step go through how you would solve the problem. You can ask the interviewer what they think of your solution and they will either have feedback or tell you to proceed.
- I find it is also helpful to write out (commented out of course) the process you have thought of. This step tends to be preference as well, but I've yet to think of a time when it wouldn't be beneficial to have your thought process actually written down. In the instance that you don't get to finish solving a problem, at least anyone who sees your solution will be able to read what you were thinking and hopefully understand how you would have finished the problem.
Get to coding!
- Alright, now that you fully understand the problem, thought of all the edge cases, came up with a good solution, and wrote down your pseudocode... you're ready to actually code! Do your best to stick to your solution and if any issues arise, go ahead and bring them up with your interviewer.
- Depending on the interviewer they may offer tips or help you understand where you're going wrong. Even if they stay silent and allow you to struggle on your own, don't worry, just stay calm and debug as much as you can.
- You got this!
Unstuck yourself if necessary
- Personally, my nerves tend to get the best of me. And in my interview I couldn't get my last loop to return the correct output. I knew what I needed but was getting lost in debugging one line.
- So I took a breath and started back at the top of where my problem began. For me, breaking down the problem into small pieces and putting print statements where I don't understand outputs is super helpful and weirdly calming.
- You know what works best for you, but if you do get stuck don't worry and just take it step by step until you can find where the bug is that's breaking your code.
Testing
- Sometimes your interviewer will allow you to run the code (which is awesome!), but if they don't, that's okay too. Just make sure with them first before you try running anything.
- In the case that you can't run it, go through the code step by step with one of the examples, ensuring that the outcome is what you expect. I honestly prefer this just because I find I catch the most bugs this way.
Space & time complexity
- My first interviewer didn't ask me for anything pertaining to big O, probably because it was just a skill check. But my second interviewer (more on that next time!) did, so of course be sure to know how to calculate that. I have a handy space complexity blog post if you need a little refresher.
You did it!
- You made it to the end of your technical interview! Congrats :) Whether you struggled the whole time or it was a walk in the park, I think either is a good learning experience and every interview will make you better.

Thanks for reading and if you have any technical interview advice to share, please do! It'd be awesome to hear your technical interview experiences and stories as well.