Curiosity saved the cat
Today, I'll be talking about curiosity...obviously, Data structures and algorithms, a little about interviews and work life, and the elephant in the room Chat-GPT! yes!
Last month was really busy and, I didn’t get the opportunity to put out a post like I promised but if it’s worth an apology, I will put out two posts between now and next week. Going forward, writing might be a little irregular, sometimes once a month, other times multiple times, until I get the hang of this..hopefully soon - DRC.
I’m hoping the title is a great hooker because this is a long, “worth it” read… sorry 🌚
I had the opportunity some time ago to be part of the recruitment process for a software engineering role. I had the task of determining a suitable assessment, and I’d handle the live code walkthrough sessions for the engineers who passed the assessment. Naturally, I dislike DSA(Data structures and algorithms) as a metric for judging sound engineers. it is what the industry adopts but I disagree because I know many folks who academically binge DSA courses and Leetcode solutions; these sorts of guys may possess very poor coding skills but they can blaze your recruitment process because you don’t want to think outside that industry box.
Before I continue, I would like to say, I don’t hate DSA, I just dislike how it is used (it is mostly never used after recruitment), and I would talk about how it should be used but let’s go back to the story.
I designed a Take-home assessment, simple enough for anyone to work on, and technical enough to filter out CRUD merchants (the role required considerable skill). I allowed for it to be written in any language and framework of choice because I wasn’t also looking for One-hit wonders. A number of Engineers made the deadline for submissions and I reviewed the codebase of two of them. The first (written in Springboot Java) seemed promising, it ran (I ran the code, even though I would have preferred running his tests though) or he could have provided a postman collection, but he did neither. The one thing that seemed like a red flag to me was finding redundant “NetBeans” packages/dependencies, code everywhere in his code and they didn’t seem necessary for such a simple task. It told me 2 things off the bat:
This guy lifted some of this code from an old legacy codebase and forgot to remove some things.
His code also relied heavily on XML, which Springboot has slowly reduced over the years. it means he wasn’t growing with the technology.
I knew I was going to confront these things at the walkthrough session. The second engineer didn’t do badly too, he had equal abilities as the first, but he used newer code conventions (by Spring boot standards) and he made obvious mistakes in his code that the first engineer didn’t. I was going to confront this too.
During the walkthrough sessions, I rightly confirmed my suspicions about the first engineer. For every question I asked that challenged his code with current styles and conventions, his response was always one element from this choice array, “That’s what I know”, “That’s how I know how to do it”, and “I didn’t know about that”. Also, he had no answer about why NetBeans was all over his codebase in 2022.
The second engineer, also had an array of responses to confrontations, “I’m sorry about that”, “I see the mistake, I will work on it”, “I didn’t know you could write it like that, I will learn about it”, and “I’ve never heard of this, but I will look it up”.
Long story short, I went for Engineer Two. He displayed just one ability I liked: The ability to learn. It was obvious that Engineer One had an edge over Engineer Two in skills but the second guy could grow in the role, and the first was incapable of doing the same because he lacked the necessary curiosity.
How this applies to work life
Sometimes, I sit across from my boss who by the way is amazing 🌚 (he will read this…Amen!), and he says, “Chibs, you did rubbish, you pushed beans”, (he says this a lot sha 😂), then he says “I corrected it anyways”. I immediately pull his code because I want to compare. In comparing, maybe I come across a technique or concept he used that I didn’t previously know about, I sometimes go back to ask him, “Hey boss, what is this you did here?”, then maybe he says something like, “oh, it’s reactive Java”. Be assured I’d already be looking for articles or a video on that subject. Most of the time, this is how I learn. Other times, I wait to see a new PR from someone in the team and I go ahead to read it, just checking for new and better ways to do something. That knowledge is forever because it is hooked on curiosity. In this circumstance, you’re actually excited to learn. Sure, it gets a bit embarrassing sometimes, I remember once when I wrote a page full of CRUD (create-read-update-delete) and someone senior refactored the whole thing into one-liners. It felt bad, but I picked it up quickly too. This is why I read code, I want to check for better systems, cleaner architecture, and code to what I presently have in my skill set.
In my opinion, this is the sort of relationship to have with senior colleagues or bosses. You might not pick up code, it might just be a shorter and faster way to deliver a project, a better SAAS or open source tool to utilize; sometimes I ask things like “Why Redis, why not memcache?” or “Why are we writing code first, then tests later?”. The point is to pick up their experience in the shortest time possible. It’s far more efficient than Udemy courses and Youtube tutorials.
I actually think that this is the entire point of Open source. The open transfer of knowledge…good software engineering knowledge. There are open-source internships and programs all over the place but of course, there are folks who only need the GitHub badges and the Linkedin certificates.
DSA :(
🥲
To be fair, I do not have a thing against DSA, but I do think they’re being misused. Most people ever only need to know it to pass Job interviews at Google, Bloomberg, and other tech giants. They barely need to implement any from scratch in their day-to-day work as most languages already do this for you. Most others use data structures and algorithms without knowing what it is anyway.
The one thing we can readily agree on is that solving DSA problems (without the pressure of passing an interview) helps you develop a critical-thinking problem-solving kind of mindset. I feel that the correct way to use DSA is as a ‘catalyst’, a ‘warmup exercise’. I remember a few years ago, I was writing for a firm and I put out content that disagreed with using DSAs to determine who is a good software engineer and who is not minutes later, I was asked to pull it down because it was a direct confrontation against the recruitment process of tech giants.
Of course, I know that they do this because they want to get the top 99.99% and they’re willing to lose some good engineers while at it, but I think it is a really bad metric for judgment, and the 2023 AI tools uproar is increasingly proving this fact daily but I probably want to stop here (it’s a long read already). There will be part 2 of this next week, but before we wrap this up, I’d just add that:
Everything we’ve talked about in this post applies to every field, design, QA, DevOps, Security, you name it!
Nice read, waiting for part 2!
Awesome... It's always a pleasure reading your posts.