There are a lot of "software engineers" who can't code well. I see a lot of "google and copy paste until it works and deploy". No thoughts behind design. No idea about performance. No testing. No innovation. They all need to go.
Is that the fault of the devs or the broken processes where management promises unrealistic deadlines up the chain, so devs have no time to think about the bigger picture and just do everything in their power to ship something that barely works at the end of each sprint and move on to putting out the next fire?
To me, the fault is in the industry and how the ships are run.
I agree the problem you are describing also exists.
But I think the GP here is describing when people really can’t program. Like they can only write trivial programs by copy/pasting code from stackoverflow, and they don’t understand CS at all.
That is a different issue then knowledgeable devs cutting corners to meet deadlines.
If that's happening, it's either a calculated decision or the senior devs aren't doing their job. Someone should be communicating to management that the solution won't scale, with estimates of when it will fail or maximum load and the amount of time it will take to do it correctly.
Sometimes it's legitimately not worth optimizing something that will never need those optimizations. Sometimes management doesn't realize something needs to be optimized before it falls over. Sometimes management does make a bad call and doesn't want to optimize something that should be, but that's been uncommon (at least for me).
They will not believe you until actual issues happen. People in general are very good at dismissing problems that are right now biting someone else. You can see it all the time, even here in hacker news. And if anything, management is especially good at being confident that things will work out.
My senior experience is that if I see trouble that requires management intervention ahead, I communicate about it and then bail out. Trying to save it will just burn me out and as long as I am trying to fix issues, management thinks everything is ok and I am just stupid worrier. The issues must get real bad for them to be noticed and fairly often, it is best to let them go there fast.
Right. My point is that senior devs should be communicating the consequences of continuing down a rushed path. If management doesn't listen, they're making a calculated business decision (right or wrong).
If management is going down a rushed path and unaware of the tech debt piling up, that's a failure of senior developers to raise those issues.
Senior devs are good at communicating but management and execs aren't good at listening, they're good at counting beans. They don't care about tech debt because that's the issue of devs to work with.
Pretty much this, there have been times in my career when I was prepared to do everything the right way, but deadlines and unrealistic expectations from people who don't even know what JavaScript is forced my hand, so the product was less pretty internally but still functioning.
For most people software engineering is about driving results, not making everything beautiful under the hood. Although it's nice to do that when you have time.
I'm sort of experiencing a weird paradoxical feeling about this. I was spied on by Google and given the FooBar test, which I passed... and until which time I would have never thought of myself as that type of programmer. I can comprehend design patterns, or even have an intuition, but I don't generally think of them upfront (maybe I do more in recent years, maybe it is a skill which can be developed). What I have always been is curious, and just trying stuff out until it works, which I feel like I've seen spoken of a lot. I'm a hackathon winner. I've collected half of the network engineering encyclopedia, which is not really considered when we think about 'programming' exclusively, yet is ironically compared to 'leetcode' here. I've worked on industrial applications. I've gone back to first principles and maths in this AI summer and I'm having fun. I had a previous professional life in music and I've been excited about algorithmic composition (et al) for decades. I have a love for math. That said, I've never felt like the big brain stats types or many of my colleagues in programming. And for that matter, many of that type (anecdotal) have never done the creative things I have in music, etc. So all in all, maybe there are different types of talents!
While I've met plenty of terrible developers from the best universities and with the best grades and interviewing skills, people that was easily outclassed and outperformed by 3-month bootcampers, I can't lie crappiest one are much worse, people who struggle to implement very basic algorithms such as Fizz-Buzz.
Indeed, Leetcode is just slightly harder (or easier even) fizzbuzz anyway.
If you are given really hard questions in an interview or they ask for dumb invert binary tree like questions. It is most likely that person who interviews you is lazy or does not want to hire you but have no choice but to interview you.
I beleive pair programming interviews are the best. As they can be 1) Time limited so you don't take home and waste your time. 2) Can be a portion of a real world problem.
