5 Tips for Accessing the Technical Interview Mindset

Lucas Thinnes
5 min readOct 13, 2021


As a bootcamp grad, the gap between finishing up the work with the given program you chose and actually landing a job can feel like a gargantuan one. So many questions come to mind along with their accompanying contributions to the seemingly unstoppable dread of imposter syndrome that the haul can feel like like a Sisyphusian struggle most of the time.

However, sometimes you get startled, as I did last week after applying and networking virtually nonstop for 6 whole months, and somebody actually wants to speak with you and put your skills to the test. The shifting of gears in my mind felt like watching an ancient piece of machinery trying to run after sitting dormant for over 100 years. I had no idea what to prioritize or how to prepare after being in job-hunt mode for so long. The overall experience was constructive and I learned a lot about myself and the process, so I wanted to impart my reflections onto the curious minds who may be psyching themselves out over the prospect of doing a technical interview!


It makes sense as the idea of cramming was probably inflicted upon us during our time in middle school, high school or college; the first time in our life when the idea of balancing what you want to do with what you need to do has slightly more heavy implications. However, there are lots of differences between the interface of filling out a final exam and solving algorithms on the spot, primarily the interest in your thought process with the latter. With instances where the outcome is still make or break, obviously the results will still be important but from what I understand, a lot of the time interviewers are looking at how you break down problems, work through roadblocks, ask for help and manage the pressure of time constraints or working slightly beyond your level. With this being the case, any intensive cramming beforehand will most likely be out the window with all this stress, so do what you can to review principles which are already under your belt as opposed to stuffing your psyche full of new information which probably won’t stick.


In my mind, the only thing with not knowing the answer to one thing or another in this domain is having any sort of defensiveness or self-deprecating response. Web development is an inevitably limitless field, at least to what the human mind can absorb, and there are assuredly countless cases of companies deciding to go with younger talent as opposed to people who have been doing it for decades for the sole reason of the mind’s plasticity and ability to work with newer languages and frameworks instead of paying somebody to be retrained in a way that could yield antithetical results. By acknowledging you do not know the answer to something you do two things for yourself; you demonstrate humility and avoid making an embarrassing mistake. If the person conducting your interview is gracious enough to offer advice or help you out, it is a sign they want to see you succeed and the best response is to show gratitude or curiosity extending beyond your knowledge and convictions. It shows growth is at the forefront of your concerns.


This one probably shows up frequently but it is fairly crucial as the benefits are twofold, you get to buy yourself time processing the prompt and also show vulnerability in hopes of not making an embarrassing mistake. If the interviewer does not feel like catching you in the moment of vocalizing something erroneous, it could be a bad sign but not the end of the world. They could want to see your process of becoming unstuck or how you would ask for help (if asking for help is permitted, which is certainly worth having clarified before beginning the interview). You can also think aloud in a very slow way as a small practice of slowing things down if you are soothed by the sound of your own voice ;)


For the record, the kind of interview that I had was to build a music blog with Rails + React in 90 minutes. Knowing that I have a propensity to obsess over design in a way that can slow down my ability to implement functionality, I chose to not tackle styling until the very end (after time ran out, to be clear). In this scenario, I had the ability to do things in the order that I pleased and so I began with building the backend out to fit the schema of a blog post as I had done this many many times. The fumbling came around by the time I started looking at the documentation on Bootstrap for designing, but by then I already demonstrated enough of my abilities to not look like an absolute novice. This is of course a case-by-case piece of advice, but it allowed me to stress way less and I highly recommend taking this approach if it is available to you.


At the end of the day, technical interviews should be learning experiences for both parties involved. The odds of absolutely nailing it on your first opportunity to show your skills may be slim, but you should hopefully walk away from it knowing what you need to focus on. It may not be a bad sign if no feedback is offered for you, but it there is time and space for the interviewer to address anything that seems pertinent, understand that this will be extremely valuable input. The best thing you can do is receive it with a humble and clear mind. Always thank them for the help along the way, and if the proceeding steps aren’t made clear to you immediately or you receive a rejection letter a few days / weeks later, go easy on yourself. There is a place for you in this world, and it can take time to reveal itself to you. The worst thing you can do is dread the consequences of a failed interview because the only mindset that will aide you in success is one of growth and positivity. Despair wins neither Heaven nor Earth. At least you got one under your belt and out of the way, so take from it what you can build upon it on your next opportunity!

Hope some of this can be useful to you. Thank you for sticking around and best of luck to you!