Comment by lapcat
1 day ago
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. ;-)
> 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.
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.
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.
1 reply →
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.
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?
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.
> Everyone is still guessing.
This isn't actually true, as the article points out; there is actually tons of empirical research.
2 replies →
> 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.
> 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...
> 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.
Nowadays it's the same poor interview when they are hiring for 20k pure salary overseas.
Employers hate just as much giving 500k to an employee who does not deliver.
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.
1 reply →
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.
1 reply →
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 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?
2 replies →
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?
1 reply →
> 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.
2 replies →
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.
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.
1 reply →
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.
1 reply →
Managing all those 1099s come tax day as an IC looking for a job sounds nightmarish, let alone from the company's perspective.
> They'll probably be querying LLMs all day after you hire them anyway.
At least they hey will know when LLMs make mistakes.
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.
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.
1 reply →
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?
> will measure the ability to query LLMs.
Hell, most places are requiring their developers to query LLMs now anyway.
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.
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.
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.
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?
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.
> 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.
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'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.
> 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.
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.
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)
2 replies →
> 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.
> 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.
Same. How does one become an indie developer?