Course Correcting My Interview Prep
How overusing AI contributed to me botching a technical interview.
The Linux Technical Interview
I woke up this morning to a “Thank you for your interest” email. It was my latest job rejection for a role that I interviewed for this Wednesday. Frankly, the position was a bit outside the usual role that I apply for. It was more of a DevOps role when I have normally been applying for software engineering positions. But I have an interest in finance, so I decided to apply and let the world decide if it was a good fit.
The technical interview decided that it wasn’t.
The senior DevOps engineer interviewer tested my familiarity with Linux/Unix and the command line interface (CLI). My reliance on graphical user interfaces (GUIs) became obvious as I worked through the challenges. I was asked to complete a few basic tasks on an Ubuntu command line. I fumbled using grep to filter a list of processes that I needed to terminate. I skimmed through the man pages, but it was hard to do on the fly. I told the interviewer that I could do it with Python’s regex, but I was unable to use Vim or the Python repl console. On the flip side, I did a lot better on the live HackerRank programming challenge on string parsing and manipulation.
Here’s how I think about rejection. It’s a signal in a feedback system. Every goal is a system with inputs (your actions), outputs (results), and feedback (what the world tells you). When an output doesn’t match your goal, the feedback tells you which input to adjust. One rejection isn’t failure, but it’s the system showing you exactly where the mismatch is.
My job interview was a clear signal: employers value practical Linux and CLI skills. They will test for them, and I’m unprepared. It was a needed course correction for my technical interview preparation.
Thinking Broadly: My AI Induced Motivation Mismatch
But why was I unprepared? In the past year, I gradually experimented with AI-assisted coding and software engineering. Instead of reading through arguments and discussions on Stack Overflow and referring directly to documentation, I used ChatGPT and Claude AI as my guide. I used it to help with my systematic debugging and troubleshooting of unexpected low-level networking TCP/IP errors. But there was an unintended consequence: overly using it robbed me of the joys of programming. The dopamine spikes of getting an LLM to solve a problem replaced the satisfaction of slow breakthroughs and solving problems. I was solving problems superficially.
This was a different feedback loop I’d been ignoring. My daily coding habits (input) were producing shallow understanding (output), but I hadn’t recognized the signal because I wasn’t failing tasks. I was just learning less. The job interview made this hidden mismatch visible. The job market wants engineers that can demonstrate and communicate their competency in the fundamentals.
I recognized that the gap in my Linux fundamentals was due to a loss of intrinsic motivation. To fix this, I needed to replace my AI usage with the slower process of learning by doing. This led me to cancelling my $40/month worth of ChatGPT and Claude AI subscriptions as well as finding project-based learning platforms online, like LabEx.
For now, I am continuing the Linux course, pausing my AI usage, and setting up an Ubuntu virtual machine for more practice. Will it get me my next job? Maybe. Maybe not. But that’s how feedback loops work in all areas of life. You adjust, test, and let the next outcome tell you if you’re closer. At least, I will know how to terminate specific processes from the command line.
Cheers,
Gilberto Guadiana
This essay is part of Leverage Notes. It’s a series on reflections and observations from my week mixed with systems thinking. About me: I’m an interdisciplinary software engineer using systems thinking to understand Bitcoin’s design, navigate a technical career, and prepare for a 10-year mission to build Iron Temple Ranch, where young men can rebuild through mentorship and work.