Comment by mjr00

Not sure what type of "greenfield" startup experience you've had, but most of the work I'm talking about involves solving problems that most people simply don't have the combined skill set to solve. Typically problems that involve a substantial amount of quantitative skills combined with the ability to bring those solutions to prod.

Nearly all of the teams I've joined had problems they didn't know how to solve and often had no previously established solution. My last gig involved exploring some niche research problems in LLM space and leveraging the results to get our first round of funding closed, this involved learning new code bases, understanding the research papers, and communicating the findings publicly in an engaging way (all to typical startup style deadlines).

I agree with your remarks around "greenfield" if it just involves setting up a CRUD webapp, but there is a wide space of genuinely tricky problems to solve out there. I recall a maintainer style coworker of mine, who describe himself similar to what you are describing, telling me he was terrified of the type of work I had to do because when you started you didn't even know if there was a solution.

I have equal respect for people such as myself and for people that you describe, but I wouldn't say it is more challenging, just a different kind of challenge. And I do find the claim "you don't learn the actually valuable lessons" to be wildly against my experience. I would say most of my deep mathematical knowledge comes from having to really learn it to solve these problems, and more often than not I've had to pick up on an adjacent, but entirely different field to get things done.

Yup. You learn the most valuable information from watching how things break and then fixing them.

It's kind of like when the FAA does crash investigation -- a stunning amount of engineering and process insights have been generated by such work to the benefit of all of us.

It is more challenging, but I feel like it also has fewer people looking for that. That whole "move fast and break things" phrase messed with too many people's heads. I don't think people appreciate this segment of a product's life cycle as much as they should. They're always looking for the quick solutions.

Everyone can do 0 to 1. Because delivery drives dopamine. The it is the boring thing, but there comes experience to find interest in that part

> Greenfield and then leaving is too easy, you don’t learn the actually valuable lessons.

You learn a ton of valuable lessons going from 0 to v1. And a ton of value is created. I guess I'm unclear how you're defining "actually valuable" here.

Taking this to the extreme, I think most lessons represent sunset or dead projects. There's no sweet illusions anymore. No assumptions. No ego. No account for infinite flexibility. No shine. No excitement of a new thing. No holy wars. No astronaut architects. Only you, the ruins and the truth.

Soooo agree. I've had to clean up the messes of people that did the 0-1 in my field and going from 1-unconditionally stable was a lot more work than the 0-1 part.

This is unironically my favorite kind of HN comment: to say something incredibly rude and/or condescending but wrap it in the right kind of thoughtful language to qualify as HN nice

The original punchline ("you don’t learn the actually valuable lessons.") was just a bit too sharp, so you even edited in a psuedo-clarification which actually just repeats that punchline but in a softer way, masterful!

> Companies have also adopted your strategy: interviewing candidates "to see what's out there" - there's a job I've interviewed for that's still open after 10 months

When I was doing a lot of hiring we wouldn't take the job posting down until we were done hiring people with that title.

It made a couple people furious because they assumed we were going to take the job posting down when we hired someone and then re-post a new listing for the next person.

One guy was even stalking LinkedIn to try to identify who was hired, without realizing that many engineers don't update their LinkedIn. Got some angry e-mails. There are some scary applicants out there.

Some times a specific job opening needs to stay open for a long time to hire the right person, though. I can recall some specific job listings we had open for years because none of the people we interviewed really had the specific experience we needed (though many falsely claimed it in their applications, right until we began asking questions)

What a time to be alive: Companies post roles that don't exist to interview candidates who don't plan to switch.

> How many offers did you receive? Companies have also adopted your strategy: interviewing candidates "to see what's out there" - there's a job I interviewed for that's still open after 10 months.

On the hiring side, at least in tech: interviewing really sucks. It's a big time investment from multiple people (HR, technical interviewers, managers, etc).

I'm not saying it's impossible that companies are interviewing for fun, but it seems really unlikely to me anyone would want to do interviews without seriously intending to hire someone.

Be careful to make judgement calls like this.

I've been running the same job ad for 2 years now, as a recruiter for a big Canadian bank. I've been laughed at for having ridiculously unrealistic standards. I've been accused of running ghost ads.

I'm in the process of hiring the 13th person using this same job ad for new and existing teams that need a very particular type of engineer.

I have to agree, getting tech interviews isn't a great gauge of the job market.

I recently did an interview and a complaint I hear from the interviewer and our own company, people (your competition) reading from AI output.

As a candidate I don't mind doing a few highly speculative interviews. After not interviewing for a while it is good practice.

I don't know, the majority of my colleagues have no idea how to do anything in a greenfield environment. They need guardrails.

My best projects have all been greenfield. The worst were a few years old but required tons of maintenance unrelated to the core product. Example: one place built their own ORM. Twice.

There is famous term for those: Tactical Tornados

https://news.ycombinator.com/item?id=33394287

To provide a different framing, I’m more of a builder and I’m happy to maintain too. What I’m not happy with, and have left jobs over, is being put into a box or becoming overly siloed.

Large companies tend to over specialize and that’s where I see the “I’m a builder” types fall apart. That takes away agency, lowers skills, and removes variety from work. That’s when it stops being fun to me.

I would hope most people with the builder architype are otherwise fine to keep building and maintaining.

Shippers gonna ship.

> The work is good until a company decides to operate with leaner teams and keeps the people committing code.

I'm no AI booster but I think this is exact scenario where AI-driven development is going to allow those non-coding developers to shine. They still remember how code works (and have probably still done PR review from time to time) so they're well placed to write planning documents for an AI agent and verify its output.

Yes when I saw this happen during the post COVID boom I was honestly shocked. Engineers I knew who were fairly senior thought that they could build the rest of their career in just boxes and arrows on a board. The whole thing just made me really dislike other Principal engineers.

I left to a startup where I write code and design architecture. I even had a former coworker tell me "wow you're willing to do stuff like that at this point in your career?"

If Jeff Dean still codes, so can I.

I got laid off at the end of last year and am currently interviewing for Staff+ DevOps/Platform Engineer type roles. I definitely feel this. I've had a decent flow of recruiter inquiries and had multiple companies go 2-3 rounds of interviews deep with me (not counting the initial "do you have a pulse" recruiter screen calls). Then the communication always seems to dry up and I'm left to wonder what box I failed to check on their hiring rubric.

Semi related, holy hell do companies have a lot of interview rounds these days. It seems pretty standard to spread 5-6 Teams calls over the course of a month. I get that these are high salary, high impact roles and you want to get it right. But this feels really excessive. And I'm not talking about FAANG tech giants here. It's everyone, from startups to random midsize insurance companies.

And a lot of it is networks as opposed to applying to a job position. My last position--that I had for many years--was reaching out to someone knew for not even a posted position and having one created for me.

Not the parent commenter but I've performed a lot of resume reviews for people and also done a lot of hiring.

Most resumes are not very good. Beyond the obvious problems like typos, there is a lot of bad advice on the internet that turns resumes into useless noise. Screen a lot of resumes and you'll get tired of seeing "Boosted revenue by 23% by decreasing deploy times by 64%." This communicates nothing useful and we all know that revenue going up 23% YoY was not attributable to this single programmer doing anything at all.

Often I'll get candidates into interviews and they light up telling me about impressive things they did at a past job with enough detail to convince me they know the subject, but their resumes are garbage because they've followed too many influencers.

So try to work on your resume first. Try different resumes. Rewrite it and see what makes interviewers take notice and what they ignore. The most common mistake is to write a resume once and then spam it to 100 jobs. I know it's not fun to change the resume or invest time into applying for a job that may not respond, but you know what else isn't fun? Applying to 100 jobs and not getting any responses because every hiring manager has 20 tailored resumes in their inbox ahead of yours.

Having a simple but clear LinkedIn profile helps. Many scoff at this, but it works. You don't have to read LinkedIn's social media feed or do anything with the site. Just set it up and leave it for them to find.

GitHub portfolios and other things have low relative value at most companies. There are some exceptions where someone will look at it and it might tip the balance in your favor, but it's a small optimization. You need to be perfect the resume first, get a LinkedIn that looks decent second, and only then think about the ancillary things.

And even then, getting interviews is one thing, but getting offers is something completely different.

And there's also the advantage of having a current job, instead of an increasingly larger jobless gap that not only decreases your chances over time, but also contributes to the cycle of "less chance -> wider gap -> increased anxiety -> less chance".

Fumble the first few months due to a combination of a lack of interviewing practice, and of job postings that never intended to hire anyway or that are looking for someone that checks literally all their shopping list of boxes, all while still dragging you for a 4-8 journey, and suddenly your position is not that good anymore.

What I think is disappearing is not so much the quality of academic education, but the baptism by firehose that entry level CS positions used to offer - where you had no choice but learn how things actually work while having a safe space to fail during a period in your career when productivity expectations of you were minimal to none.

That time when you got to internalise through first hand experience what good & bad look like is when you built the skill/intuition that now differentiates competent LLM wielding devs from the vibers. The problem is that expectations of juniors are inevitably rising, and they don't have the experience or confidence (or motivation) to push back on the 'why don't you just AI' management narrative, so are by default turning to rolling the dice to meet those expectations. This is how we end up with a generation of devs that truly don't understand the technology they're deploying and imho this is the boringdystopia / skynet future that we all need to defend against.

I know it's probably been said a million times, but this kinda feels like global warming, in that it's a problem that we fundamentally will never be able to fix if we just continue to chase short term profit & infinite growth.

> If you earned your CS degree (or any degree) before 2022 or so, the value of that degree is going to grow and grow and grow

In my experience, target schools are the only universities now that can make their assignments too hard for AI.

When my university tried that, the assignments were too hard for students. So they gave up.

That’s an insight that a project I’m working on has built upon: https://unratified.org/connection/ai/higher-order-effects/#1...

Education and training and entry level work build judgement.

That's not something enthusiasts here and elsewhere want to hear, that's pretty obvious also in this discussion. People seems extremely polarized these days.

AI is either the next wheel or abysmal doom for future generations. I see both and neither at the same time.

In corporate environment where navigating processes, politics and other non-dev tasks takes significantly longer than actual coding, AI is just a bit better google search. And trust me, all these non-dev parts are still growing and growing fast. Its useful, but not elevating people beyond their true levels in any significant way (I guess we can agree ie nr of lines produced per day ain't a good idea, rather some Dilbert-esque comic for Friday afternoon).

We're now reaching the point where people have gone their whole college education on AI, and I've noticed a huge rise in the number of engineers that struggle to write basic stuff by hand. I had someone tell me they forgot how to append to a list in their chosen language, and couldn't define a simple tree data structure with correct syntax. This has made me very cautious about maintaining my fluency in programming, and I'll usually turn off AI tools for a good chunk of the day just to make sure I don't get too rusty.

"Those who can't, do..."

> think the folks burning thousands of dollars of credits are unable to describe what they want.

Basically, yes. I bought 'business tier' and I know about webdev but I'm somewhere between intern and junior, so I do a lot of discussing. One session is "I want [functionality and constraints], ask me relevant major design questions" then implementation, then me investigating and asking for fixes.

  > I think the folks burning thousands of dollars of credits are unable to describe what they want.

my related question whenever i hear a story like that: are they just filthy rich or have any plan to make that money back?

I don't see the value of a junior instructing an AI, because I as a senior can also instruct an AI.

I perceive the AI itself as a very fast junior that I pair program with. So you basically need the seniority to be able to work with a "junior ai".

The bar for human juniors is now way higher than it used to be.

I used to do online interviews with full access to Google or any online resource (so long as you shared your screen and I could see). Use your own code editor, no penalty at all for searching up syntax or anything else.

I always asked a simple question like here is an array full of objects. Please filter out any objects where the "age" property is less than 20, or the "eye color" property is red or blue. It was meant more as a sanity check that this person can do basic programming than anything else.

Tons and tons of people failed to make basically any progress, much less solve the problem, despite saying that they worked programming day to day in that language. For a mid level role I would filter out a good 8 or 9 out of ten applicants with it.

I would consider it a non-leetcode type of question since it did not require any algorithm tricks or any optimization in time/space.

Nowadays that kind of question is trivial for AI so it doesn't seem like the best test. I'm not hiring right now,.but when I do I'm not sure what I will ask.

> mid/difficult

You're assuming the question has to even be that difficult. I've proctored sessions for senior-level webdev roles where the questions were akin to "baby's first React component" -- write a component that updates a counter when you click a button. So many candidates (who purported to be working with React for years) would fail, abysmally. Not like they were just making small mistakes; I didn't even care about best practices -- they just needed to make it work. So many failed. Lot of frauds out there.

Simple: don’t do that.

It’s been well over a decade that I’ve had to do the coding interview monkey dance and I actually turned down an offer where I did pass a coding interview because I found it insulting and took a job for slightly less money where the new to the company director was interested in a more strategic hire (2016). That was the same thing that happened before in 2014 and after in 2018 - a new manager/director/CTO looking for a strategic hire.

In fact even my job at BigTech -AWS ProServe (full time blue badge RSU earning employee) as a customer facing consultant specializing in app dev was all behavioral as well as my next full time job as a staff consultant in 2023.

I’m 51 years old and was 40 in 2014. If I’m still trying to compete based on my ability to reverse a b tree on the whiteboard even at 40, I have made some horrible life decisions.

(Well actually I did make a horrible life decision staying at my second job too long until 2008 and becoming an expert beginner. But that’s another story)

I've put a lot of thought into hiring in this era, and what I've personally found works the best is:

Let them use their preferred setup and AI to the full extent they want, and evaluate their output and their methodology. Ask questions of "why did you choose X over Y", especially if you're skeptical, and see their reasoning. Ask what they'd do next with more time.

It's clear when a candidate can build an entire working product, end-to-end, in <1 day vs. someone who struggles to create a bug-free MVP and would take a week for the product.

In addition to the technical interview, hiring them on a trial basis is the absolute best if possible.

Taste and technical understanding of goals and implementation to reach those goals is the biggest differentiator now. AI can handle all the code and syntax, but it's not great at architecture yet - it defaults to what's mid if not otherwise instructed.

"And then what happens in a year when the models can handle that as well?"

Either the machines exterminate us or we become glorified pets.

Hope the AIs prefer us to cats (even though that's a long shot).

It's like having an early/broken chess engine.

An amateur with a chess engine that blunders 10% of the time will hardly play much better than if they didn't use it. They might even play worse. Over the course of a game, those small probabilities stack up to make a blunder a certainty, and the amateur will not be able to distinguish it from a good move.

However, an experienced player with the same broken engine will easily beat even a grandmaster since they will be able to recognise the blunder and ignore it.

I often find myself asking LLMs "but if you do X won't it be broken because Y?". If you can't see the blunders and use LLMs as slot machines then you're going to spend more money in order to iterate slower.

> Junior devs can indeed prompt better than some of the old timers

I guess? I don't really see why that would be the case. Being a senior is also about understanding the requirements better and knowing how/what to test. I mean we're talking about prompting text into a textarea, something I think even an "old timer" can do pretty well.

I'm hosting a Kubernetes cluster on Azure and trying to autoscale it to tens of thousands of vCPUs. The goal is to transparently replace dedicated developer workstations (edit: transparently replace compiling) because our codebase is really big and we've hired enough people this is viable.

edit: to clarify, I'm using recc which wraps the compiler commands like distcc or ccache. It doesn't require developers to give up their workspace.

Right now I'm using buildbarn. Originally, I used sccache but there's a hard cap on parallel jobs.

In terms of how LLMs help, they got me through all the gruntwork of writing jsonnet and dockerfiles. I have barely touched that syntax before so having AI churn it out was helpful to driving towards the proof of concept. Otherwise I'd be looking up "how do I copy a file into my Docker container".

AI also meant I didn't have to spend a lot of time evaluating competing solutions. I got sccache working in a day and when it didn't scale I threw away all that work and started over.

In terms of where the LLM fell short, it constantly lies to me. For example, it mounted the host filesystem into the docker image so it could get access to the toolchains instead of making the docker images self-contained like it said it would.

It also kept trying to not to the work, e.g. It randomly decides in the thinking tokens "let's fall back to a local caching solution since the distributed option didn't work" then spams me with checkmark emojis and claims in the chat message the distributed solution is complete.

A decent amount of it is slop, to be honest, but an 80% working solution means I am getting more money and resources to turn this into a real initiative. At which point I'll rewrite the code again but I'll pay closer attention now that I know docker better.

The problem is the lack of experience compounds.

Because AI accelerates the rate of knowledge gain, this gets even faster.

I’ve observed radically different workflows amongst senior candidates vs junior candidates when using an ai. A senior candidate will often build an extremely detailed plan for the agent - similar to how you would do a design for/with a junior engineer. Then let the agent go full throttle to implement the plan and review the result.

Juniors seem to split into the category of trust everything the ai says, or review every step of the implementation. It’s extremely hard to guide the ai while you are still learning the basics, opus4.6 is a very powerful model.

My thinking is a bit different here: Seniors, even mediocre ones, already learned a lot of hard lessons by doing things pre-LLMs, even pre-SO. Those skills are valuable and I don't know how to train them into juniors.

I find it easier to get a reasonably smart senior to use AI in a good way, than to train a junior in what thinking to do, and what to outsource, learning basics about good design, robustness and risk analysis. The tools aren't the problem per se, it's more about how people use them. Bit of a slippery slope.

That's just my anecdotal experience from not a whole lot of data though. I think the industry will figure it out once things calm down a bit. Right now, I usually make the bet to get one senior rather than two juniors. Quite different to my strategy from a few years ago.

> Code now does not need much design.

I’ll bite: why? Genuine question, not a weird gotcha.

No it isn't, because in the context of the comment it should be read "people with experience and/or credentials desired [...] are always in high demand " regardless of their actual performance level.

I also think its being used to filter out people that aren't basically a mirror for the interviewers in many instances.

I've noticed a huge tightening of the rope around that sort of thing.

I can't tell you how many times I've passed all the tests, all the interview things, get to the final round with the team and the rejection email comes in despite having good conversations. By all accounts, I believe any person would say the interview went well.

my peers are reporting the same things.