The New Era of Interviewing
It is a sad reality of the Software industry that most folks have to spend days, weeks and years, sometimes to re-calibrate themselves for interviewing. The notion of practicing on Leet-code, reading books and videos on System Designs is the mainstream advice being given to peers, who want to pursue opportunities within and outside of the orgs.
The main reasoning of this problem is that how else can one figure out if someone is equipped for the role or not. Hence, people are sweating on how to somehow make their marks in the world of Leetcode and System Design.
Why is this a Problem?
This is a problem because switching roles and finding a job is a second job in this time. It also creates a sense of distrust that what one is doing in their current day-day work is somehow completely irrelevant to what one can do. This is like having to write the MCAT test each time a doctor wants to switch or a lawyer having to appear for a BAR, every time they want to try something else.
So, What is the Big Deal. Just Invest Time in Leet-Code?
The reason this is a big deal is that instead of building the love, passion and interest of learning, growing and maintaining a skill set, engineers are following a hard-core system of a peer-pressure driven model.
If one is not using Dynamic Programming, Depth First Search and specific design concepts in their every day job, then why do they have to keep these concepts fresh on a regular basis, just to prove their mark somehow?
If these concepts are completely outdated, then why are we stuck on asking these in our interviews?
Back in the infancy of the Software industry, it made sense to make someone code on the white board, as the field was so new and fresh. But today it feels that the field has moved on far away, but our benchmarks of evaluation are still at ground-zero.
So, How Do You Hire and Distinguish Good-Candidates from Not?
Why can we not do what other industries do? Why can we not rely on someone’s existing experience and references?
If not, then would it make sense to do a full-fledged hackathon level interview, where people work together with hiring managers on the actual job and are asked to learn, code and work together, for a week before making the hiring decision?
That way at least the work that one is doing in an interview is directly relevant to the work that the team is going to do? Also both the interviewer and interviewee can determine the actual passion and skill-sets for someone about the actual position?
What’s Next?
I think it is time that the Software Industry moves away from the pure practice, learn and prove model of obsolete coding, that is no longer deployed in every day jobs. We need to recalibrate our hiring practices and focus on the model of Growth, Team-Work and Learning on the Job models, instead.
What to do Till We Get There?
The main advice I give myself and my mentees is that if one is spending time and effort to review theories of Computing, one should not do it in a brute-force way of somehow having to land a job.
Rather, one should focus on learning the depth of that technology.
So, if someone is spending a weekend studying Dynamic Programming, then instead of beating oneself up to finish that question in the 20–30 min mark, the focus should be on understanding and learning. It is important to understand, what is Dynamic Programming, what is it doing and how is it being applied. This way, one is building a genuine passion for the technology and even if they do not fulfil the mark of a certain interview, they are still building a skillset in their belt, that can be used for further growth.
We have all learnt these concepts in our Academic times, but with the lack of usage, somehow these areas are rusty in our brains. Instead of approaching these problems as a test, we have to approach them with the idea of Re-Growth.
Also, while we are at it, it would help if we can take these learnings and start to apply them in our every-day jobs or other passion-projects simultaneously.
