My Tech Interviews Experience
Today, I hit my 6th month mark of my job searching journey. Yep, 6th month. A lot of my new friends that I have met over LinkedIn are getting job offers. Of course, I am really happy for them, yet it was really tough for me whenever a friend told me they got a job offer because that means… they will no longer be in this journey with me.
One of the most frustrating moments throughout this journey was that I was not getting a lot of interviews, until a couple months ago, I finally got my first tech interview, which I was in the final round… and yep, I got rejected, because of my lack of knowledge in React lifecycle methods in React Hooks (I knew how to use componentDidMount and it was a huge deal to use useEffect as it was my first time at that time to actually knew how to use that). Ever since that interview, I understood my strengths and weaknesses and was much more determined to be a way better candidate.
It took me another month or so to finally get two more tech interviews — in total, 3 tech interviews throughout this journey. I knew very well that I bombed both of them, but I was super grateful for these two interviews. And interestingly, the contents of the two interviews were very different. One of them was the traditional kind of whiteboard interview, which I was asked to solve a medium Leetcode question, and oh my god, I was freaking out before that interview, because I was aiming for front-end position and did not spend much time studying data structures. The other one was parsing a CSV data, i.e. turning an extremely long string into a nested, organized object.
I also have to point out that I did use mock interview platforms, like Pramp, a few months ago. I had a hard time breaking down the questions. I am still not very familiar with graph and dynamic programming as of today. At this moment, I have no intention learning the more difficult data structure concepts as I am not aiming for large tech companies.
Here’s my takeaways from those two interviews:
- Print the inputs in a function if struggling
Always console.log the inputs, especially if I have a hard time seeing it. What I mean by that is that sometimes there is something hidden in that string you are provided, or in my case, even the interviewer hinted so many times there is a line break. It was not inside the string and I did not realize that \n is what she meant by line break. After I was struggling on how to split a string with this “line break thing”, my interviewer gave me a big hint to console.log the input by splitting the string into an array, and yep, now I see that \n hanging inside the array.
2. Work on the working solution first before worrying about the optimization
Throughout the two interviews, although I had a working solution in mind, my brain was always worried about whether the solution (or pseudocode) I had was not optimized enough. In the end of the interviews, I only had the psuedocode written, but not the actual code. In both times, my interviewers helped me break out of my confusing cloud by telling me to try to write my brute force solution first and run the code and this leads to my next takeaway.
3. Run the code while writing the solution if unsure
I have heard that sometimes in the interview, they don’t let you run the code in the middle of interview. However, I was allowed to run the code as many times as I needed to, and you know what, my inexperienced brain was not smart enough to understand how important that is. During the interviews, I had my pseudocode ready and I communicated with my interviewers what I would want my solution to look like and my head was in the confused mode wondering whether it would actually work. As I continued to communicate with my interviewers and get more and more confused with myself, both my interviewers told me, “Why don’t you go ahead and try the run the code?” And yep, I knew how my code looks now… it was quite close to the sample output, yet and got so much to work on… but it was already the end of the interview.
4. Don’t just talk, write the code and get it work
This takeaway is probably a summary for all the takeaways above. My biggest strength is that I am good at communicating. I heard that dozens of times from different people. Despite being good at communication is a good soft skill, interviewers/employers want to see how good you can code. I spent so much talking about my solutions that I didn’t even have enough time to have my full brute force solution written.
It could be some imposter syndrome going on, ’cause I remembered during the interviews I kept thinking, “I don’t think I can do this.” So, I usually use talking to help ease my nerves, but that doesn’t demonstrate my programming skills.
5. Break down the problem piece by piece
This is probably the most cliche takeaway. I am a big picture person, so I like to see the big picture before getting into the details. I realized it was a huge disadvantage for me, as I would spend a lot of time figuring out what this particular question actually do and why I need it. After a few interviews, I realized although having a big picture is important, more importantly, it’s how I would break down… let’s say an extremely long string. Questions like how would I split this string, or how would I push this to an array, or how could I make this element into a key of object, etc. These are more obvious examples/questions, but it really helps when you have an input and output in front of you and you have to figure this out piece by piece until you get a working solution.
It’s similar to how you solve an algebra question like 3x + 1 = 6x + 5. Like you won’t start immediately think what x is. Yes, that’s the end goal. But we have to think like how to get all the x’s on one side and all the numbers on the other. It’s similar to how we solve a data structure.
Now I am at my 6th month mark. I am really hoping to get more tech interviews. I am okay if I bomb the interviews, because in each interview, it teaches me different lessons and know what I have to improve on. Same goes to all of you readers who are reading this today. Don’t let one interview that you bomb devastated you, it’s a way to grow. If you bomb an interview today in your dream company, don’t let the rejection unmotivate you. I have seen dozens of people from LinkedIn feed getting into their dream companies after a couple years of work experience. The rejection is not the end of the world.
If you read till the end of this article, I appreciate you. I feel like this is more of a reflection journal, and if you find that my takeaways/mistakes are helpful, I hope that you would also understand and learn my mistakes and not make the same mistakes I made in your interviews. So, good luck!!
Last but not least, get your coffee/tea, dance to some happy music and happy coding!
