Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I’m 50 in Silicon Valley and going through dozens of interviews right now. I decided to quit during COVID and now am trying to renter the workforce. I have 24 years experience and worked at companies you’ve all heard of and I honestly have great experience. I’m still a coder and code in my spare time because I enjoy it. I still maintain friendships with people I worked with over 20 years ago, we recently had a reunion lunch and it was nice to reminisce over the dot com days.

I’m so far 0/10 on interviews. The bar is so high now and the expectations of perfection in a 45-60 min interview are so ludicrous that I can’t find a job yet. I’m LeetCoding about 3-4 hours a day, focusing on medium and hard questions. I went to sleep last night at 1am after struggling to understand a hard-level LC question that took me about 2 hours to work through.

I know the drill, I’m not shirking away from studying. I’ve conducted hundreds of interviews myself. I’m old enough to have been through every single interview style that coders have had to endure since the Microsoft interviews of the 90s. But the sheer breadth of knowledge you need to know, plus the expectations of making perfect decisions in a limited amount of time is utterly ludicrous. It’s like people have forgotten that you can’t design Twitter in 45 mins or think about every single possibility. or that some of these coding questions that are being asked are PhD level problems, so if you’ve never seen it before, it’s going to be pretty hard to solve. Or that people can make honest mistakes and get on the wrong track for 10 mins out of a 4 hour interview, and then you get rejected. Or people also seem to forget that the interviewers themselves are so inexperienced at interviewing that they confuse their candidates with poor instructions, or they expect the candidates to guess what they themselves think the right answers are.

The most frustrating part is when you’re given a relatively “easy” question but you go down the wrong path, figure out your mistake, and then correct it and solve the coding question in the allotted time , and then be told that I “didn’t perform as strongly as they hoped”.

If I were told “study X,Y and Z. We will test you at LC hard only on this.” I could bang it out of the park. But I literally have to know every single topic in CS and every level. LC literally has thousands of questions. My brain can’t remember all of these solutions. I’ve been studying for 2 months solid and finished only 200 LC questions because some questions take me all night to understand and I’m exhausted.

The biggest insult is that a company I worked at before needs me to go through a full interview loop even though I have great performance reviews only a few years prior and my code is still running there. Not that I would return, because I left that place for a reason, but the idea that an interview is a better judge of my abilities than the years of performance reviews is completely mind blowing to me.

Everyone knows that interviewing is broken but it’s not broken. It’s mentally ill. It’s crazy. Interviews don’t test “how good of a performer will this candidate be?” It’s “how well will this person do on these random questions that we don’t know if it actually correlates to work performance.”

I was on an interview loop for my company where someone had a GitHub. When we suggested that we could check out their GitHub to see their coding, someone objected saying that we don’t know if that person actually wrote the code. The confidence people have that on-site interviews produce the best example of how smart people is a reflection of how insane things are.

Expectations are far too wide and as a candidate you need to know literally everything otherwise you won’t “perform strongly”. But it’s really just random chance. Coding interviews should be longer and less random. Give time for the person to mess up and get back on the right track. Isn’t that what you want in a co-worker? Systems design questions should be a long conversation about building systems, not just “what points did the candidate mention that I was expecting them to.”

Coding interviews are more of a hazing than indicator of future performance. And as more people study, the bar gets higher and higher until it will reach absurd levels. I have staff or senior staff level experience but I’m applying for E5 level positions because I would rather get into a company and work my way up than try to come in at a level where the expectations are mentally ill.



My pops and I were talking about this. We have a theory that the real reason these leetcodes are done is to allow large organization to discriminate in whatever way they want without opening themselves to discriminations lawsuits. I don't actualy believe this is the "conscious" reason, but I think this may be one of the reasons that leetcode style interviews are popular.

I can get everyone but the least skilled interviewer to pass if I provide enough assistance in the interview. Similarly, I can fail anyone but the strongest algorithmic candidates by being unhelpful in the interview. The interview allows enough "smoke screen" that I can basically end up passing/failing in a manner that is pretty detached from their "objective" algorithmic skill.

Just a theory.


Your theory has been seen before in other contexts - https://arxiv.org/abs/1110.1556

The Mathematics Department of Moscow State University, the most prestigious mathematics school in Russia, was [around 1975] actively trying to keep Jewish students (and other “undesirables”) from enrolling in the department.

One of the methods they used for doing this was to give the unwanted students a different set of problems on their oral exam. I was told that these problems were carefully designed to have elementary solutions (so that the Department could avoid scandals) that were nearly impossible to find. Any student who failed to answer could easily be rejected, so this system was an effective method of controlling admissions.


It's much more simple than that. It's meant to prevent job mobility. Eng salaries are already absurdly high. Ever noticed how almost all the big tech companies do more or less the same ritual? It's entirely design to prevent seniors from moving around. They're too expensive already. It is almost collusion. Before the big tech companies used to have a secret handshake agreement not to poach each others candidates. They were caught and ordered to stop and forced to pay fines. This was around 2013/2014. Since then LC questions have become absurd. The process is designed to favor younger candidates who will accept less money and work harder for the company.


I hear you on the ludicrous breadth of knowledge that is expected. I recently went through the interview loops of several large tech companies. This time around I decided to study leetcode only a little bit and to lean more into my experience during the interviews and it worked out better for me. Here's the biggest key to interviewing at senior+ level, I think. In the past, I think my tendency had been to assume that the interviewer was looking for one right answer and to try and meet them where they were. This time around, I would openly say that it depends on which context you're talking about. If someone asked me to design Twitter, for example, I could do it as a CRUD app with a web front-end, a microservice that's essentially an adapter to a SQL DB of some kind, pretty easy. So I would just say that. "If you are just starting out, this could easily represented this way and it could support you into thousands of users..." Then I would leave it on them to ask more questions about how to scale it up. I'd mention that you could carry the DB farther by using read replicas if you accept that not everything is in real time. Then we'd start to eventually talk about potential solutions for getting more realtime data like Firebase, but we'd talk about where in the stack is that really necessary or appropriate and at what scale. I found pretty good success this way, rather than starting with the most complex solution, instead starting with, basically, the simplest, and easiest to get going initially.


This is pretty much true, but if you're doing a coding test, don't just provide a naive solution full stop -- if you can _also_ provide more scaleable solution(s) or at least a discussion of how things could be made more scaleable in the readme, you'll do better


The only place where I really met high expectation is in finance. The amount of ten-seconds-for-the-answer-or-we-stop-the-interview questions was enormous.

Last 5 places I interviewed, 2 didn't ask LC at all, and I still failed at 4.

Also, for LC, you should work on it for 15-30 minutes and then look at the solution. It's the most efficient way. If you don't even understand the task, just don't do it. Similarly, sites like codeforces allow you to group tasks by algorithm and to sort them by number of people that solved them (and you can look at the solutions). This also simplifies the knowledge acquisition.

As for being a principal/staff engineer. This is all new to me and I have no idea how much these individuals code or what exactly they do (although I'm currently starting a principal engineer role in a company of around 300 engineers). So I assume either I'm silly or the title inflation is rampant. Although, the interview required operating systems, networking, algorithms, hardware, people skills, low/high level programming language knowledge that I guess I have. The questions were: "How does a UI library work?", "Describe this networking protocol?", "How many syscalls are triggered by npm install?", and whatever other question that they ask you to go as deeply as possible as you can.


I was in the exact same boat for several years. After repeated rejections, I took a break from interviewing for a couple years. I already had a job so I could afford to do that. I realized that I was applying for the wrong type of jobs. Instead of hands on IC roles, I targeted engineering manager roles since I have quite a bit of experience managing small teams. I recently landed a job with a FANG as an engg. manager. Even though there is a coding component the main focus is on systems design and team leadership, also I think there is less age bias for EM roles.


Similar age and circumstance but not in the USA.

The saddest part for me is the companies that just throw you a take-home exercise without even bothering to phone you first. You apply to a certain position and then, say a week later -or sometimes more-, they simply send you an email with some programming task to develop.

Frequently they are not small tasks but full projects which require multiple days of work. Just a few days ago: delivering a full web application to manage "map layers", with a DB, a back-end, and a "user-friendly front-end with a nice design"; testing included and all put into Docker containers, and a working demo somewhere published automatically from the repository.

And I mean, it's not just the assumption that you will spend however long it takes you on this for free, but that you will do it without even having had a simple conversation with them before.

----

Anyway, what I really wanted to say was: Good luck in your search. Stay sane.


This does have the effect though of filtering out candidates who were lukewarm on the position to begin with (eg they were just throwing applications around en masse) because now, yes, there is that investment to be made in proceeding with the application. And the coding test tends to become the focus of the rest of the interview process, assuming the company goes forward with it. And good companies will give fairly comprehensive feedback on your submission, so there's that.


>Expectations are far too wide and as a candidate you need to know literally everything otherwise you won’t “perform strongly”. But it’s really just random chance. Coding interviews should be longer and less random. Give time for the person to mess up and get back on the right track. Isn’t that what you want in a co-worker? Systems design questions should be a long conversation about building systems, not just “what points did the candidate mention that I was expecting them to.”

One reason for this is that large tech company have horrible diversity metrics and are trying to avoid getting sued for discrimination (bot just by candidates but also by the government). If every candidate is judged on the same robotic criteria then that makes a discrimination claim harder. A second reason is to avid managers building fiefdoms or employees having much more loyalty to their manager than the company.

Startups have a wider range of interviews but they also pay much less. Although you could get lucky with an late-stage startup that hasn't fully solidified it's interview processes yet.


Refuse these kind of on-the-spot tests and save everyone a lot of time.




Consider applying for YC's Summer 2026 batch! Applications are open till May 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: