Blog

How to be eternally prepared for a Job Interview ???

Premise :

I got my first job when I was in college through a campus placement. First we had to give a timed aptitude test and following it up with a personal interview if we passed the aptitude test. I had to answer only one question in the personal interview round which was 'Would you be willing to relocate to any location for work ?' and you would have guessed my answer by now. It was a resounding YES. Why would anyone fresh out of college miss the opportunity to live in a new location all by themselves, especially when they are getting paid ??? and I got the job.


With in two years, I quit my job to join a startup in which i was a co-founder as well. So, as you guessed, I never had to give an interview for this job.


After four years, I had to find a job, since the startup was failing miserably. Out of the three companies I got interviewed at, one of them desperately needed to fill positions for a huge project and I got selected as I was ready to join immediately. My technical interview lasted for ten minutes and I joined with in three days. Thirty positions were filled with in next month. I thanked my luck and totally forgot that i did not perform well in my interviews, as I got the job. Who would want to remember bad experiences anyways ... right ???...


I was unmistakably wrong here. By this time, with out my conscious mind knowing it, I developed a phobia towards interviews and also a mindset that cracking interviews are hard for me. I should have made a note of this particular weaknesses and planned to overcome them while doing my new job with urgency. But instead, I totally swept it under the rug and focused on other things. Of course not all the things I focused on were bad. With in couple of years, i got financial discipline, I cleared my debts. I became fit, I completed half marathon. But the only thing I regret was not focusing on the eventuality that is facing another job interview.

 


Problem : 

So, after working for a couple of years in the same company, when i planned to settle down with a girl I liked, I thought some extra money could be of help especially since I would be starting a family soon. The fact in the IT Services industry is that, if you continue working for the same company you won't be able to beat inflation. Forget taking risk, you will hardly be left with disposable income to do a minimal SIP. Soon, you will go into debts if you do not have financial discipline and have that FOMO mentality and if you are susceptible to societal pressures. I didn't have any of that but the reality was perspicuous to me. I had to get rid of my fear of job interviews and get a new job with a good hike.


Solution :

Now I will start proposing a multi step solution to this hard problem, while detailing the mistakes I did and how you can avoid them and then you are free to improvise. My solutions are inspired by Cal Newport's Deep Work and Digital Minimalism and Scott Young's Ultralearning books. They are fantastic books and I recommend the readers of my article to read them if they haven't already.


1. Metaresearch :


First you have to research like a crazy person on things important to your job and vision for your next job. For example, write down all the tools being used or recommended by your team and one adjacent tool in that space as well and prepare a plan to master them. Let's say your team uses TeamCity for deployments. You can add Jenkins as well. Let's say your team uses Visual Studio IDE. You should try to see how another IDE like Webstorm or VS Code works or even go little crazy and try to work on VIM. Good luck exiting vim ;). Extrapolate this to everything related to your job like the tech stack you are currently working on and add the closest upgrade for each individual item in the stack. I am going to give my example for this, at the time of searching for my job interview, I was working on .Net framework 4.5, so I would also add .Net Core to the learning list. Since Microsoft was completely rewriting the framework and was putting considerable effort into this, it became immediately obvious that, trying to learn it wouldn't be a bad idea. By now I hope you got how to go about this step. Let's say for argument's sake that you are convinced to switch your tech stack say from .Net to MERN, I would still argue that learning the nearest upgrade is a good idea. But instead of going deep, you can limit the scope and learn the basics and move on to your new stack. You should also add your perceived weaknesses to this list.


After making this 'To Master List' of key tools and resources required for your job and for your next job, try to answer few questions on them available to you. Finding material for this should not be a problem. You can even form your own questions. This should be your initial check point to gauge your progress through out the journey.

This is very important step for people who don't know where to start since answering these questions would give them a direction.


After this step, you would have a pretty good idea about where you stand and the effort to put to reach where you want. You can even decide which company to join and if you can find somebody from that company to take your mock interviews etc. At least the search should begin. I know majority of us do such things exactly when you get a call from a company for open positions, but this should be essentially done in the beginning itself. 


2. Directness :


In this step, I propose to upload your latest resume to job sites and forward it to your colleagues, friends and family and try to take three or four interviews to get over the fear and also to do  a first real test of where you stand. Oftentimes we overestimate our capabilities and underestimate the efforts needed to move to the next stage. So, here is where I got my reality check. If you were not honest or overconfident about your own skills in the previous step, you would know here. Don't worry if this disheartens you. This is common for first timers, freshers and mid-level experienced people and the good part is you have identified it. Once the problem is identified it is easier to fix even if that is a complex problem. Also, you can remove or add to the list you made in the previous step based on the topics you were asked questions in the interviews. Sometimes you add your favorite topics instead of the important topics. So this is where that kind of filtering happens and what you get is a much more focused list. Once it is clear what needs to be done, you can pause taking interviews and start the learning part.



3. Drill , Retrieve & Feedback :


One thing I have noted over the years is that, your actual job is different from the interviews. In the context of a software engineer, they may ask you to code in a notepad, they might ask you to not use internet to search solutions, they might ask you to code in an ide of their choice, they might ask you to solve a problem, they could ask you to create an entire project, it could be anything. But when you are actually doing the job, you have access to so many resources and time to figure out the best possible way to do your job at hand. While the job is an open book exam, interview is a closed book exam. Another metaphor from cricket since I just couldn't resist this one. While Job is a Test match, Interview is like a T20. If you are tested on your problem solving skills in the job, you are mostly tested on memory in the interview. Since you are not practicing necessarily the same stuff asked in interviews, you are less prepared and will hardly have the memory to solve the problems in interview real time under pressure with out practice. So, I suggest to implement this radical idea explained below.


Cut down dependency on tools as much as possible. I can elaborate by giving few examples. Disabling intellisense while trying to code a solution to a problem with out worrying about compilation errors in the first round, then after you think you have arrived at an algorithm, enable intellisense and check where you went wrong with syntaxes and other language specific stuff. Another idea is to first finish coding for your task in your work environment, and then try to solve the same problem once again in a notepad without looking at the finished solution. Now, you might say, I already work in tight deadlines and so many emails to check, so many things to do etc. etc. But this active recall take hardly ten minutes more to implement for each finished task and the benefit is better retention. With proper planning and strategies listed out in second step, you should be able to extract some time for these steps and also, this step feels initial very hard, but once you keep doing it, you will start enjoying this and times start tumbling down. You can also try to solve other colleague's problem using notepad and check the solution later once they check in the code. You don't need to solve all the other tasks, just one or two based on your schedule and if the problem falls in your area of interest listed in first step and filtered in current step. You can try more things like learn a technology and implement your entire work project in the new technology. If you learn a new concept in technology, try to imagine if that can be implemented in any of the areas in your project. Learn a new language feature every week and try to refactor the code using the same. Give this enough time and start attending interviews again. Repeat this process till until you are cracking interviews one by one with out setting time to prepare separately.


The idea behind this radical approach is that we often start becoming slaves to the tools we designed initially to help us do our job little better. It's similar to how people get addicted to coffee, smoking, drinking and drugs. First it starts with a little drag and then with in couple of years, you are chain smoking. Even though the effects are not that drastic with being dependent on tools the cycle is same. We should be aware of this and try to minimize the effect. The irony with job interviews is that while testing our problem solving skills in the job, we are tested on memory during tests. So, if you are giving an interview, the burden of memory should not weigh down on you while you are trying to pin the problem down.


So, instead of watching tutorial after tutorial and giving interviews only after feeling adequately prepared, start giving interviews immediately, take feedback, note important concepts, drill down on your weaknesses, stuff you want to improve and which are important for your current and next job, implement them by carefully scoped projects and repeat the cycle. Make notes on how you solved them. Recall them later and cross verify with the notes. Write a blog or make a video or explain how you solved a problem to your colleague.


Intuition & Experimentation:


After going through certain cycles of third step, you would develop your own intuition on how to approach any problem in general and you will start experimenting with the methods. The only suggestion would be to note down how you are experimenting, on what you are experimenting and results you are expecting, give an experiment enough time and observe the results. Embrace what is working and improvise. Discard what is not and get lean.



And that's how I expect to become Interview FIT !!!


The main reason for writing this blog is that I am in that job searching phase again and I wanted to take a more methodical approach this time. So, i took what worked for me last time, mixed it with the science behind learning from Scott Young and Cal Newport's works and presenting here for fellow experimenters and learned critics. So, try this out if you do not know where to start your preparation and let me know if it worked. I am excited to hear what you have to say.



All Blogs