Reskilled Again
It’s interesting looking at software development job postings that still list requirements like X+ years of Java or Y+ years of TypeScript. There are certainly some niche languages where I think that’s still worth considering, and I get a bit squeamish when it comes to vibe-coded C/C++, but for most languages, years of specific experience is just not a relevant gate.
The last few rounds of interviews that I participated in really highlighted the shift in how I was beginning to feel about the industry and where others were still focused. I’ve never really put much stock in deep technical interviews. I expected candidates to walk me through how they think about applying techniques, and most importantly, to be clear when they would need to phone a friend to dive deeper. Other interviewers were still drilling deep on specific technical competencies. To me, that seemed like painting a house while the garage was on fire.
One of my stock questions from the 2010s was, “Tell me how you learn about capability XYZ: where do you go, how do you start, how do you assess your current or future level of expertise?” Some of that was a like-me bias that wanted other self-taught/self-learners, and some was trying to find a candidate who could deal with the ever-changing tech landscape.
The new version of this for me is, “Tell me about how AI tooling has changed the way you approach development, and walk me through your thinking and your expectations.” There’s still a like-me bias, as I’m trying to work my way through the same questions, but it’s clear that asking someone to walk through the when/why for each of React’s use* functions is a waste of both of our time.
Foundational concepts like the difference between streaming and batch data, and when you might want to use each, could be useful experience. But even that bit of knowledge is a short dialog away with a decent model. It’s good to have your own expertise as a check, but you can also vet answers with other models to see if they agree. Experience matters in the code-smell sense, but specific time-in-seat capabilities matter less.
The industry is shifting too fast at the head and likely too slowly at the tail. If I have a role to play in it going forward, it won’t be because I can walk through the difference between a Materialized View and a Temp Table and when I might want to use each one. The skill I need to keep working on, and that might pull me through, isn’t total mastery of intelligence tools; it’s more basic: I love to solve problems, any kind of problem, and to do that I need to be able to look, listen, learn, and then apply. That’s it, just see a problem -> solve a problem, where the arrow is the circle of adaptation through learning.
I don’t bet, mostly because I can’t guarantee a win, but if I did, I would put it all on the most important skill being the ability to learn new things. That’s not revelatory by any means, but core to learning is doing, and for me, I need a problem driving me to do. In the past, I haven’t always pursued personal projects because I assumed no one would need or want to use them. That was my loss. Over the past few weeks, I’ve just been building. No one needs to see the analysis of the air quality data I’m capturing locally, but I do need to practice how to adapt the tools I have to the problems I want to solve.
Image source and license: "Major Scale Modes for Perfect Fourths Tuning," by Nathan Bushman, via Wikimedia Commons at File:Major Scale Modes for Perfect Fourths Tuning.png. Licensed under Creative Commons Attribution-Share Alike 3.0 Unported (CC BY-SA 3.0).
These aren’t enterprise-scale problems, and I’m not futzing with OLAP Cubes to report on billions of data points in real time. These are small, repetitive, and sometimes a little silly, but they are practice with the instruments. Like scales on the guitar, they’re not a song unto themselves, but they build the adroitness needed to sing.