4 ms·

My point is that LeetCode and buzzwords became the unofficial benchmark for a software engineer during the distorted/ZIRP era. You had to be good at it to get i

My point is that LeetCode and buzzwords became the unofficial benchmark for a software engineer during the distorted/ZIRP era. You had to be good at it to get in, and once in you could just coast your way through, not that anyone would mind because so many of your peers and superiors are doing the same thing and none of it matters as the company itself may be coasting on investor money and never intending on making a profit. Unfortunately, LeetCode skills and "architecture astronomy" (https://en.wikipedia.org/wiki/Architecture_astronaut https://en.wikipedia.org/wiki/Architecture_astronaut) are a very poor proxy for actually driving profit. This doesn't mean a LeetCoder (for fun or to play the game - as long as they understand it is a game) can't also be a good contributor in today's market, but their value would come more from experience solving actual business problems and ability to collect/define/argue requirements and then translate them into a system (which may or may not even be code - sometimes a Google Form is all that's needed) rather than whether they know LeetCode. When it comes to solving business problems and actually driving profit, programming in abstract terms (the kind that LeetCode and most interview processes select for) is worthless - LLMs can do it just fine. The hard part is understanding/fleshing out the business requirements (including being aware of what you don't know, and planning for that or seeking outside help), refining your solution with the relevant stakeholders, and being aware of high-level constraints including regulatory requirements, security, etc. Once you have a good enough specification, programming it is the generally the easy part.

bradlys 2y ago
Are you advocating for everyone to create their own SaaS here or what? End of the day, most engineers need to join employers. We can’t have 10M+ different SaaS out there and each engineer develops their own personal brand of it. That’s not how software scales. Most ICs are never going to be in a position where the CEO is going to listen to them about what product we should develop and be given the time and resources to investigate that stuff. Your assertion doesn’t even acknowledge infra engineers who clearly don’t work on product facing work. It’s a bit ridiculous.
- Nextgrid 2y ago
  I see the era of permanent tech employment as coming to an end, and tech will have to transition to being closer to a trade. You don't expect to pay builders/plumbers/architects/electricians and keep them around forever after your house is built right? You will at best only need them occasionally on a one-off basis for any fixes or alternations. A properly designed tech solution (aka, not one designed to pad a resume) for upkeep should only require a small fraction of the manpower needed to originally build it. I expect companies keeping in-house "skeleton crews" to run things and handle maintenance and small changes, with larger ones being done by a (potentially returning) cast of contractors who come in on a project basis. So the solution for permanent employment would be to either join one of those skeleton crews or join an agency/consultancy. Otherwise, the only way out is freelance and curating your own client portfolio. Maybe you can partner with others and form a coop to have more manpower and handle bigger projects - essentially building your own agency. > Your assertion doesn’t even acknowledge infra engineers My assertion is that engineers who want to succeed in the current market will need to know enough infra/sysadmin to support their solution, or farm it out to someone who will. If they don't, someone else will outcompete them. Infra is also a huge breeding ground for resume padding and architecture astronomy (and there were no incentives to discourage it - in fact cloud providers are still laughing all the way to the bank). It doesn't inherently mean all that complexity was necessary. So I expect "infra" specialization to become a nicher skill, one or permanent skeleton/maintenance crews or hyperscalers who actually need the complexity. > who clearly don’t work on product facing work I'm intentionally being vague when I talk about "solutions" and solving business problems. I do not mean it should be an app, a product or even have a UI. A cron job running a shell script to copy files from one place to another may very well be the right solution to some business requirements. Infra engineers would be a perfect fit for problems that don't involve significant UI work (I myself prefer those as I hate frontend with a passion). I think the era of high specialization in tech might be in decline; tools are good enough and hardware is good enough and the field is mature enough that most business problems can be solved just fine by a generalist (bringing in specialists on an ad-hoc basis when needed) - or otherwise they'll get outcompeted by someone who can.
  - bradlys 2y ago
SR2Z 2y ago
> LLMs can do it just fine. No, they can't. They can (sometimes) bang out a frontend app or some CRUD service, but if that's all the code you write you should not be a senior engineer. The process of writing a specification and the process of implementing it tend to have a ton of overlap in the real world. There's no way to actually define one in a vacuum, despite almost every PM I've ever met pretending otherwise.
- Nextgrid 2y ago
  > No, they can't I was talking purely about those abstract interview questions where the full problem can be summarized in a few lines and the expected solution is ~50 lines max. I've just tried with Claude 3.7 and it's produced a seemingly plausible solution at the "word finder" problem (2D grid of letters - given a word, return if it's present in the grid as a series of adjacent cells in any direction). I agree that they're far from taking our jobs, which is my point - those interview questions are absolutely not representative of what we really do and optimize for the wrong outcome.
  - SR2Z 2y ago
    Fair enough, but my bet is that even trivially recontextualizing an interview question is enough to wreck an LLM's performance. If you change the "find a word in a grid of letters" question to a "find a Collatz sequence in a grid of numbers" question, does it still work? As an interviewer, I would expect a qualified candidate to spend maybe an extra 5-10 minutes asking clarifying questions and understanding the difference between the two.

bradlys 2y ago

Are you advocating for everyone to create their own SaaS here or what? End of the day, most engineers need to join employers. We can’t have 10M+ different SaaS out there and each engineer develops their own personal brand of it. That’s not how software scales. Most ICs are never going to be in a position where the CEO is going to listen to them about what product we should develop and be given the time and resources to investigate that stuff. Your assertion doesn’t even acknowledge infra engineers who clearly don’t work on product facing work. It’s a bit ridiculous.

Nextgrid 2y ago
I see the era of permanent tech employment as coming to an end, and tech will have to transition to being closer to a trade. You don't expect to pay builders/plumbers/architects/electricians and keep them around forever after your house is built right? You will at best only need them occasionally on a one-off basis for any fixes or alternations. A properly designed tech solution (aka, not one designed to pad a resume) for upkeep should only require a small fraction of the manpower needed to originally build it. I expect companies keeping in-house "skeleton crews" to run things and handle maintenance and small changes, with larger ones being done by a (potentially returning) cast of contractors who come in on a project basis. So the solution for permanent employment would be to either join one of those skeleton crews or join an agency/consultancy. Otherwise, the only way out is freelance and curating your own client portfolio. Maybe you can partner with others and form a coop to have more manpower and handle bigger projects - essentially building your own agency. > Your assertion doesn’t even acknowledge infra engineers My assertion is that engineers who want to succeed in the current market will need to know enough infra/sysadmin to support their solution, or farm it out to someone who will. If they don't, someone else will outcompete them. Infra is also a huge breeding ground for resume padding and architecture astronomy (and there were no incentives to discourage it - in fact cloud providers are still laughing all the way to the bank). It doesn't inherently mean all that complexity was necessary. So I expect "infra" specialization to become a nicher skill, one or permanent skeleton/maintenance crews or hyperscalers who actually need the complexity. > who clearly don’t work on product facing work I'm intentionally being vague when I talk about "solutions" and solving business problems. I do not mean it should be an app, a product or even have a UI. A cron job running a shell script to copy files from one place to another may very well be the right solution to some business requirements. Infra engineers would be a perfect fit for problems that don't involve significant UI work (I myself prefer those as I hate frontend with a passion). I think the era of high specialization in tech might be in decline; tools are good enough and hardware is good enough and the field is mature enough that most business problems can be solved just fine by a generalist (bringing in specialists on an ad-hoc basis when needed) - or otherwise they'll get outcompeted by someone who can.
- bradlys 2y ago

SR2Z 2y ago

> LLMs can do it just fine. No, they can't. They can (sometimes) bang out a frontend app or some CRUD service, but if that's all the code you write you should not be a senior engineer. The process of writing a specification and the process of implementing it tend to have a ton of overlap in the real world. There's no way to actually define one in a vacuum, despite almost every PM I've ever met pretending otherwise.

Nextgrid 2y ago
> No, they can't I was talking purely about those abstract interview questions where the full problem can be summarized in a few lines and the expected solution is ~50 lines max. I've just tried with Claude 3.7 and it's produced a seemingly plausible solution at the "word finder" problem (2D grid of letters - given a word, return if it's present in the grid as a series of adjacent cells in any direction). I agree that they're far from taking our jobs, which is my point - those interview questions are absolutely not representative of what we really do and optimize for the wrong outcome.
- SR2Z 2y ago
  Fair enough, but my bet is that even trivially recontextualizing an interview question is enough to wreck an LLM's performance. If you change the "find a word in a grid of letters" question to a "find a Collatz sequence in a grid of numbers" question, does it still work? As an interviewer, I would expect a qualified candidate to spend maybe an extra 5-10 minutes asking clarifying questions and understanding the difference between the two.