Full disclaimer: As I am writing this, it is 5:32 AM in the morning for me(Eastern time) and I am restless, so I chose to write my thoughts that (hopefully?) can spark a productive conversation. I'd love to hear peoples' thoughts.
I know I am still new to the industry and I have a lot to learn and experience. The one thing I just cannot seem to grasp though is the constant talk and reiteration of how the process has grown out of control, hurting potential hires who end up quitting the industry before getting a foot in the door because the interview process has become so.... unhealthy.
Yet, I hear this a lot and very few offer solutions or just say to continue feeding into the broken process that is starting to fester like a sore that has not been given proper attention and treatment. Or perhaps, I should say, the process is working as it's intended to be which is snuffing out potential talent that do not pass the criteria that the broken process singles out to seek after like a moth seeking a light source.
Aren't Technical Interviews meant to gauge a candidate's ability to organize and gather pieces of logic in one's mind in the sense of bringing a solution to a concrete problem, thus resulting in showcasing how one would design or architect a solution? How is LeetCode and HackerRank supposed to help solve this when it's the same questions and answers that can go down to mere memorization? Is it not, in that manner, just competitive programming where one can invert a binary tree in 30 seconds because they have done it millions of times? I admit, I think LeetCode and HackerRank can be great practice for one self-learning or in college and has yet to graduate.
However, although it is a good source of practice, the fact of the matter that LeetCode and HackerRank questions are used as a indication of one being granted an opportunity of a job that bring about a significant difference to one's life, in addition as used as an indicator of being a "good enough Software Engineer" seems to do more harm than good.
There are people memorize a Data structure and algorithm problem, but can they actually code from scratch or debug an existing script that has nothing to do with DSA? Do they know how to do Test Driven Development? Do they know how to pair program? I've heard time and time again, depending on role you go for, DS&A will barely be used in the actual code-base itself. How are interpersonal qualities measured? Or does that not matter as long as they know how to spit out code?
I've heard from people that DS&A is just a filter to weed out people that can't pass medium-hard problems on leetcode, hacker-rank. So what gives? I genuinely wonder.
Perhaps I say this because I've been told how I am not capable of being in Tech because I cannot do such problems. I may not know how to memorize such problems, but sit me down with some team members to collaborate and figure out what to do and build and I'd be on cloud nine enjoying myself talking to people and learning. I'd be happy to know that the work and time I put can be something bigger than me and my team. The lives that can be made better, the efficiency of daily tasks that can be done with whatever product I work on.
I just do not feel it is healthy on both ends to have over 7 rounds of interviews. Time is a very sensitive manner and this varies upon each individual, especially those with a family to take care of. I admit, I am biased on this part since I patiently stuck through interviews ranging from 2 to 4 months, completing all the rounds and even making it to the final round only to be told my lack of experience is what worries the company or they suddenly decided they had no need for the role to be opened because someone got the role internally. Such is life, you know?
I genuinely wonder, has there ever been a full, fleshed out conversation among people on what ways to do an interview process that isn't trying to imitate FAANG? Or perhaps, a cap of how many can apply to a place that doesn't end up being overwhelmed or resorting to said flawed procedures? These are thoughts that constantly run through my mind that I do not know and am so young to the experience.
I saw someone by the name of Jim S. write the following of interview process they have done:
"Assuming a candidate looks potentially “good enough” on paper, I pair-program FizzBuzz with them for an hour sometimes two. This simple exercise: leads to many, many conversations around principle and practices; shows me how well what they’ve written about themselves matches up with reality; let’s me know what it would be like working with them; in short, tells me everything I need to know and eliminates guess-work.
So, they’ve never paired before? Cool! Let’s see how well they learn and whether they’re amenable to change. They’ve never done TDD before? Great! See above re learning and change.
We have fun. Almost every time I’m told stuff along the lines of, “that was fun,” and, “I learned a lot.”
I’ve been happy with every hire that we’ve made based on this simple interview style."
This comment was then followed up by someone who asked what does one do for 1-2 hours using just FizzBuzz. Is it just simply rewriting it in different ways? I was curious too and this is what Jim continued saying:
"Not exactly - sort of. It depends on the candidate.
If they’re good at TDD and pairing we start ripping thru FizzBuzz and launch into conversations about TDD, Four Rules of Simple Design, SOLID, “if as a guard clause, never else,” Law of Demeter, pair programming, mob programming, microservices, event driven designs, our favorite authors and what they wrote that changed our perceptions, etc. It could easily go beyond two hours on all those topics, as I’m sure you know.
If they’re not versed in TDD and pair programming I see how quickly and well they learn, and whether they enjoy learning new things.
After implementing the second business rule simply within the single method we’ll often start talking about SRP and how we might solve the SRP violation that is beginning to emerge. Sometimes that comes later.
The refactoring that we do along the way in FizzBuzz, and the conversations that we have as a result, are what tells me a lot about how the candidate think about software."
The conversation came from this LinkedIn Post that honestly sparked me to write this blurb/early morning thoughts. It actually had me thinking "Man, I'd love to interview on FizzBuzz right now!" and then it had me thinking,
Imagine if companies adopted such a creative way to interview that had people wanting to sign up for such, knowing it'll be a healthy and productive one that can leave the candidate learning something or knowing something from said interview, even if not selected.
I guess it's wishful thinking and again, this is just my early morning rambling.
But I truly wish that in this year of 2022 where we promise changed habits or new things, this year can be a year where early career software engineers like myself can see change in the industry and us given a chance to be a member of said change.
But then again, I know my voice probably means so little right now and I've come to terms with that after all that has happened. I can only dream of a better tomorrow.
Top comments (0)