Comment by noduerme
2 hours ago
I really wanna ask, because... I'm 46. Been writing code for a living about 30 years, never on a salary, always contractor. I wrote and maintain enough code for non-tech companies that aren't going to take a risk on AI rewrites anytime soon that I can probably coast until retirement. But I haven't interviewed or even needed to sell myself for a long time.
I always thought I would easily pass an interview, but I may have been wrong before all this on the basis that I don't work that well on a team.
OTOH ...is the question now really valuable whether a candidate can explain their thought process rather than deliver? Why wasn't that a question 20 years ago when it actually mattered? Or does it matter more now because the bar needs to be higher, and there's no cache of more experienced devs to train them up?
There are too many candidates for too few job openings. So people come up with all matters of ridiculous filters because they feel they have to test everyone. In reality they can take almost anyone with relevant experience and they'll get the job done, but that wouldn't look like good hiring process.
I think delivering is still a requirement either way, but the value is in hearing a candidate has the ability to problem solve in an unknown problem space vs regurgitate a memorized solution. Even better is witnessing some has the ability to try, fail, then self-correct, and rebound.
So, my policy has always been that if I sit through a meeting where a client asks for new feature "X" and I figure out a way to avoid building the new feature, and either use existing business logic / day-to-day processes, or else find some new way that doesn't involve code, I don't bill for that time. I'd say that I probably give up about 35-40% of potential coding work just by helping them work through that. Which is fine, because it leaves me free time to do other things.
On the other hand, I don't have the option to fail even slightly. I deployed a patch yesterday for an old, rare, logic bug in one reservation system, and within an hour I was being bombarded with edge cases of people seeing their reservations as cancelled during the 15 minute switch-over period.
Sometimes I feel like the job of a programmer for a company is just very different from what I do. If anything goes wrong with anything I deploy, I'm awake for however long it takes to make sure it's right. On the other hand: No PRs, no teamwork. Just a click to deploy once I'm relatively sure. And a lot of responsibility.