Hacker News Reader

Comment by lapcat | Hacker News Reader

I won't attempt to generalize from my case, but let me offer a personal anecdote.

I'm now a successful, self-employed indie developer. One of the main reasons I stuck with indie development through the hard times—the maxim that it takes 5 years to become an overnight success was true for me—was that I became practically unhireable. There are multiple strikes against me: I'm middle age in an industry rife with age discrimination, I don't have a computer science degree, and I experience brain freeze during live coding interviews.

I would note that not all stress is the same. Firefighters rush into burning buildings for a living, and what could be more stressful, yet many of them would panic at the idea of giving a speech to a non-burning roomful of strangers. I have no problem with stress on the job, and I've successfully navigated many work emergencies during my career, but something about strangers standing over my shoulder judging me, determining my financial future by providing or withholding a job, like the sword of Damocles, turns my stomach inside out. And like the article author, I can revisit the coding problems and solve them afterward, as soon as the interview is over. Interviewers must think I'm a fraud who can't code, yet all evidence from my career, now almost 2 decades long, suggests otherwise.

A lot of commenters causally speak of "false negatives" as if they were random, but some people, myself included, are always the false negative. I am consistently filtered out by audition-style interviews. I'm not a stage performer.

[Edit:] I didn't expect my comment to rise to the top of an already crowded discussion. I feel a little self-conscious about it. ;-)

View on HN

> but something about strangers standing over my shoulder judging me, determining my financial future by providing or withholding a job, like the sword of Damocles, turns my stomach inside out ... I'm not a stage performer.

This resonates. I'm now in my early 60s. Oddly, in my 20s and 30s I could interview reasonably well. But as time went on, I think the interviewing styles became more confrontational.Whereas earlier on they were trying to find reasons to hire you, later on it was more that they were trying to find reasons not to hire you. Possibly this is somewhat attributable to ageism, but I think it was a change in the industry as well. Over the last 15 years or so I found interviewing to be increasingly unpleasant. Started having panic attacks in interviews. Somehow I still managed to get hired places (and I started doing more contracting where interviewing wasn't required because they were familiar with my work). When the startup I was working in lost it's funding at the end of '22 I decided it was time to hang it up and retire. Not because I don't like the work (I really do) and not because my skills were out of date (in the last startup I was working on optimizing AI algorithms to various hardware - CPUs, GPUs, FPGAs), but because I just couldn't face interviewing anymore and I really didn't need to.

Exactly this for me the last couple of years. Interviewing at most companies these days results in me getting through the final rounds only to be presented with “feedback” about all the secret things they really wanted that I didn’t meet the bar for. The feedback is often extremely vague but is always a list of shortcomings and rarely a list of strengths. The companies that do provide strengths are the ones I feel bad about missing.

> I think it was a change in the industry as well.

It's very true, I did not interview from about 2006 to 2014, and had no problems before, but had a noticeable feeling of "wtf is going on?" after this (and still do feel that way tbh).

It's the money. It's all about the money. Things are pretty low stress and low stakes when you're hiring for a 50k pure salary role. When things blew up into the mid six figures with stock incentives, it became a whole thing. This pervades the work environment too. Everyone is scared to death of saying the wrong thing or messing something up or sounding stupid because it means your 800k mortgage won't be getting paid next month. I hate it.

Your 800k mortgage not getting paid is one thing, but when there's a partner and kids who need money to eat, it's a whole other level.

Throw in that your health insurance tends to be tied to your job in the US.

Employers hate just as much giving 500k to an employee who does not deliver.

Nowadays it's the same poor interview when they are hiring for 20k pure salary overseas.

> earlier on they were trying to find reasons to hire you, later on it was more that they were trying to find reasons not to hire you

Have you by chance been pursuing roles at increasingly larger and more lucrative orgs?

I've worked at several startups, and those were clearly more looking for reasons to hire. Now at a FAANG, the interview process was clearly more in the looking for reasons not to hire direction...

Pretty sure he's talking about roles that pay close to seven figures TC, not a paper money startup.

Interviews aren't always confrontational. I have been using the same pair programming exercise for roughly the last hundred interviews. There are no tricky algorithms, just walking through the implementation of a basic rest endpoint. It's cooperative and I want the candidate to ask questions. If you can code at fizzbuzz level, are comfortable writing tests, and know a little about databases, it's easy.

There are probably great programmers out there that think pairing is horrible and stressful and this is the interview from hell. I accept that, but I also think that being able to pair and communicate is an important job skill. I want a team, not brilliant lone wolves.

My last three jobs all did pair programming so we structured our interviews to be similar, and they’re still my favorite interviews I’ve conducted. Many candidates also praised the format, whether they were hired or not.

The pair programming thing works great as an actual work sample test. I think it works best when neither person knows the answer though.

If one of you already knows what they want to see, it’s not really pair programming.

Either way though your process is already better than 90% of companies.

For the most part I think this is right though I'm not opposed to a quick screener. It reminds me more of the traditional engineering interview, which is more about how you think. Knowledge is good, but it usually isn't hard to obtain. But the way you think? That's much harder to change. I'd love to optimize for both, but if I have to pick I'd rather have someone who has a good engineering mind. Seems even more important these days, because if I just wanted to optimize for knowledge I'd just use an LLM and RAG.

This is how I've conducted a few interviews at a startup. I take pains to emphasize that:

1. I'm just looking for pseudocode, nobody cares about whether you do length(items) or items.size(), etc. The code won't even be run.

2. Invent functions without necessarily defining them, I'll object if doAllTheWork() needs to be fleshed out.

3. The problem/docs presented are the whole thing for the interview. There might be bugs to uncover, but there's no secret second phase to the boss battle.

Ultimately, I'm looking for them to assemble the basic building blocks, and see what suggestions they have when I point out issues like error, handling, stale data, security, etc.

There was a major industry change in technical interviewing practices after Google hit it big. They very publicly optimized their process to minimize false positives even at the expense of a high rate of false negatives. This included live coding and "brain teaser" type questions. Google was then wildly successful and so people in the industry assumed that their interviewing process was one of the reasons why. So a lot of other tech companies superficially copied the Google process in a "cargo cult" approach.

And I'm not claiming that the old Google approach was necessarily wrong or bad (I understand their current process has significantly changed but don't know the details). As an industry we still haven't figured out what the best practice should be. Everyone is still guessing. Every company seems to think they have an excellent hiring process but there are no real controlled experiments or hard data in that area. Who knows?

> Everyone is still guessing.

This isn't actually true, as the article points out; there is actually tons of empirical research.

Virtually none of that research is actually high-quality, reproducible, and correlated with organizational outcomes. I don't see it as really actionable one way or the other.

No one is capable of measuring programmer productivity objectively.

You can, if you have clear objectives.

Nah. It's impossible, unless you define "productivity" in such a narrow way that it ceases to be relevant to actual business value creation.

You just defined it, "business value creation", from there, you narrow it down, short term vs long term, strategic vs revenue generating, and so on.

The idea that you can't measure productivity is align with people who think "economics is not science."

I think it’s possible some of the time for some projects to measure how much business value an IC created.

But I also think there is no company with more than 50 software engineers employees that is able to accurately attribute business value creation to the majority of their software engineers.

Software engineers rarely pick what they work on, so in most cases you can only measure how well they meet the objectives they were assigned to work on.

And even then you can only get any kind of accuracy at the team level.

And those numbers aren’t comparable between teams because teams aren’t assigned to work on the same things.

People who think they can accurately measure things like velocity will bring out arguments based on the law of large numbers. But that only works when the number of samples is much larger than the number of variables, which is not the case for software engineering.

You can believe that economics is science. But still believe that it’s impossible to figure out how much GDP growth is attributable to each individual member of congress.

> Software engineers rarely pick what they work on, so in most cases you can only measure how well they meet the objectives they were assigned to work on.

There it goes, your other metric.

> People who think they can accurately measure things like velocity will bring out arguments based on the law of large numbers. But that only works when the number of samples is much larger than the number of variables, which is not the case for software engineering.

You can't accurately measure any coastline, but we don't stop at that.

>There it goes, your other metric.

1. It’s impossible to measure that except in aggregate

2. The only thing you can actually measure is how soon did it launch because the quality of the thing is too wrapped up in what it’s supposed to do.

How many bugs were there? That’s heavily dependent on how complicated the problem it’s solving.

The absolute best thing anyone has come up with is velocity, which just measures how good a team is at estimating. That also only works at the team level and it’s only accurate for teams repeatedly doing similar work that haven’t changed in composition for years.

> You can't accurately measure any coastline, but we don't stop at that.

We actually can accurately measure the relative lengths of coastlines such that we can compare them by picking a measurement resolution and using that for all of them.

You can’t do that here. It doesn’t work.

If we could accurately map business value creating back to ICs, tech companies would look very very different.

Even if you could objectively measure how good an IC is at meeting objectives. The developers I’ve met who were best at that metric tended to be terrible at their jobs in general because they’d just take anything product wanted and build it exactly as described.

So you want some amount of pushback. But not too much or they just end up not doing anything.

Try to come up with a metric for that. To do that though it needs to be normalized by how good the PM is at designing features. If the PM was terrific, you wouldn’t want pushback.

So now you have to rate all your PMs before you can rate your ICs. Then you need to rate the PMs bosses and so on. Until you have an uncomputable mess.

The best you can do is have enough EMs so they can get a feel for how ICs are doing. You can also probably expose the absolute worst performing engineers with metrics because they’re just literally doing nothing. But even then, you’ll get some false positives.

Nah. It's impossible to link business value creation to individual contributors. No one has ever figured out how to do this in a accurate, reliable, and repeatable way. When it comes to knowledge work, productivity can only be measured in aggregate for larger groups.

Most of economics is junk science. Very little of it is quantitatively rigorous or falsifiable in the real world.

Let's not forget it became a business. Gayle Laakmann wrote a book, became a consultant, and I'm sure earned a whole lot of money convincing companies that she'd found the perfect path to hiring great engineers.

I think she had a willing audience because a lot of companies weren't sure they were interviewing the 'right' way. It's always easier to tell your bosses you are following the advice of a top consultant than to try to tell them why you have a better strategy than the FAANGs.

Exactly! She was the one instrumental in publicizing this shitty way of hiring. Or course she could care less about the damage caused because she cashed in, actually still is.

AFAIK Gayle sold her book and services as a way to train for interviews, not conduct them. The problem is the companies, not her.

> This resonates. I'm now in my early 60s. Oddly, in my 20s and 30s I could interview reasonably well. But as time went on, I think the interviewing styles became more confrontational.Whereas earlier on they were trying to find reasons to hire you, later on it was more that they were trying to find reasons not to hire you. Possibly this is somewhat attributable to ageism, but I think it was a change in the industry as well.

At one point in my past, I was planning to do a career change over to Investment Banking (I know, I know... don't laugh), so I interviewed at a bunch of banks. These guys are notorious about how annoying and uncomfortable they make their interviews. They'll deliberately grief you and try to throw you off your game to see how you react, soft-skill-wise, under stress. Like they'll ask you a question about calculating a discounted cash flow, and then while you're answering they'll make a phone call to someone, just to see how you deal with disrespect.

While tech interviewing hasn't gone to those extremes, I definitely agree we seem to be moving that direction: interviewers seem to be deliberately looking for ways to stress/haze the candidate, for whatever reason. Something I never experienced interviewing in tech < 2005 or so.

That sounds something like the infamous interviews that Admiral Hyman Rickover conducted for the US Navy Nuclear Reactors program. He deliberately wanted to weed out officers who couldn't perform under intense pressure (although it's impossible to know whether that was really an effective approach).

https://www.usni.org/magazines/naval-history-magazine/1992/m...

> interviewers seem to be deliberately looking for ways to stress/haze the candidate, for whatever reason.

Probably caused by a tight market where there's greater pressure to filter a larger pool of candidates, and company cultures have worsened due to economic pressures.

This really resonates with me. It's hard to describe just how enjoyable and more importantly interesting tech interviews used to be. I can't think of one in the past decade that's left an impression on me. Now interviews feel like I'm playing Trivial Pursuit with a very non-technical George Costanza, trying to convey years of experience verbally when the card says Moops.

Yup, it's a gross system, designed only for checking if the kids did their CS data structures homework last week. This may have relevance at the FAANGs in the 2010s when they were hiring cattle, but small to midsize companies need about zero of that and would much better suited testing someone's ability to read/review code, or discuss edge cases for a feature, or any number of other soft, real world situations.

I've worked at startups for more than 20 years and I still fail these stupid tests because I refuse to "cram". And that's fine. Those are bad fits for me anyway - I've been a CTO, built and launched multiple companies, managed teams, worked well in teams, etc. But I am still treated like a new grad in most of these interviews.

I failed to implement a LRU cache fast and clean enough in one of these interviews. How many statups need this? I haven't done that since the 90s. And I fully understand how someone can look like an idiot for not being able to do some these tasks instinctively when they may be so recent in your mind, but if you never use them at your job, what's the actual point here? It's like hiring an architect based on their slide rule skills.

To me it shows a lack of care given to hiring in general. At best it reveals workers that will throw hours at problems rather than thought. Mercenaries, I guess. But companies that hire like that tend to have highly complex code. And not because it needs to be complex, but because the company culture tends to focus on clever solutions above solving business goals.

I would rather hire and work with people who focus on breaking down problems and keeping logic and structure as simple as possible. Complexity is the enemy of progress. If there is one benefit of leetcode is that it finds smart people who can handle lots of complexity. Which is useful! But I would rather hire someone who isn't and can't, but can solve real world problems effectively and consistently. Wild concept, I know!

Don’t get me wrong, at 51 years old with my experience, I wouldn’t even think about doing a coding interview and in fact the only reason I got into BigTech at 46 was because a position at AWS ProServe fell into my lap in 2020 (no longer there).

But given the choice between making BigTech compensation and enterprise CRUD compensation if I were 25-30 I with today’s opportunities (well not the current shit show) instead of when I was 25-30, of course I would “grind leetCode” and do what it takes.

> I would rather hire and work with people who focus on breaking down problems and keeping logic and structure as simple as possible

At my stage in life, I can afford to be picky about where I work and optimize my lifestyle choices over money. But if I were 25? If I had to work 40 hours a week anyway, my only concern would be where could I get the most money in my bank account and as much (public company) stock in my brokerage account via RSUs. You act as if being a “mercenary” is a bad thing. The only reason I work is to exchange labor for money. That’s been the case since 1996. It ain’t about “passion” or the “mission”.

Nothing wrong with being a mercenary and I agree with the value prop differences by age/life stage.

I think working in a non-spaghetti codebase makes a huge difference, work enjoyment-wise - regardless of age. And that can be more valuable than people think.

My first job out of school was an amazing model of how to run a company and had been around for years. I have also worked at startups who had immediately created a big ball of string within 3 years. The company with by far the smartest people had to run a nightly job to "recalculate everything" that took 10 hours because their logic was too complex to be reliably deterministic.

If I just wanted a fat paycheck I would have gone into finance or fintech, it's far simpler. I don't intend to discount other people's or company's choices, but I do think "leetcode as a default" is a terrible model for finding decent engineers, and even worse now we have LLMs.

> but I do think "leetcode as a default" is a terrible model for finding decent engineers, and even worse now we have LLMs.

I don’t disagree. It’s a gravity problem. I might not like gravity. But gravity doesn’t care if I like it or not if I jump off of a 25 story building. It’s a small investment in time to have a much better career trajectory.

Let me emphasize I wouldn’t do it. But I don’t have to. I’ve done the build the big house in the burbs things twice and now downsized. My (step)children are grown and fully launched. I have credentials an experience where two of the other BigTech cloud providers (I have worked at one) were recruiting me based on my network without grinding leetcode. But most people don’t have those choices at least at 25-26.

I definitely couldn’t advise someone who was a recent grad to meander in enterprise Dev because they didn’t want to play the game. Yes I realize a large majority of developers in the US are enterprise devs. If you take away my AWS account, I’m just an enterprise dev with above average communication skills.

I had a coworker that called himself Coin Operated Ken. 100% mercenary. Dude made bank and retired early.

I've been on the other side of this interaction, and it's just as frustrating -- we do a phone interview a student who's been doing random stuff with the project for a while; and some combination of stress, the phone, not being in his native language, and he's totally not performing, in a way that seems almost certain to be situational and temporary. We were all open to trying some other format that would help him perform better, but he decided to cut his losses and apply elsewhere.

But unfortunately, it seems pretty likely to me that non-live coding interviews will measure the ability to query LLMs. If it's a choice between filtering out people who freeze up at interviews, or letting in scammers who have no ability whatsoever, I'm afraid the first is still the best option.

If you think they're good, why not do a paid day of work then? They'll probably be querying LLMs all day after you hire them anyway.

I think this is impractical without at least some filter first. Some jobs get thousands of applications and some of those are fully fraud. I'm all for a paid work stint but where do you draw the line, how do you evaluate it fairly, and how do you make that possible and attractive for people already working?

Also: as someone who interviews and handles hiring, the biggest bottleneck for me is my time.

In enterprise sure, I had whole weeks where not much was going on, but in tech or in startups? An hour is already precious.

I love this idea in theory, but in practice this would just mean coming up with some throwaway project and then paying them a full day to build on it. I've never had a job where there wasn't at least a few days of onboarding (often times a few weeks) before somebody could productively contribute to our applications. If it's a brand new project then sure, but how often does that happen? And when it does, do you want your completely unknown candidate doing it or one of your senior engineers who understands the big picture, how it will fit in, your company culture/values/etc?

It doesn't need to be a day then hire. It can be done in stages.

My experience is LLMs can suggest some pretty good multi-day throwaway projects. I'd want to know can the candidate manage multiple agents, and effectively communicate/collaborate with humans.

Even something simple, like take 1 hr then explain to us this new repository in detail.

This would be at least partly my solution. Issue as I see it is, hiring someone is expensive largely because you're committing to giving them a prolonged position thats difficult to terminate.

I think contract hires need to become more of a norm.

Contract-to-hire positions are generally only attractive to candidates who aren't currently employed. For those who are, it's too big a risk.

If you know you're good, why don't you offer to pay to do a day of work for them? The potential upside seems massive if you actually get the job. You would also be able to offset the costs of borrowing another engineer's time to get up to speed somewhat.

> They'll probably be querying LLMs all day after you hire them anyway.

At least they hey will know when LLMs make mistakes.

> If you think they're good, why not do a paid day of work then?

not many people could take the time away from their current job, so you'd be automatically filtering out people who are currently employed (which, i would imagine, is a signal that they're already sufficiently good).

So only those who could take the time can come to this style of interview, and it introduces a systemic bias.

I never quite got this argument. If someone isn't willing to make time to work on a PAID project, it means they don't want the job bad enough. Take a day of vacation geez...

Most people looking for a new job apply for several before finding a good fit. If this became common practice, it wouldn't be taking a day of vacation, but potentially all of them. Not really practical.

That's a bad idea in general. A paid day of work may be legally impossible for some candidates who are currently employed and have signed an agreement with their current employer regarding IP rights and/or conflict of interest.

The way I've seen it implemented is that companies just wire it via Paypal and don't think too hard about it.

Wait, I meant startups. So compliance? Probably not a thing.

It's not a compliance problem for the hiring company but potentially places the candidate in legal jeopardy.

Companies constantly talk about how expensive it is to hire people because your most valuable employees have to spend time prepping for interviews, reviewing homework, discussing results etc.

In the era of full remote work I don't understand why you don't just have a small greenfield project that you can quickly onboard prospective employees with. Have a brief personality / resume griller screening, then hire them for a week and toss them at a few bugs or issues for this project with a semi-public slack. Then see what they output and decide at the end.

That would likely be less expensive then all the other nine layers of interviewing hell they maintain and get better results.

Managing all those 1099s come tax day as an IC looking for a job sounds nightmarish, let alone from the company's perspective.

If your interview can be passed by using an LLM and the job you are hiring for can’t be done solely with an LLM, by definition your interview isn’t testing for the skills you need for the job.

> will measure the ability to query LLMs.

Hell, most places are requiring their developers to query LLMs now anyway.

I realize my field is kinda special (industrial automation) in that it's really a mix of programming, IT, and electrical engineering, but I can usually tell if someone is knowledgeable with just a few minutes of conversation. You can also weed out the bullshitters - the people that present guesses as fact - who in my experience are much more of a problem.

I know of no test that will tell you if they're a good fit for your company, which is arguably more important than their skill level.

I guess I don't really understand what the coding tests are supposed to achieve, unless you're letting your managers interview people without a senior programmer to help. If that's the case, you may as well just pick randomly.

> I know of no test that will tell you if they're a good fit for your company, which is arguably more important than their skill level.

I'm beginning to see it the other way around though. My manager has to "get me". I've only met one so far and he understood who I was well enough during our first interview.

He was like "ah I see, so you have lots of different skills and you want to go into lots of different directions. Awesome! I think we can do amazing projects together." This was coupled with "during lunch we like to talk about (geo) politics, some science facts, random stuff and self-improvement, those type of things." (note: Dutch company)

Ultimately I noticed he must have a fairly high openness to experience. I think all managers that I am managed by should have that.

Having a manager that knows how to properly employ you is important, sure. I was talking more about how you work with your teammates to get things done.

There's a place for lone wolves at some companies, but in my line of business you have to be able to work with engineers, project managers, electricians, as well as other integrators. Our projects are definitely team efforts. I make an effort to assign tasks based on people's strengths, but if you're hard for my team to work with, you're useless to me and I'll eventually be in the boss' office asking for you to be replaced.

Don't university courses at some point entail open book, internet access enabled exams? And that's good enough for passing or failing a whole semester?

> If it's a choice between filtering out people who freeze up at interviews, or letting in scammers who have no ability whatsoever, I'm afraid the first is still the best option.

So far, my opinion is: you still can weed out scammers by running your questions against an LLM in advance. There are still easy questions (not even involving coding, just reasoning about the problem and identifying edge cases) where LLMs fail spectacularly.

I find that “age discrimination” in the industry not to be a myth. But it is more nuanced. If you’re older and have the skills and experience, “you should have”, the world is your oyster. I am 51 and found a job quickly both in 2023 after being Amazoned and last year.

Admittedly, I wouldn’t make it through a coding interview even though my jobs have always involved some coding. But at 51 years old, if I were still competing for jobs based on my ability to invert a btree on the white board, I’ve done something horribly wrong in my life.

I can do a system design interview with my eyes closed though. It’s been part of my $DayJob to come up with real world system solutions on the fly in front of clients.

> Amazoned

We have a data point.

I came from a world-class company, but it wasn't a MANGA, so I wasn't given the "implicit points" for coming from an environment with the right perfume. I was a radioactive 55-year-old. I almost never got to a second interview. As soon as someone figured out my age, the process stopped cold. I was usually ghosted.

As for coding interviews, I spend exactly zero time practicing. I've seldom practiced for tests, and have usually done well. I do pretty well, under stress. That's been my life, since I was 22, or so. I do suck at simple college tests, like balancing btrees, because I have never encountered one in my work. I do well at the stuff I encounter regularly.

As someone with no college degree, I found that absolutely no one has ever cut me slack, or given me the benefit of the doubt, so my entire career was having to prove myself, over and over again, with almost no room for error. I worked with top-shelf engineers and scientists, and they didn't really suffer fools.

Bit exhausting, frankly. But my entire adult life has been about getting high-Quality deliverables out the door, and being personally held to account for the work.

That doesn't really seem to be what today's companies want, though. Pissed me off, for a while, but it has ended up being a very good thing for me.

I doubt my degree in CS from 1996 where I learned COBOL and FORTRAN at a no name college in south GA makes a difference. Heck I doubt it made a difference after my first job, let alone after my second looking for my third in 2008z

I didn’t get a job at a company that anyone has heard of until I was 46 (AWS). My career before then was a journeymen enterprise developer until 2016 when I started leading projects. Now I still do hands on coding. But it’s now strategy cloud consulting specializing in “modernization” (ie app dev) with 50/50 client facing post sales architecture and coding and leading larger implementations.

Now admittedly, one of my secrets is that I keep completely clean shaven of all facial hair so there is no signs of balding or grey and I’m in decent shape. No one can tell my age.

According to Bill Burr it’s probably the lotion (https://www.youtube.com/watch?v=_sSSrtbujO4)

I always say that our school gets us our first job, then that gets us our next job, and so on.

But having a college degree on your CV does make a difference. Often, it's the HR screeners that are impressed with it; not the techs. I found that I usually got past the screeners, but the techs didn't like me. The educational creds didn't have anything to do with that. It was the lack of "cultural fit."

The company I worked for, was a top-tier Japanese photographic equipment manufacturer. The Japanese are tough taskmasters. You don't last almost 27 years at a joint like that, on brown-nosing and jargon.

But since I accepted my lot, I have been happier n' a pig in shit. I get to do code, seven days a week, ship regularly, and not have managers screwing up the party. Never knew it could be this good.

> “modernization”

Glad to hear this isn't just something I'm encountering in isolation. My role at a BigTechCo (and I'm barrelling right through my mid-40s) could be summed with exactly that same word.

> No one can tell my age.

My beard finally started to grey and after about 2 years of that steady progression I shaved it off and now people treat me so differently. Even people who already knew me treat me differently. It's been quite the experience.

> But at 51 years old, if I were still competing for jobs based on my ability to invert a btree on the white board, I’ve done something horribly wrong in my life.

And yet some of us in our 60s still like to be down in the nuts&bolts of the code. I don't think that means we did something wrong. It's just what we prefer.

It doesn’t matter what “I like”. I saw the writing on the wall at 40 that development was going to be a commoditized race to the bottom and it was going to be hard to stand out and that developer salaries were going to plateau and they largely did in second tier cities aside from the large tech companies.

If you look at the leveling guidelines of any major tech company or even smaller companies with real leveling guidelines. “Coding” is only the differentiator between junior and mid. After that it’s about “scope”, “impact” and “dealing with ambiguity” is.

When I was looking for a job in 2023 and last year, it was much easier for me to stand out from the crowd based on my architectural experience, leading strategy, being comfortable hopping on a plane and talking to CxOs than it was as a pure developer.

I still do my share of development but only for smaller POCs/MVPs where it doesn’t make sense to bring in a lot of specialists since I am pretty good in a lot of areas.

How did you begin to succeed in indie development?

I'm almost 40 and I've always loved programming as a hobby, but I decided to try it professionally last year. I know, I know, not the best timing!

I have an active Github of (what I think are) interesting projects, success in other fields before I tried software development professionally, good communication skills, etc. But my experience with live coding sounds like yours.

So I'm very curious if you have thoughts on the routes to independent contribution where all that matters is being able to do the thing, not signaling ability to do the thing. I know I can do the thing (or I'm confident I can learn how), so I'd rather get paid to do it myself, if that makes sense.

> I'm not a stage performer.

This. So much this. I’m over leetcode interviews and will no longer do them.

> A lot of commenters causally speak of "false negatives" as if they were random

They also don't talk about, what my experience has shown me, is an extremely high false positive rate.

I've passed these style interview for a few large companies and those places easily had the least skilled developers I've worked with. Similarly, I've been shocked by the lack of technical skill in many ex-FAANG coworkers I've had. Their are some exceptions, but those are typically people who worked for a FAANG nearly a decade ago.

In the early days when Google was doing more CS style algorithmic thinking tests, it might have been a better measure, but this world of "grinding leetcode" as a skill provides very poor signal on developer skill.

For an MLE position Meta currently requires two leetcode mediums to be completed within 40 minutes and the solution must be absolutely optimal, and this is as a screen. This can only be reasonably accomplished by studying all 100+ of their problems on leetcode so you know the answer before hand. I do think thoughtful algorithm design interviews can be high signal, but in it's current form you can't test anything other than "how many hours did you study this?"

Most of the smartest people I've known and worked with have much more interesting things to do with their time than grind leetcode. Additionally, at this level of grilling, you're not even thinking anymore. In fact, the interviewers seems genuinely surprised if you give a correct answer that is not exactly performed in the canned way expected. White boarding algorithm interviews can be great, but what we have to take is a sad facsimile of what was originally being tested.

It takes a lot of practice and is a skill in itself. Most interviewers would fail a similar live coding exercise if they interviewed at another company without practice.

The goal is to keep yourself grounded and focus on the problem at hand. Practicing under these circumstances of course makes it easier.

Yes I think this is worth emphasizing: Just as firefighters are’t interviewed by sending them into a burning building, and aspiring public speakers don’t walk onstage at TED but join groups like Toastmasters, you can train toward performing better in live coding interviews.

> you can train toward performing better in live coding interviews.

I have no doubt that you can. But how much time do I want to waste on this kind of training? Personally, I don't need to do these kinds of interviews anymore because I decided I could retire instead. I suppose if I were in my 20s, 30s or 40s I'd have to "waste" time training to interview (and let's be honest, it could take a lot of time) - or just decide to change to another industry.

This is why I start with something very simple. If I detect the candidate is getting paralyzed with nerves, I'll reassure them and give little hints to help bring them out of it. After successfully completing a simple exercise, they usually feel more confident and relaxed. Only then will I give them a more challenging problem, with the caveat that I'm mostly interested in seeing how they might approach the problem and what things they can tell me about it. If they solve it, great. If they don't, did they show an ability to reason about the problem well, or identify key aspects of the problem that make it challenging? Can they communicate their thoughts as they think about it?

That may be true but what proponents of Leetcode style interviews say, is that they don't care. This process filters out good and bad candidates but "post filter", what remains is higher quality candidates. It is absolutely questionable from a scientific perspective (where is the tracking of the "B" group for instance), but if companies want to do irrational things they are allowed to do it.

I think this wouldn't even be that bad of a thing (assuming that there's just so many candidates that you need some kind of filter), if it weren't for the issue pointed out in the study cited by the article: "But here’s a surprising finding: not a single woman in the public setting passed, while every woman in the private setting did."

That to me implies this isn't just an imperfect filter, but actually a very biased filter.

I expect for some companies, that pay 3-8X above average there should be a very large number of candidates. The really odd situation is the low paying, enterprise CRUD job that feels the need to use leetcode hard on their tiny pool of candidates that can't get jobs anywhere else.

> but something about strangers standing over my shoulder judging me

I don't like it when people I do know do it all that much, either, to be completely honest.

> I'm now a successful, self-employed indie developer.

That's the true goal. As long as you can independently make more than what they are offering and you won't need to be playing by their interview games.

Even if the cash headline is less, some people will consider being your own boss makes up for that.

> turns my stomach inside out

The most effective way to deal with this is to do it again and again until you get used to it.

It's the same thing as dealing with stage fright. Just keep doing it. The stage fright will fade away.

It's like moving, first time is very stressful and it's a whole ordeal, but after repetition it's a familiar, whole ordeal.

If one could line up several interviews a day it could work.

I haven't had a real interview this year.

There is truth to this but it's important to acknowledge that exposure therapy alone may not be sufficient for everyone and will require alternative modalities.

Nothing is sufficient for everyone. You set an impossible bar.

I've thought about this kind of thing.

There are a few huge personality disconnects at many companies.

One is that a lot of programmers are introverts and the people who hire them frequently are not.

If not managed well, this can lead to like hiring like and other problems where people who like to think deeply about problems are excluded or just not understood.

The open seating problem is adjacent. Managers might love to collaborate all day but a lot of introverts are working in a difficult environment.

I absolutely agree with you. Coding under pressure and duress results in code that may not operate as intended. Im in the camp of code is both a creative activity and that code has to be accurate in its implementation so it works nicely. I may refine the code several times to get the version I really want that I am satisfied with.

This is exactly why i'm now a couple years in to being a hopefully-one-day-successful self-employed indie developer. I somehow have a couple of clients who think i'm some kind of genius (i'm not), while being completely unemployable by "real" companies. Thank you for sharing this.

How did you land clients?

I started on Upwork.

Same. How does one become an indie developer?

Reply on news.ycombinator.com