Comment by crystal_revenge
15 hours ago
I generally tend to interview every year to see what's out there in the world (sometimes I find something worth switching for, other times not). I'm not even looking very hard but have had 4 interviews in the last month.
Personally I think it's a bit more nuanced than senior vs junior (though it is very hard for juniors right now). What I've seen a lot of hunger for is people with a track record of getting their hands dirty and getting things solved. I'm very much a "builder" type dev that has more fun going from 0-v1 than maintaining and expanding scalable, large systems.
From the early start of the last tech boom through the post-pandemic hiring craze I increasingly saw demand for people who where in the latter category and fit nicely in a box. The ability to "do what you must to get this shipped" was less in demand. People cared much more about leetcode performance than an impressive portfolio.
Now reminds me a lot of 2008 in terms of the job market and what companies are looking for. 2008-2012 a strong portfolio of projects was the signal most people looked for. Back then being an OSS dev was a big plus (I found it not infrequently to be a liability in the last decade, better to study leetcode than actually build something).
Honestly, a lot of senior devs lose this ability over time. They get comfortable with the idea that as a very senior hire you don't have to do all that annoying stuff anymore. But the teams I see hiring are really focused on staying lean and getting engineers how are comfortable wearing multiple hats and working hard to get things shipped.
> I'm very much a "builder" type dev that has more fun going from 0-v1 than maintaining and expanding scalable, large systems.
Maintaining and expanding is more challenging, which is why I’ve grown to prefer that. Greenfield and then leaving is too easy, you don’t learn the actually valuable lessons. As experience shows that projects won’t stay in the nice greenfield world, building them can feel like doing illusory work — you know the real challenges are yet to come.
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.
FWIW this is the best kind of job ever for me as well:
"when you started you didn't even know if there was a solution."
Regardless what the problem is - as long as I know _nobody knows if there is a solution_ it's an instant sugar rush.
You are free to bang your head against a stone wall for months trying to crack the damn thing.
OFC you need to deliver in the end. And this requires then ruthless "worse is better" mentality - ship something - anything. Preferably a the smallest package that can act as mvp that you know you can extend _if this is the thing_ what people want.
Because that's the other side of the coin - if the solution is not known - people are also not aware if the solution has true value or if it is a guess.
So in any case you have to rush to the mvp.
Such joy!
Of course the mvp must land, and must be extensible.
But these type of MVP:s are not a slam dunk.
The combined requirement of a) must ship within limited time b) nobody knows what _does_ require a certain mindset.
3 replies →
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.
> You learn the most valuable information from watching how things break and then fixing them.
Trust me, you get plenty of experience in this as a founding engineer in a startup.
Many of these comments make me wonder how many people here have actually worked at an early stage startup in a lead role. You learn a lot about what's maintainable and scalable, what breaks and what doesn't, in the process rapidly iterating on a product to find your market.
8 replies →
Valuable in what metric? I'm very much in the brownfield-has-the-lessons camp, but one of the lessons is that this experience has a very low market value. In fact it's so impossible to downgrade from "senior in $outdated" to "junior in $whateverisconsideredhotrightnow" that any brownfield experience could easily be considered to have negative market value.
I don't think they're mutually exclusive. You could just as easily describe someone with bootstrapping experience as being like an FAA crash investigator who investigates take offs. You get to know exactly what works when moving fast and looking for quick results, and what dooms a short timeline to failure.
2 replies →
I was just thinking yesterday that knowing all the ways something breaks and behaves is the key to understanding systems.
1 reply →
Yep. I have loved fixing problems in systems and the processes that the people working on them use for years.
“What kind of role are you looking for?”
“Technologist flavor of NTSB investigator.”
4 replies →
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
Oh boy you're wrong. Many people (including myself) are experts at doing 0 to 0.8. The rest is much more difficult.
1 reply →
This is news to me having watched many many many people fail to do 0 to 1.
Maybe you're just a really really good engineer and product thinking hybrid!
> 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.
I suspect the issue is the parent has never worked in an early stage role at a growing startup still iterating on finding product-market-fit. If they had they would realize you learn a lot about "maintaining and expanding", especially when your prototype now has a bunch of users.
This is evident in my personal experience by the fact that I am often the one that sees scaling and maintenance issues long before they happen. But of course parent would claim this is impossible.
Having worked at both greenfield startups and unicorns, I've found that virtually every problem I've encountered at the unicorn startups was caused by folks being incompetent at the greenfield level. Maybe when you get to the scale of Google things are different, but it's certainly possible to build a business big enough to retire off that doesn't require any more technical knowledge than what you'd learn at a two-person pre-PMF startup.
Architecting not knowing how to maintain it.
Edit: a legacy vibe coder
Sure, but that's in many ways the easy part.
If v1 is successful and attracts a lot of users, it will have to have features added and maintained.
Doing that in ways that does not produce "legacy code" that will have to be thrown away and rewritten in a few years is a very different skill than getting v1 up and running, and can easily be what decides if you have a successful business or not.
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.
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.
Having been in both roles, I believe it is important that each side of the “1” give the other a little grace.
When you are going from “1” to stable, there is some breathing room because you have a 1 that works, mostly. Sort of. Dealing with it may be a slow slog of sordid substitutions, but the pressure is different.
Going from 0 to 1 may involve working 80+ hour weeks with little sleep and enormous stress. It may mean meeting deadlines that make or break the product in a mad rush to fulfill a contract that saves or dooms the company. It may mean taking minutes to decide designs when days or months of consideration would have been more appropriate. And it may mean getting a lot of things wrong, but hopefully not so wrong that a version 2 is impossible.
As a final note: often v1 has substantial problems, that’s true. But sometimes it’s actually not that bad, and v2 fails because it was trying to shove the tech de jure (k8s cough cough) where it wasn’t needed so someone could get that shiny architect promotion.
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!
It's correct tho. If your entire career is nothing but greenfield development, you'll never know the result of your decisions or the impact of tech chosen.
Staff or principals that have a tenure of majority greenfield development are extremely dangerous to companies IMO. Especially if they get hired in a nontraditional tech company, like utilities, banking, or insurance.
2 replies →
My intention was actually to inspire others to maybe also start preferring long-term/maintenance work, because I feel there’s a lack of enthusiasm for that.
Almost invariably after submitting, I see how I could clarify and/or expand on my thoughts, so I often do end up editing.
6 replies →
The soft sensitive people today have no idea how hard a condesending asshole has to work to live up to his own standards. When they do, one should still find something to troll them with. If you cant find it you complaint about the excessive border radius creating a child friendly fisherprice kind of environment. If that is the worse you can find they should agree and confess they have a fear of sharp edges.
How times have changed
Passive aggressiveness isn't the opposite of kindness, and worse than directness, but you'll get away with it here because this is just reddit but more pretentious and all the same biases are intact, just more walls of text instead of getting to the point.
And yet it is correct. The most valuable engineers today are those who have maintained and expanded the 0..v1 crap from others, and are now driven and ambitious enough to go build the next generation of 0..v1. Armed with that experience, the crap is minimal and value maximized.
1 reply →
They're 100% correct, though.
4 replies →
> I'm not even looking very hard but have had 4 interviews in the last month.
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.
> 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)
> some specific job listings we had open for years
If you need to wait YEARS to hire someone with some specific experience, I can guarantee that you really didn't need that person. You're doing this just to check some specific artificial goal that has little to do with the business.
29 replies →
> 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's a small engineering org, allegedly head-hunting one principal engineer for the whole org, so it's a single opening. 10 months later they are still hunting for their special snowflake.
> 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
This is exactly what I mean. If you can go for years without filling a role, it's non-essential , and are in effect, "seeing what's out there". More and more companies are getting very picky on mundane roles, such as insisting on past experience in specific industries: "Oh, your extensive experience in low-latency comms is in telecoms? We prefer someone who's worked in TV broadcast, using these niche standards specifically, even though your knowledge is directly transferable. We don't want to waste 5 days on training"
1 reply →
Honest question. Were these super specialized roles with such specific skill requirements that it took such a long time to find the right person? Looking back, do you think the team would have been better off hiring someone who came close enough, and supporting them to learn on the job?
2 replies →
I assume that this means you're sending out rejections that include a mention of "we've hired someone else for this role".
If your hiring model is hiring multiple people through one posting, then you will probably get a lot fewer angry ex-candidates being weird (because they think you've lied to them since the posting is still up) by just sending out rejections that don't say that and just get the "we're no longer interested in you for this role" message across.
Nicer/more corporate language for both, of course.
2 replies →
What a time to be alive: Companies post roles that don't exist to interview candidates who don't plan to switch.
and waste everyone time
> 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.
> On the hiring side, at least in tech: interviewing really sucks.
I know it sucks, I've sat on the other side if the interviewing desk many times, and the charade wastes everyone's time - the candidates most of all because no one values that.
> 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.
It sounds like you've never had to deal with the BS that is headcount politics, which happens more at larger organizations due to more onerous processes. Upper management (director, VP) can play all sorts of games to protect a headcount buffer[1], and everyone down the chain has to waste their time pretending to be hiring just because the division heads want to "maximize strategic flexibility" or however they phrase it.
1. Which is reasonable, IMO. Large companies are not nimble when reacting to hiring needs. The core challenge are the conflicting goals thrust on senior leadership reporting to the C-Suite: avoiding labor shocks, and maximizing profitably -- the former requires redundancy, but the latter, leanness.
It sucks from both sides.
I am on the interviewing and screening side and understand what you're saying. I also empathize with the people I routinely reject who don't understand why they were rejected. It's hard to see why you might not be a right fit for a role.
> it seems really unlikely to me anyone would want to do interviews without seriously intending to hire someone.
I keep seeing this accusation thrown around and like you, I have a hard time seeing this. On the flip side, looking at it from the eyes of many disenchanted candidates, I can see how a theory like this is appealing and self-reinforcing.
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'm very much a "builder" type dev that has more fun going from 0-v1 than maintaining and expanding scalable, large systems.
Most prefer a greenfield project.
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.
Shipping is only hard when you have to deal with all the loose ends "builders" leave lying around.
There is famous term for those: Tactical Tornados
https://news.ycombinator.com/item?id=33394287
From 2022. Funny that soon after that we figured out how to automate the Tactical Tornado programmer and collectively decided that they're the best thing ever and nobody needs other kinds of devs anymore.
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.
Seeing a lot of the same. Never studied leetcode and didn't work at leetcode companies. I could do them, I passed AWS and Microsoft cloud at L5 levels with no prep, but never was my strong suit. But I ship, and I can play politics very well. Especially in crusty organizations. Lots of callbacks, very hot market.
My friends who are "book smart" and leetcode geniuses are struggling. They're my friends, but they come off a bit "off" at first glance, the stereotypical nerd vibe. They're all really struggling since they can't sell themselves properly and lack the interpersonal skills.
> I'm not even looking very hard but have had 4 interviews in the last month.
Did you get any offers yet? It seems the issue is not lack of interviews but lack of offers. Many companies are looking for a goldilocks candidate and are happy to pass on anything that doesn't match their ideal candidate
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.
I just had back to back round 6 interviews. Both companies have 8 rounds. And yes, not FAANG.
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.
I, too, am able to get interviews. The last time I made a serious search was in 2022-23, and companies were clearly eager to hire at competitive rates. This past fall, they were not. My salary requirements stopped at least two interview processes when the question was raised. In other cases it was not clear that the company was serious about moving forward with hiring for the position at all. A three month search ultimately came up dry, which is fine because I'm currently employed, but I do not think the hiring landscape is promising at all right now.
> Honestly, a lot of senior devs lose this ability over time. They get comfortable with the idea that as a very senior hire you don't have to do all that annoying stuff anymore.
A few years ago, when interest rates were 0% and companies were hiring at an unsustainable rate, I got a lot of criticism for cautioning engineers against non-coding roles. I talked to a lot of people who dreamed of moving into pure architect roles where they advised teams of more junior engineers about what to build, but didn't get involved with building or operating anything.
I haven't kept up with everyone but a lot of the people I know who went that route are struggling now. The work is good until a company decides to operate with leaner teams and keeps the people committing code. The real difficulties start when they have to interview at other companies after not writing much code for 3 years. I'm in a big Slack for career development where it's common for "Architect" and "Principal Engineer" titled people to be venting about how they can't get past the first round of interviews (before coding challenges!) because they're trying to sell themselves as architects without realizing that companies want hands-on builders now.
> 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 generally tend to interview every year to see what's out there in the world (sometimes I find something worth switching for, other times not). I'm not even looking very hard but have had 4 interviews in the last month.
The Pick-Up Artist's Guide to Tech Interviewing, you should be writing.
The first 100 subscribers get a 50% off discount the month of March, you should be announcing on LinkedIn and Tiktok, and making passive income.
The rest of us experienced people with proven track records have to learn algorithms on the weekends despite having white hair.
When I was in corporate I'd talk about cover your ass mode and get'er done mode. And while realistically I know both are necessary, I was always annoyed at the need to have a cya mode. I get a bit of schadenfreude from the thougt of the market being harder for the people who don't seem to have a get'er done mode, and a bit of his at the thought it might be because there's less concern over whom to bother if something needs to be fixed later.
I don’t see this reality in the style of interview being performed at all.
Everyone has seemingly adopted the FAANG playbook for interviewing that doesn’t really select for people who like getting their hands dirty and building. These kinds of interviews are compliance interviews: they’re for people who will put in the work to just pass the test.
There are so many interviews I’ve been in where if I don’t write the perfect solution on the first try, I’ll get failed on the interview. More than ever, I’m seeing interviewers interrupt me during systems or coding interviews before I have a chance to dig in. I’ve always seen a little bit of this, but it seems like the bar is tightening, not on skill, but on your ability to regurgitate the exact solution the interviewer has in mind.
In the past I’ve always cold applied places and only occasionally leaned on relationships. Now I’m only doing the latter. Interviewees are asked to risk asymmetrically compared to employers.
Interviews are easy to get, going through 4-8 rounds and making it through is not.
In your experience, what’s the best way to increase signal? I feel as though a lot of devs struggle with the initial process of getting past screening, drawing attention to projects, etc.
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.
At least in my experience, applying at jobs online has been entirely useless for the last 5 years. No company ever contacts you after using the online application forms. And the only way I’ve got interviews is from recruiters contacting me.
3 replies →
> 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.
This is the "quantify everything" mantra career coaches have been repeating for decades. As the story goes, no company is going to care that you refactored the FooBar library in order to make bugs in the DingDang module easier to fix. You have to only write down things that moved some quantifiable business needle like revenue or signups, even if the link to that needle is tenuous. Obviously, this ends up penalizing hard working, talented devs who don't happen to be working in areas where wins are easily quantifiable.
1 reply →
> Most resumes are not very good. Beyond the obvious problems like typos ...
This is a person who you're going to be reviewing their code or reading the documentation that they write.
If there are typos and poor formatting in the resume (that they've had the leisure of reviewing themselves and correcting), what does this say about the quality of the code the code or documentation that they're going to write when under a time constraint?
Are you going to be faced with the decision of having code with variables that have spelling errors and documentation that is grammatically or factually incorrect go through because of the time pressure?
The resume itself is a demonstration of the applicant's ability to pay attention to the details that matter in software development without showing a single line of NDAed code.
Interviews are easy, offers are hard.
>I generally tend to interview every year to see what's out there in the world (sometimes I find something worth switching for, other times not). I'm not even looking very hard but have had 4 interviews in the last month.
You've been interviewing forever. You're the well practiced pickup artist of job searching. Of course you'll be getting the call backs over the other 1000 applicants who don't have the same experience level applying. You "just know" how to read between the lines and tailor a resume, whip up a cover letter, etc whereas they're making mistakes.
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.
interviews aren't the problem, you know full well that "getting a call back" means nothing in this space, but the insane and unresolved technical round process
and sure, lots of people can't get a call back too, but starting the process means nothing
should say how many offers did you get, that's a better way to normalize it
Hopefully it’s not too much like 2008 and we end up with another huge surge in unpaid internships
[dead]