This is effectively the same sentiment I echo when talking about AI to folk in the tech industry who are scared of, rather than resistant to, change.
I haven’t professionally built anything on bare metal in years. It sits somewhere in the aether these days, and I no longer have to worry about it in the same way.
I can’t speak for other languages, but Spring Boot made enterprise level Java development accessible to the masses, and the jobs are still there. They have just shifted.
If you haven’t done the groundwork and seen what these frameworks are replacing, you won’t truly grasp what the tools are doing. That is why vibe coding leads to unintended side effects, and I feel for students who are dropped straight into frameworks that obscure what is going on under the bonnet. It is not magic, it just looks like it.
If an organisation treats AI as a silver bullet, the best they will get is an off-the-shelf assistant. The real gains will come from domain-specific models that understand the business well enough to generate tailored, useful output. But that does not remove the engineer, it just shifts their role towards quality, safety, and accountability.
Compliance alone – GDPR, PCI, and the rest – will slow down any industry-wide adoption of truly bespoke AI models. Retreading the same ground just to offer suggestions that feel human? That could cost tens, if not hundreds, of millions per organisation.
'Barely any developers who can't develop for shit.' That's a frustrating sentence to unpack.
Is the claim that the majority of developers are proficient because of Leetcode as a filter?
I don't think Leetcode is a useful interview tool when the actual role deviates from the style of questions that are expected to be completed in an interview scenario. And this is a prevalent issue.
Clearly it can be gamified and I don't think this makes for good engineers. It makes for people that are good at solving Leetcodes. Jira tickets aren't Leetcodes.
Whatever technical filter is implemented (pairing/take home/in house white boarding etc.) I care much more about observability, logging, approach to difficult problems etc. and general attitude.
Run me through the architecture for previous solutions that have been worked on. Did you own it? Were there any outages? What happened when requirements change? How can you ensure what you've created is fit for purpose for the organisation?
There's so much more to engineering rather than just code. And in my experience many engineers are worse at this than they think.
I've been involved in a similar project before that fell through, the issue being if you say something's halal when it's not (what if the certification has expired, falsified or whatever else) then the burden falls on the person who claims that it's halal - even if well intentioned. The issue of checking status is non-trivial.
More of a quirk of panoramic pictures than anything else, I'd have thought you would've pointed to the use of colours, saturation, or lighting in standard iOS photos - it's why I swapped to Halide.
Appalling. You were lucky the candidate was available for months of interaction. You deliberated too much and you lost out on what sounded like an excellent fit. No one is going to be perfect. No one is going to be at their best during interviews. Yet not understanding that when someone shows strength and promise that you bring them in to the role where there's a probationary period to do further evaluation shows a complete lack of competence in hiring.
Every job that I've had I've found despite LinkedIn. My first graduate job was through word of mouth, the second I was headhunted, the third I found a recruiter that was worth his salt (who also, eventually, placed me at my fourth). Anything I've needed to know about a company there were ways outside of LinkedIn to find out, often as LinkedIn seemed like a HR washed exercise in grandiose. FWIW they're all but one are companies you would've heard of.
Echoing the sentiments above it's a bitter pill to swallow recognising that there are hoops to jump through in order to play the game. We all have had to learn this one way or another.
Don't let this stop your pet projects and try to realise you have multiple paths you're fulfilling at the same time. Bills need paying. You're beginning (and will be advancing) in your job and future prospects. Your love of software needs nurturing so you don't become jaded by a 9-5.
Play the game. Get where you need to be. Don't close doors.
Would you prefer challenges about technical debt, scope creep and legislation changes forcing large rewrites? Coding for a living can be rewarding but in many large organisations is often tedious.
I haven’t professionally built anything on bare metal in years. It sits somewhere in the aether these days, and I no longer have to worry about it in the same way.
I can’t speak for other languages, but Spring Boot made enterprise level Java development accessible to the masses, and the jobs are still there. They have just shifted.
If you haven’t done the groundwork and seen what these frameworks are replacing, you won’t truly grasp what the tools are doing. That is why vibe coding leads to unintended side effects, and I feel for students who are dropped straight into frameworks that obscure what is going on under the bonnet. It is not magic, it just looks like it.
If an organisation treats AI as a silver bullet, the best they will get is an off-the-shelf assistant. The real gains will come from domain-specific models that understand the business well enough to generate tailored, useful output. But that does not remove the engineer, it just shifts their role towards quality, safety, and accountability.
Compliance alone – GDPR, PCI, and the rest – will slow down any industry-wide adoption of truly bespoke AI models. Retreading the same ground just to offer suggestions that feel human? That could cost tens, if not hundreds, of millions per organisation.