Today, I’ve stumbled this computer science post about job interviews and algorithmic skills. Why do we quantify and evaluate one’s cognitive process in solving algorithms to enter the workforce? And why often does our algorithmic problem solving skills deteriorate, even though the heart of computer science is all driven by math and logic? Shouldn’t programmers be top-of-the-line in terms of interviewing?
There exist a moment in which a new grad/intern faces a challenge that determines the outcome of being broke or being finically stable. Of course, the main premise of such entry of barrier into tech jobs exists to ease the process in the recruitment side while also leveraging the power of quantitate measurements as a threshold for competence.(i.e. algorithm & behavioral interviews score as a stopping rule), in such that probability of hiring an individual that contributes to the company efficiently becomes higher upon filtering out applicants who fails the coding interviews. On the essence of Leetcode and the valuation of one’s skillset Algorithmic and Implementation skills are favorable in an interview. A standard cycle of a new grad is to grind leet codes in one sweep; where all the programming and algorithms knowledge is converged into a singleton — A whiteboard or a phone call interview. Here’s the fact: A new grad whose new formation of skills comprises of solving algorithmic problems 2 week prior before interview has a higher chance of being recruited than a programmer who’s done real-work experience. In Cracking the Coding Interview by Gayle, the author provides an unfortunate event emphasizing such dilemma. Why is that? In the workforce, where our thinking is thrusted with good design, stand-ups, back-end, and front-end; our thoughts favor top-down thinking and implementation of APIs rather than concrete problem solving skills of building such algorithms from scratch. In the algorithmic world, we’re focus in thrusting our memory with the types of problems we’re confronted in a given problem statement. With time and endurance, you’ll recognize that every problem statement is similar to some previous prior knowledge you’ve been doing with algorithms and data structures Why waste making smart code when there exist a library that already does that. Your productivity is measured by the amount of users you can retrieve and retain. Not the runtime of your algorithm. The key premise is that APIs are well-designed and thought out, that doing the hard problems is less efficient and slow when money is on the line. Most of our work focuses the scalability and code readability. The very specific math we often learned in our algorithm classes such as omega notation, skip list data structure, the proof of why trees have logh height, amortized, and probabilistic analysis, is often shallow when we do projects or work. Are these crucial and valuable skill only useful for academia reachers in computer science? and not software engineers in general? Yes and no. Most of your time won’t be dealing with writing mathematical proofs to why your algorithm is the most efficient, but when things get real, you want to work with people who can dig deep and conjure something special. That algorithm you just formulated may be worth millions.