To be honest, I’ve done quite a bit of LeetCode, and while it’s great for practicing algorithms and problem-solving, I’ve found that I rarely use these “fancy” algorithms in my actual work. Most of the time, what really matters is breaking down requirements into clear logic, writing maintainable and collaborative code, and communicating well with the team. These skills are hard to assess through algorithm-focused interviews alone. I really hope interviews can place more emphasis on practical engineering skills and real-world scenarios, which would be more valuable for both companies and candidates.
I’m currently preparing for interviews myself, so having access to high-quality, free resources like this is incredibly helpful. The AI interviewer feature, in particular, looks like it will be very useful for me. Thanks again to the author for making these resources available!
I think it really depends on the job. In most jobs I've had the algorithms rarely get more complicated than just avoiding accidental O(N^2). The sort of thing where juniors would do a linear search.
But I did have one job working on an AI graph compiler which used fancy algorithms all over the place. In practice though I found the space between "use the standard library" and "it's NP-complete; use heuristics" where the answer is "you can use this neat dynamic programming trick" is basically nonexistent.
This is awesome. Just for awareness - I started going through the book a few days ago and there's a lot of other useful information outside of the LC style questions (e.g. what's actually important on a resume, how to realistically get your foot in the door with companies, etc.). Very data driven and comprehensive, so for me there's still a lot of value in the non LC parts of the book.
Incredible value here, thanks for sharing Aline. The book itself is a wonderful resource, not just for the technical chapters but the rest on resumes and reaching out etc. Even the technical portion provides the framework (boundary thinking, triggers, etc.) which is above and beyond basically any other resource online or in print. The AI interviewer is also super useful and the 'book' section of the site is very well put together. 10/10.
Welders, millwrights, machinists, carpenters, lots of trades have qualifying interviews. I’ve taken written exams in interviews for machining and welding as well as hands on show me parts.
Not that I agree with absurd interview process of software development but they often see themselves more akin to attorneys than tradesmen. The difference being attorneys have to pass a bar exam and even trades have journeyman cards to provide credibility.
Software development has none of that. Real engineering has PE licenses but how do you achieve that in such a broadly scoped field of software development?
We either play the interview game or find a way around it.
I may have a outdated notion about the trades you mentioned, but I have seen an "apprentice" model a lot. I have seen it with a masonry where the experienced guy was bringing in his nephew and teaching him on the job. A lot of these trades are family owned and have seen taking in people based on someone vouching for the new guy.
Maybe this varies country to country. I have seen this in India and UK atleast.
In UK atleast there are trades like roofing, landscaping, exterior building cleaning, masonry, tree surgeon etc which I have seen them are mostly family based.
This trade has never helped itself by insisting on being taken for a profession. A lot of these kids have never known the joys of time and a half - or the incentive that gives management to try to have all their s—t in one sock, every once in a while, for a change.
Right. Acting. It isn't more difficult for men because their part is, uh, hydraulically obvious. More to the point, it isn't less hard work for women. I get why guys assume it would be, though. Good grief, I bet you probably think you've never seen anyone fake an orgasm outside a porno, too...
Someone has reflexively taken offense at something here. It's clear who and I think I see what, but I have to confess myself still mystified as to why.
All I've said is that women also act and that's also hard work. I didn't say it is the same job, only that it is no easier. Why does that bother you so?
Young men are adorable, but really I feel for you. What you really desperately need is a role model, the same way I did at your age. None is to be found here.
'Principal' developer at my last place spent 100 consecutive days grinding leetcode. Shortly after had an interview where they made him do a leetcode test live and he failed it.
It's a whole separate skill to be able to code with an audience, let alone an audience who is judging you. I could forgive a non-technical interviewer not knowing this but surely someone who is a dev themselves understands the very real performance anxiety. It's bonkers why we do this to people— the best I've seen is the in person talks about their experience, architecture, problems they've encountered and how they solved them and then either code samples from their public code if they have some or a short take-home assignment if they don't.
They could cheat on the take-home but it isn't meant to be difficult and you hopefully figured out at the in-person that they're someone who wouldn't need to bother cheating.
I can't code with somebody looking over my shoulder. I need to relax and think about the task.
They expect me to code while being judged by one or more strangers, against the clock, with high stakes involved. If that was the actual job I would not apply for it.
A good analogy I’ve been told is the NFL combine. Vertical jump, straight-line speed, and bench press performances are probably moderately correlated with on-field performance, but the best test of playing the game is playing the game.
I more understand the emphasis on leetcode problems for juniors but a timed session without an observer (perhaps with browser tracking) to solve those problems makes a lot more sense than bringing in the anxiety of the observer, as you’ve noted. It sucks having to spend mental energy wondering how your problem-solving looks to whoever’s watching and seems actively detrimental to assessing talent for an IC role.
It's almost impossible for me to do any serious work or problem solving in an interview situation due to anxiety and stress-my mind simple does not work the same way as it does when relaxed and in flow.
I interviewed at Amazon for a principle engineering position - got the interview as my resume has some pretty high profile accomplishments. But they just asked me leetcode questiins all day. I don't practice leetcoding so needless to say I didn't do well. Everyone there looked tired and worn out, probably dodged a bullet.
I was approached for Principal at AWS by the team's hiring manager, and I liked them, and was interested in the team's work. But when they couldn't exempt me from the company-standard initial coding screen, I withdrew my application.
I'm sure the manager was great, but we've all heard of some less-desirable aspects of working at Amazon, and I wouldn't want to go there without a sign that I'd be shielded a bit.
So, I've made the "corporate drone coding screen", and Leetcode interviews in general, my own metric. If a company does it, they fail the interview.
And if I'm having a moment of weakness, and considering submitting to some techbro frat hazing, I remind myself that, if I was willing to do that, I would've gone to Google already, which usually would've preferable to whatever opportunity this other company is dangling.
I don’t get why people act like terms like “Principal Engineer” have an agreed-upon specific meaning that can be used in cross-company discussions. At most places I’ve worked the titles were a duct taped hierarchy born of “we needed to give so-and-so another raise but had run out of non-manager titles, so here’s Senior Software Engineer II”
FWIW, the "principal" part implies a few things no matter which org... they should be able to manage a project from start to finish, mentor juniors, and make confident correct architectural decisions.
If you've ever hired a plumber or electrician, you might have gotten a crew of younger apprentices, maybe a journeyman, and an older "master" plumber or electrician. Most of the master's time is spent with the critical mechanical tasks, solving problems that occur, and directing those other tradesmen. The principal is the 1 person who can do _any_ of the other's job if they are unavailable. They are also the 1 person (and ideally the only 1 person) who makes "the plan" for how the work will proceed, and also decides when a project is complete.
The crucial difference (well, one of many?) between a principal-level engineer, and any type of management...is that the principal-level engineer should be able to do every junior engineer's job in a pinch - expertly, and with confidence and adapability to problems.
Some basic level of leetcoding should be fine to verify that the candidate can at least code and is not only a bullshit artist who jumps from one position to the next, failing upwards.
I had some interviews, not at the principal level, we had a couple of candidates who were very good during the informal interviews, they could hold a conversation about technology, but they couldn’t code the simplest of problems. I know folks don’t like it, but this could happen in my humble opinion at all levels.
I don't doubt you in the least: I've also seen BS artists who got through interviews without being able to so much as write a for() loop.
But I've never seen anyone fail upwards as far as a Principal/Staff Engineer level. Last time I interviewed at that position, no one even asked anything about code. They were more concerned about my position on architectural choices, pros and cons of various approaches, knowledge of applicable standards and regulations (I'm in the medical device field), mentoring and team leadership issues and how to resolve them, etc.
Lots of reasons you can fail an interview, doesn't mean they're a bullshit artist. If we want to be intellectually honest about this process (letting a candidate prove themselves), the least we could do is offer different formats for people to pick from: leetcode live coding, take-home, pair coding, PR review, etc.
What is key is letting the candidate decide the format they're best at.
Leetcode's signal is pretty bad compared to pair coding/PR reviews IMHO. And if the job genuinely involves writing algorithms, you can put algorithms in the code and have them go over that.
Take home is probably the most vulnerable to cheating, but if you have them code review it afterwards, it's detectable fairly easily.
OP here.
A few of you have asked why we made these problems free. The answer is twofold, simple, and maybe even a bit underwhelming:
1) We want people to read the book (To wit, we've also made 9 chapters of the book free: http://bctci.co/free-chapters)
2) We want people to use interviewing.io
In my career, I've written a lot of stuff about hiring, and I've shared a lot of interview-related materials (e.g., full length interview replays). I hate paywalls for content, and you probably do too... and I have never regretted making it free. In my experience, putting good stuff out there is the best way to market to an eng audience.
I would like to give a try, but I am getting this for India:
My name is Aline, and I'm the founder of interviewing.io. Thanks so much for your interest. It looks like you’re not in a country where we’re open for business yet, so we can’t create your account, but we’ll add you to our waitlist.
I think the reason leetcode problems are still popular is because they test whether a candidate is willing to work hard (‘grind’) on problems that don’t even matter. A lot like what actually goes on at a FAANG company.
Hard disagree. At FAANG companies, working on problems that "don't matter" is exactly how you get a "Meets Some" or worse at your next perf review. These companies are obsessed with measurable impact - you need to show clear business value, user metrics, or revenue impact.
Spend 6 months grinding on irrelevant work and you'll be on a PIP in a blink of an eye
Usually low level engineers don't have a say on what projects they get to work. They show impact by completing whatever projects were handed to them and hope/pray those projects take off and become visible to upper management and/or tied directly to revenue.
The grind aspect is real though. 99% of FAANG engineers aren't building the next google maps or LLM, they are doing Enterprise CRUD + ELT + jira tickets. Companies like Meta and Amazon have enormous workloads and thus a grinder is preferable.
After a few years of experience, CRUD and ETL can be done while sleepwalking so the only missing component is someone willing to grind, e.g. someone who will spend 100 consecutive days doing leetcode
The writing is on the wall for Leetcode-style interviewing. The signal-to-noise ratio is diminishing in the age of AI (cheating). These sorts of puzzle challenges might no longer play a meaningful role going forward.
I agree with what Mike said. We shared the content because we want people to read the book and to use interviewing.io... it's not because we've given up on it (see my longer comment about it: https://news.ycombinator.com/item?id=44136448). We have yet to see any real evidence that technical interviews are dying.
What is hopefully dying is companies asking verbatim LeetCode questions and candidates having to memorize a bunch of questions. We wrote this book largely because we wanted to teach people how to think. I knowing how to think is only going to get more valuable.
Hot take from the author: This is a commonly repeated claim, but it’s probably not accurate.
It’s FAR easier for companies to stick with the interview process they’ve used for decades—just mandate in-person interviews again—than to reinvent the wheel with some new, unproven format. Sure, there’s a growing need to assess more than just DS&A in initial screenings, but let’s be honest: those interviews aren’t going anywhere.
The REAL reason to make these resources free? Because it’s not a competitive advantage to offer problems to practice. There are already tons of free problems online. The real value isn’t in giving people a place to do problems—that already exists. The value is in the book. If you already know enough to do well on problems without the book, then you shouldn't have to pay to practice it.
Aline is a bit of a Hacker News legend. She's been active here for longer than most people have been working and when you see how she's built her product, it's plainly obvious that she legitimately understands and sides with the HN community.
I bet the genuine answer to your question is that she knows it's a resource that could help tons of people (at a time when tons of people need that help) and paywalling it means that it won't serve that same purpose.
LeetCode-style interviews used to be an aptitude test, kinda like the weeder courses in college. Now that most people cram for them, they've lost their original purpose.
I wish I could just submit my solution and be told if it passes instead of dealing with the AI Interviewer. A lot of problems don't have a leetcode equivalent.
You can try to short-circuit the AI Interviewer by just entering your solution into the IDE. OR you can ask to end the interview, and then you'll get a link to the solution.
We built it this way on purpose, though... the intent is to mimic an interview and gently force you to talk through your thought process, not to have yet another LeetCode clone.
We use Clearbit for enrichment: https://clearbit.com/ That said, all interviews on interviewing.io are anonymous unless you and your interviewer both explicitly opt in to unmask.
Long ago, some dotcom, founded by students who'd never worked, used their own idea at the time about what software development is about (i.e., Stanford first-year CS problem sets). And since that company had a lot of money (for different reasons), a lot of wannabe companies tried to mimic whatever they did.
Today, CS student's idea of an industry interview has turned into an extortion racket cottage industry, with people not only selling ritual prep books, but now also selling mock interview rituals with techbros who got into the best-paying companies.
Youse has a lovely career potential; its would be a shame if somethings was ta happen to your job interview.
What more does it take to realize this is very time-consuming and expensive theatre, and terrible metric for hiring good software engineers.
And if you're an employer who doesn't care that students spend many hundreds of hours rehearsing for the interview theatre, to the exclusion of getting more experience building things, and that your interviews aren't actually selecting for software engineer aptitude, what happens when the hire takes that same misaligned hoops-jumping mindset to their work.
Thank you for this. Some people are critical of coding tests but I do this there is a point: namely to weed out people who can't code.
Am I the only one that interviewed people with lengthy resumes full of programming experience and when I asked them to do a simple programming exercise they fell flat on their face? I've seen experience in C, gave them take home two hour exam and they couldn't even get anything to compile. What he meant was he took a class a few years back.
You see it in other domains with extensive Excel experience and the guy gets hired and never heard of a vlookup.
I think some of the stuff is overkill but you need to select for people that know how to program.
I for one am glad they exist because I don't have a CS degree but learned on my own. I lucked into this profession through an online leetcode style screener and your book helped me immensely,so thank you
I think we may have disagreement on what Leetcode means in this context -- but it has to be complicated and varied enough that simply memorizing the solution is not sufficient. It being interesting is a bonus for other parts of the technical interview.
You are not the only one. I've interviewed probably 1000's of engineers and it is striking how often one runs into candidates that can't code... or ones that operate at a level far below what you would expect.
Meh. There is a world of difference between 1337code problems and anything one encounters in the real life. Judging someone by that 1h slot on a domain they haven't worked on for decades doesn't paint the right picture. It does tell a lot about the priorities of the company though, so there's that.
I think it paints part of a picture - obviously you shouldn't hire just based on top score in an algorithmic interview. But if I interview someone for a JOB WRITING CODE with decades of experience and they refuse to write code and can't explain the difference between a linked list and an array, that's a good argument for reconsidering hiring them...
Sure, explain. Write? Not sure about that. The main question is what kind of code they are supposed to write. Have you actually used a linked list in a company setting? I know the difference, but can't say I've used it... ever, in a company setting. I guess if I worked for Redis or similar this would be base requirement, but for 98% of software development jobs I don't see where this could be useful.
My experience is the opposite - developers eager to squeeze every last drop, using some exotic data structure [*] or sorting algorithm which takes way too long to implement and makes code review a nightmare. For a feature that doesn't need it.
[*] not saying that linked list is exotic, it is just rarely needed in $DAYJOB in my experience.
Yes, I have used a linked list in a company setting, both in writing code and in technically leading things where understanding the behavior of linked lists vs arrays was important.
But again, it's not the only criteria in these kinds of interviews IF CONDUCTED WELL - the specific experience you cite, of "developers eager to squeeze every last drop... makes code review a nightmare. For a feature that doesn't need it" is also part of what you're looking for. And you can ask a candidate who does that "hey, that seems unnecessary here and hard to undrstand, why are you doing that?"
Cracking the Code Interview is a great book and excellent for practice and brushing up. But I have found leet-code questions terrible for actually interviewing candidates. A lot of them boil down to whether the candidate knows the specific trick or can regurgitate the memorized solution.
(Maybe I am just bitter because I have more than once bombed a leet-code interview myself)
I interview a lot of people and my go-to coding question is actually a pretty simple question that might be found in a 2-year coding course. What I am looking for is production ready code, good error handling, tidy design, and understandable code. All things that leet-coding specifically discourages.
Leet Code style questions are a shorthand assessment for two things:
1. Raw mental horsepower
2. The ability to just repeatedly do focused learning, aka just grinding
And sure, it probably does favor #2 these days - but that is a critically important skill. You can trade one for the other, but everybody has some amount of both, and these questions figure out, roughly, your computed aggregate score of these.
They have a very high false negative rate, but an exceptionally low false positive rate for a 60 minute interview, so it works very well in companies with large interview candidate pipelines.
Why is 2, the ability to grind/memorize random problems, important for any company? I can't think of any company I've worked at, where that would be useful during my day to day work.
Maybe I'm in the minority, but I don't think the ability to memorize dozens of algorithms and then spit them out on demand is really that useful to most practicing software developers, nor is it a good signal about one's technical expertise.
People love to say things like this. In my experience on both sides of these coding interviews in FAANG companies, the questions are basically never algorithmically intensive.
The furthest I've ever seen it go in practice: binary search, BFS/DFS, hash tables. I've never seen any more obscure algorithmic trick than standard uses of these algorithms and data structures.
I'm not saying leetcode doesn't have more insane questions, but interviews tend to be straightforward.
I disagree. Many of the leet code problems can be solved by thinking them through and coming up with a solution without ever seeing the problem before. If the candidate gets stuck, the interviewer should act as a partner and offer occasional hints in case some sort of trick is involved.
Maybe we have different things in mind when we say "leet-code questions".
I don't know why leet-code style interviews would discourage the things you mentioned.
People keep saying this, but no one ever shares any meaningful data to make their case. Tech companies have been using Leetcode-style interviews to hire programmers for decades, and have grown in value from nothing to trillions of dollars in that time. The industry as a whole is worth tens of trillions, and the software these fake Leetcode programmers have built has eaten the world. Large companies have all spent billions on recruiting and internal processes and have come to the same conclusion - coding interviews work, and are very effective. Why should they stop? Vibes? Online comments?
I used to agree with the anti-Leetcode sentiment like the OP, but changed my tune fairly quickly once I started doing actual production-grade software engineering that goes beyond just simple CRUD and realized the things that Leetcode tests are applicable everywhere. It just kinda clicked one day for me and I started passing Leetcode assessments.
Sure, some interviews are pretty hard and some algorithms/data structures are not as common on the job. But given a complex enough system, you'll run into lots of situations where having this foundation will pay off. I mean, it's just computer science.
That's the thing about software engineering. You can get a lot done without knowing the foundational stuff. But then you're just a blunt instrument. Everything looks like a nail to a hammer.
I am the OP. Please understand that I am not against coding problems in interviews. Anyone who has done any interviewing will tell you that a surprising number of supposedly qualified applicants cannot code at all (usually because they have been doing project management for too long.)
And if you have a specific industry need to invert a binary tree or fill 8 containers with 32 differently sized boxes or whatever then go nuts. But I have found working through a 30 minute exercise with the candidate, asking them to explain their thought processes, and listening to what questions they ask is much better than just giving them 30 minutes to bash their head against a problem.
It is more effort for the interviewer though because it cannot be automated. But it does allow you to scale the interview by asking things like "What would it take to make your code thread safe? Imagine 4 threads. Now imagine 1000, what would you change?", etc.
So I agree with both things you said here - besides filtering those that can't code at all, you learn a lot by working through the problem with the candidate. And vice-versa. "30 minutes to bash their head against a problem" is not a good interview process.
Honestly it's 30-45 minutes where you can establish whether the person can code, and whether they have the basic foundational knowledge to crack efficiency problems is pretty hard to beat.
Whilst there's probably diminishing returns on making the actual challenge more and more difficult, the general concept is a lot fairer than the majority of other interview types I've had thrown at me. ( Usually something they've solved internally, where they expect you to regurgitate the same answers without the same context )
The problem is leetcode interviews for CRUD jobs, and there is no accountability to really stop that.
This is in part due to job titles being meaningless. Senior Software Engineer has a very large dynamic range of technical ability needed when looking industry-wide. For example, if "Developer" was the non-leetcode title, and "Engineer" was the leetcode title (with harder interviews and higher pay), it'd make things a lot more understandable for everyone.
It's not a static situation. The questions have changed, to the point where solving them in interview conditions is a separate skill. When I interviewed people at Google, I asked interesting but quite simple questions and they gave me all the information I needed. As a candidate doing interviews elsewhere I have often been asked questions that are way too complicated to actually solve in the time.
How we got to this point : as average candidates train more in interview-coding, the interviewers pick harder and harder questions. It's got to the point where the only way to reliably pass is to have pre-canned memorized solutions to hundreds of existing questions. It's an arms race divorced from the reality of the job, which is done with real world tasks, privacy, little time pressure, and access to reference materials.
Hot take: these interesting, contained problems that you really can solve on your own are a finite resource, and every time you read the solution to one you permanently deplete that resource for yourself.
That comment and yours both broke the guidelines [1], particularly the one that asks us not to "fulminate".
It's fine and welcome here to critique anything, we're just trying to make HN something other than a ragefest, particularly about topics that people have been saying the same enraged things about for a long time.
When the same things have been said about an issue for a long time, it's time to think about new ideas and new solutions to that issue.
It's fine to feel whatever you feel about technical interviews, but the guidelines ask us to be more measured when we post comments here. Several guidelines cover this in different ways:
Comments should get more thoughtful and substantive, not less, as a topic gets more divisive.
Please don't fulminate.
Please respond to the strongest plausible interpretation of what someone says, not a weaker one that's easier to criticize. Assume good faith.
Eschew flamebait. Avoid generic tangents. Omit internet tropes.
Please don't post shallow dismissals, especially of other people's work. A good critical comment teaches us something.
IMO "easy/medium" coding questions have their place. I run quite a lot of interviews and I have many many "seniors" from known techn companies that can't do exercises that are glorified reverse for loops.
The idea all tech companies require you to know niche data structures is kind of a meme honestly. I'm sure some do but not the ones I've interviewed at at least.
Sure, if you think the candidate might actually be lacking basic skills, which wasn't obvious from his resume you obviously ask him some basic trivia. But establishing this as part of a process, including having companies which prepare you for this process is ridiculous.
What is the point of all of this. No other industry has this.
Because other engineering disciplines don't have joke applicants, because other engineering disciplines have governing bodies distributing credentials. If you're a PE, everybody knows you have a base level of competency in your field. Yeah you might not be a great engineer but you're not going to be the Civil Engineering equivalent of somebody typing questions into ChatGPT and pretending to not understand you when you ask why they're reading a script back to you.
I'm not necessarily arguing that software engineering should have some gatekeeping organization that you need to prove yourself to, but you take the good with the bad. In other engineering disciplines, a third party organization takes the responsibility of filtering out the unqualified people. In software, the hiring companies have to do it, so you end up with the first interview (at least) being spent just proving you're not lying about every single thing on your resume.
No other engineering discipline has such a low barrier to entry where everyone can self tech themselves at home almost everything people that go through the higher education pipeline can, and then extra on top due to how fast the industry evolves, where even having a degree might not make you qualified for a job today. In no other engineering discipline is all the tooling FOSS.
So the PRO is that anyone can become a SW engineer, but the CON is that when anyone can become a SW engineer you're competing with soo many people on an even playing field that weeding out the wheat from the chaff is tricky and no company had the perfect solution because it doesn't exist.
What other engineering profession things change so fast that tools from ~20 years ago (C, PHP, Perl, etc) are not useful on the job market anymore? What other engineering profession gets hundreds/thousands of applicants per open position? What other engineering profession has such a lack of standardization that every company works completely different, with different tools and different processes to ultimately do the same thing?
In most other traditional engineering disciplines it's not just the university degree or credential that matters to getting in, but a lot of critical knowledge can only be gained from mentoring and learning at the job from graybeards of the industry, knowledge you'll never get if you try to teach yourself, even if technically all the relevant courses and information is freely available online. Not to mention that in a lot of engineering professions the tooling is specialized, non-FOSS and very $$$, so your only chance of touching it is at university or a company who will pay you to get certified in that tooling.
How many 100% self taught, no prior experience people are applying to these positions and are accepted for interviews? Obviously that number is extremely low especially given the last couple of years.
Having a process which only exist for the 1% of least likely candidates is absurd. Even if you wanted to give these people w chance, obviously you don't need to subject the 99% of people to the same process. What is the point of asking a CS graduate with 5 years industry experience some brain teaser questions? There is literally no point, it tells you exactly zero about the candidate.
Also, you can self teach everything in most engineering disciplines. What part of Electrical engineering or mechanical engineering requires a substantial financial investment or has things you could only learn in a university?
How is criticizing the premise of something a "generic tangent"? If the premise behind something is bad the whole thing is bad.
Evaluating something obviously needs to account for the context it exists in. In fact talking about this particular Show HN is impossible without implicitly or explicitly taking a position on the hiring process. If the current hiring practices were good, having resources to succeed in them would be beneficial and praise worthy. Otherwise they only help to strengthen a broken process, although obviously it might be beneficial to individuals to game that process (which further demonstrates the problems with that process).
I don't see how you even could substantively talk about this post without evaluating the hiring practices it presupposes.
If the premise behind something is bad the whole thing is bad.
Then find a thread where the premise is being discussed, if that's how you feel, or write your own post about the faults of the premise. "The premise of your whole thing is invalid" is not something you can grumpdump on someone showing their work. The, well, premise of Show HN is people showcasing their work specifically - it's not an invitation for everyone to express their views on general things they dislike.
The idea that criticizing something by criticizing its premise is off topic or unrelated is ridiculous.
>"The premise of your whole thing is invalid" is not something you can grumpdump on someone showing their work.
Why? It is obviously extremely relevant and on topic. Also don't pretend this is some drive by "This sucks because hiring sucks". I specifically am criticizing the specific aspect this Show HN is targeting.
Because it's shitty and tedious? It's so shitty and so tedious there there are forum (beside basic human) conventions against it. They're right in the links above. Your comment is flagged dead. What further explanations are necessary here, really? "Don't be an internet jerk" is hardly an abstruse or unusual social concept.
Also don't pretend this is some drive by "This sucks because hiring sucks"
I don't have to pretend, it's the literal tangent that you took.
I do not believe that I even came close to breaking any rules or that I even went slightly off topic.
Of course I was "shitty", by not giving someone a pat on the back for their "hard work", simply because I think what they did is a waste of time and effort. Obviously I know that criticizing someone, who has put in significant work is very looked down upon.
This is also one of the reason I was flagged, the other wing people very invested in that hiring process for whatever reason taking issue with my position.
I do not mind a negative reaction to my comments, obviously I had to expect it. But my comment was on topic and it was flagged for going against the social convention of being generally supportive of people showcasing their work. If it makes me a "jerk" to point out that people have wasted their time on some stupid project, then so be it.
I do not believe that I even came close to breaking any rules or that I even went slightly off topic.
I'm afraid you're simply mistaken about that. It's not an ambiguous thing, it's repeated a bunch of times over and there are reams of mod comments about it. You don't owe anyone here pat on the back. You do owe everyone here basic decency or if you can't manage that, simply abstaining from bilecommenting.
This is also one of the reason I was flagged
You could ask the moderators to remove the flag if that's the case.
>I'm afraid you're simply mistaken about that. It's not an ambiguous thing, it's repeated a bunch of times over and there are reams of mod comments about it.
Again, I do not see which rules I would have broken. If there is some esoteric mod commentary, that it is off topic to talk about something more abstractly, than I am totally unaware of that and to be honest I neither believe that to be the case nor would I take that seriously. As far as the rules of the site go, I do not see how I violated them at all. Neither in wording nor in spirit, to be honest talking about things more abstractly seems to be explicitly encouraged by the rules and reading them again, after you linked them only made this more certain to me.
>You do owe everyone here basic decency or if you can't manage that, simply abstaining from bilecommenting.
I don't know what that means. My comment contained a substantive critique and I have not insulted any person, beyond pointing out what they did is a total waste of time. To be honest I do understand that my comment was quite negative and I agree that obviously many people reacted to this negatively. I fail to see how it is against any rules to make comments with harsh critiques that other perceive negatively.
>You could ask the moderators to remove the flag if that's the case.
Again, I expected the negative reaction. If people want to flag me for being critical that is their prerogative.
To be honest, I’ve done quite a bit of LeetCode, and while it’s great for practicing algorithms and problem-solving, I’ve found that I rarely use these “fancy” algorithms in my actual work. Most of the time, what really matters is breaking down requirements into clear logic, writing maintainable and collaborative code, and communicating well with the team. These skills are hard to assess through algorithm-focused interviews alone. I really hope interviews can place more emphasis on practical engineering skills and real-world scenarios, which would be more valuable for both companies and candidates.
I’m currently preparing for interviews myself, so having access to high-quality, free resources like this is incredibly helpful. The AI interviewer feature, in particular, looks like it will be very useful for me. Thanks again to the author for making these resources available!
I think it really depends on the job. In most jobs I've had the algorithms rarely get more complicated than just avoiding accidental O(N^2). The sort of thing where juniors would do a linear search.
But I did have one job working on an AI graph compiler which used fancy algorithms all over the place. In practice though I found the space between "use the standard library" and "it's NP-complete; use heuristics" where the answer is "you can use this neat dynamic programming trick" is basically nonexistent.
This is awesome. Just for awareness - I started going through the book a few days ago and there's a lot of other useful information outside of the LC style questions (e.g. what's actually important on a resume, how to realistically get your foot in the door with companies, etc.). Very data driven and comprehensive, so for me there's still a lot of value in the non LC parts of the book.
Incredible value here, thanks for sharing Aline. The book itself is a wonderful resource, not just for the technical chapters but the rest on resumes and reaching out etc. Even the technical portion provides the framework (boundary thinking, triggers, etc.) which is above and beyond basically any other resource online or in print. The AI interviewer is also super useful and the 'book' section of the site is very well put together. 10/10.
I wonder which other professions or trade ask people to perform infront of them in a simulated env as a filter criteria.
Actors for sure with auditions and maybe maybe chefs, male pornstars.
Welders, millwrights, machinists, carpenters, lots of trades have qualifying interviews. I’ve taken written exams in interviews for machining and welding as well as hands on show me parts.
Not that I agree with absurd interview process of software development but they often see themselves more akin to attorneys than tradesmen. The difference being attorneys have to pass a bar exam and even trades have journeyman cards to provide credibility.
Software development has none of that. Real engineering has PE licenses but how do you achieve that in such a broadly scoped field of software development?
We either play the interview game or find a way around it.
I may have a outdated notion about the trades you mentioned, but I have seen an "apprentice" model a lot. I have seen it with a masonry where the experienced guy was bringing in his nephew and teaching him on the job. A lot of these trades are family owned and have seen taking in people based on someone vouching for the new guy.
Maybe this varies country to country. I have seen this in India and UK atleast.
In UK atleast there are trades like roofing, landscaping, exterior building cleaning, masonry, tree surgeon etc which I have seen them are mostly family based.
This trade has never helped itself by insisting on being taken for a profession. A lot of these kids have never known the joys of time and a half - or the incentive that gives management to try to have all their s—t in one sock, every once in a while, for a change.
> maybe maybe chefs
staging [1] is very much a thing for kitchen staff
[1] https://en.wikipedia.org/wiki/Staging_(cooking)
All sorts of managers and analysts have "project stages" where they have to analyze data and present a case study.
Only male?
Males are under pressure to "sustain" it for 10-15 min atleast (with many people watching). For females, no such thing.
[flagged]
They didn't say anything about acting? They said men have to "sustain" - ie hold an erection without ejaculating.
Right. Acting. It isn't more difficult for men because their part is, uh, hydraulically obvious. More to the point, it isn't less hard work for women. I get why guys assume it would be, though. Good grief, I bet you probably think you've never seen anyone fake an orgasm outside a porno, too...
gender roles, and dare I say even sex roles, are actually noticeably different in sex.
Did I say that they were not?
the entire premise of your objection is "what about women in porn?"
OC listed three jobs total, the premise being that jobs in which a tryout is a useful evaluation tool are rare.
There is no a priori reason to believe that the very different jobs that men and women have as porn actors should both fall into this rare category.
Unless, of course, you're reflexively looking to take offense at the idea that men and women are not interchangeable.
Someone has reflexively taken offense at something here. It's clear who and I think I see what, but I have to confess myself still mystified as to why.
All I've said is that women also act and that's also hard work. I didn't say it is the same job, only that it is no easier. Why does that bother you so?
Because no one was talking about the difficulty of the task except for you, and you chose to get indignant.
I didn't raise the subject: https://news.ycombinator.com/item?id=44137282
Young men are adorable, but really I feel for you. What you really desperately need is a role model, the same way I did at your age. None is to be found here.
'Principal' developer at my last place spent 100 consecutive days grinding leetcode. Shortly after had an interview where they made him do a leetcode test live and he failed it.
The whole thing is broken.
It's a whole separate skill to be able to code with an audience, let alone an audience who is judging you. I could forgive a non-technical interviewer not knowing this but surely someone who is a dev themselves understands the very real performance anxiety. It's bonkers why we do this to people— the best I've seen is the in person talks about their experience, architecture, problems they've encountered and how they solved them and then either code samples from their public code if they have some or a short take-home assignment if they don't.
They could cheat on the take-home but it isn't meant to be difficult and you hopefully figured out at the in-person that they're someone who wouldn't need to bother cheating.
I can't code with somebody looking over my shoulder. I need to relax and think about the task. They expect me to code while being judged by one or more strangers, against the clock, with high stakes involved. If that was the actual job I would not apply for it.
A good analogy I’ve been told is the NFL combine. Vertical jump, straight-line speed, and bench press performances are probably moderately correlated with on-field performance, but the best test of playing the game is playing the game.
I more understand the emphasis on leetcode problems for juniors but a timed session without an observer (perhaps with browser tracking) to solve those problems makes a lot more sense than bringing in the anxiety of the observer, as you’ve noted. It sucks having to spend mental energy wondering how your problem-solving looks to whoever’s watching and seems actively detrimental to assessing talent for an IC role.
It's almost impossible for me to do any serious work or problem solving in an interview situation due to anxiety and stress-my mind simple does not work the same way as it does when relaxed and in flow.
Principal Engineer level shouldn't even be tested on leetcode. There are far more important things to know about that candidate.
I interviewed at Amazon for a principle engineering position - got the interview as my resume has some pretty high profile accomplishments. But they just asked me leetcode questiins all day. I don't practice leetcoding so needless to say I didn't do well. Everyone there looked tired and worn out, probably dodged a bullet.
I was approached for Principal at AWS by the team's hiring manager, and I liked them, and was interested in the team's work. But when they couldn't exempt me from the company-standard initial coding screen, I withdrew my application.
I'm sure the manager was great, but we've all heard of some less-desirable aspects of working at Amazon, and I wouldn't want to go there without a sign that I'd be shielded a bit.
So, I've made the "corporate drone coding screen", and Leetcode interviews in general, my own metric. If a company does it, they fail the interview.
And if I'm having a moment of weakness, and considering submitting to some techbro frat hazing, I remind myself that, if I was willing to do that, I would've gone to Google already, which usually would've preferable to whatever opportunity this other company is dangling.
It’s because they’re not interested in engineers, they’re looking for visa workers from cultures that optimize for grinding those types of questions
depends on how much you're willing to suffer for the stock
I don’t get why people act like terms like “Principal Engineer” have an agreed-upon specific meaning that can be used in cross-company discussions. At most places I’ve worked the titles were a duct taped hierarchy born of “we needed to give so-and-so another raise but had run out of non-manager titles, so here’s Senior Software Engineer II”
FWIW, the "principal" part implies a few things no matter which org... they should be able to manage a project from start to finish, mentor juniors, and make confident correct architectural decisions.
If you've ever hired a plumber or electrician, you might have gotten a crew of younger apprentices, maybe a journeyman, and an older "master" plumber or electrician. Most of the master's time is spent with the critical mechanical tasks, solving problems that occur, and directing those other tradesmen. The principal is the 1 person who can do _any_ of the other's job if they are unavailable. They are also the 1 person (and ideally the only 1 person) who makes "the plan" for how the work will proceed, and also decides when a project is complete.
The crucial difference (well, one of many?) between a principal-level engineer, and any type of management...is that the principal-level engineer should be able to do every junior engineer's job in a pinch - expertly, and with confidence and adapability to problems.
Some basic level of leetcoding should be fine to verify that the candidate can at least code and is not only a bullshit artist who jumps from one position to the next, failing upwards.
I had some interviews, not at the principal level, we had a couple of candidates who were very good during the informal interviews, they could hold a conversation about technology, but they couldn’t code the simplest of problems. I know folks don’t like it, but this could happen in my humble opinion at all levels.
I don't doubt you in the least: I've also seen BS artists who got through interviews without being able to so much as write a for() loop.
But I've never seen anyone fail upwards as far as a Principal/Staff Engineer level. Last time I interviewed at that position, no one even asked anything about code. They were more concerned about my position on architectural choices, pros and cons of various approaches, knowledge of applicable standards and regulations (I'm in the medical device field), mentoring and team leadership issues and how to resolve them, etc.
Lots of reasons you can fail an interview, doesn't mean they're a bullshit artist. If we want to be intellectually honest about this process (letting a candidate prove themselves), the least we could do is offer different formats for people to pick from: leetcode live coding, take-home, pair coding, PR review, etc.
What is key is letting the candidate decide the format they're best at.
Leetcode's signal is pretty bad compared to pair coding/PR reviews IMHO. And if the job genuinely involves writing algorithms, you can put algorithms in the code and have them go over that.
Take home is probably the most vulnerable to cheating, but if you have them code review it afterwards, it's detectable fairly easily.
if only he had spent 101 days...
Or the interview was about more than just leetcode and they just weren’t that good.
Aline and team are doing great work. Love to see this!
Proud to have helped work on this. Happy to field any questions.
Why make the questions and AI interviewing free? This sounds too good to be true
OP here. A few of you have asked why we made these problems free. The answer is twofold, simple, and maybe even a bit underwhelming:
1) We want people to read the book (To wit, we've also made 9 chapters of the book free: http://bctci.co/free-chapters)
2) We want people to use interviewing.io
In my career, I've written a lot of stuff about hiring, and I've shared a lot of interview-related materials (e.g., full length interview replays). I hate paywalls for content, and you probably do too... and I have never regretted making it free. In my experience, putting good stuff out there is the best way to market to an eng audience.
I would like to give a try, but I am getting this for India:
My name is Aline, and I'm the founder of interviewing.io. Thanks so much for your interest. It looks like you’re not in a country where we’re open for business yet, so we can’t create your account, but we’ll add you to our waitlist.
Odd, that shouldn't be happening. Can you please email support@ and say you're trying to access the book materials, and we'll investigate
I think the reason leetcode problems are still popular is because they test whether a candidate is willing to work hard (‘grind’) on problems that don’t even matter. A lot like what actually goes on at a FAANG company.
Hard disagree. At FAANG companies, working on problems that "don't matter" is exactly how you get a "Meets Some" or worse at your next perf review. These companies are obsessed with measurable impact - you need to show clear business value, user metrics, or revenue impact. Spend 6 months grinding on irrelevant work and you'll be on a PIP in a blink of an eye
>working on problems that "don't matter"
Usually low level engineers don't have a say on what projects they get to work. They show impact by completing whatever projects were handed to them and hope/pray those projects take off and become visible to upper management and/or tied directly to revenue.
The grind aspect is real though. 99% of FAANG engineers aren't building the next google maps or LLM, they are doing Enterprise CRUD + ELT + jira tickets. Companies like Meta and Amazon have enormous workloads and thus a grinder is preferable.
After a few years of experience, CRUD and ETL can be done while sleepwalking so the only missing component is someone willing to grind, e.g. someone who will spend 100 consecutive days doing leetcode
This sounds like an amazing resource. What’s the rationale for making it all free?
> What’s the rationale for making it all free?
The writing is on the wall for Leetcode-style interviewing. The signal-to-noise ratio is diminishing in the age of AI (cheating). These sorts of puzzle challenges might no longer play a meaningful role going forward.
I agree with what Mike said. We shared the content because we want people to read the book and to use interviewing.io... it's not because we've given up on it (see my longer comment about it: https://news.ycombinator.com/item?id=44136448). We have yet to see any real evidence that technical interviews are dying.
What is hopefully dying is companies asking verbatim LeetCode questions and candidates having to memorize a bunch of questions. We wrote this book largely because we wanted to teach people how to think. I knowing how to think is only going to get more valuable.
Hot take from the author: This is a commonly repeated claim, but it’s probably not accurate.
It’s FAR easier for companies to stick with the interview process they’ve used for decades—just mandate in-person interviews again—than to reinvent the wheel with some new, unproven format. Sure, there’s a growing need to assess more than just DS&A in initial screenings, but let’s be honest: those interviews aren’t going anywhere.
The REAL reason to make these resources free? Because it’s not a competitive advantage to offer problems to practice. There are already tons of free problems online. The real value isn’t in giving people a place to do problems—that already exists. The value is in the book. If you already know enough to do well on problems without the book, then you shouldn't have to pay to practice it.
Aline is a bit of a Hacker News legend. She's been active here for longer than most people have been working and when you see how she's built her product, it's plainly obvious that she legitimately understands and sides with the HN community.
I bet the genuine answer to your question is that she knows it's a resource that could help tons of people (at a time when tons of people need that help) and paywalling it means that it won't serve that same purpose.
What does “side with the community” mean?
LeetCode-style interviews used to be an aptitude test, kinda like the weeder courses in college. Now that most people cram for them, they've lost their original purpose.
I wish I could just submit my solution and be told if it passes instead of dealing with the AI Interviewer. A lot of problems don't have a leetcode equivalent.
You can try to short-circuit the AI Interviewer by just entering your solution into the IDE. OR you can ask to end the interview, and then you'll get a link to the solution.
We built it this way on purpose, though... the intent is to mimic an interview and gently force you to talk through your thought process, not to have yet another LeetCode clone.
How did your site know my first/last name when I gave my email address to create an account and clicked the confirmation link you sent?
We use Clearbit for enrichment: https://clearbit.com/ That said, all interviews on interviewing.io are anonymous unless you and your interviewer both explicitly opt in to unmask.
Long ago, some dotcom, founded by students who'd never worked, used their own idea at the time about what software development is about (i.e., Stanford first-year CS problem sets). And since that company had a lot of money (for different reasons), a lot of wannabe companies tried to mimic whatever they did.
Today, CS student's idea of an industry interview has turned into an extortion racket cottage industry, with people not only selling ritual prep books, but now also selling mock interview rituals with techbros who got into the best-paying companies.
Youse has a lovely career potential; its would be a shame if somethings was ta happen to your job interview.
What more does it take to realize this is very time-consuming and expensive theatre, and terrible metric for hiring good software engineers.
And if you're an employer who doesn't care that students spend many hundreds of hours rehearsing for the interview theatre, to the exclusion of getting more experience building things, and that your interviews aren't actually selecting for software engineer aptitude, what happens when the hire takes that same misaligned hoops-jumping mindset to their work.
Thank you for this. Some people are critical of coding tests but I do this there is a point: namely to weed out people who can't code.
Am I the only one that interviewed people with lengthy resumes full of programming experience and when I asked them to do a simple programming exercise they fell flat on their face? I've seen experience in C, gave them take home two hour exam and they couldn't even get anything to compile. What he meant was he took a class a few years back.
You see it in other domains with extensive Excel experience and the guy gets hired and never heard of a vlookup.
I think some of the stuff is overkill but you need to select for people that know how to program.
I for one am glad they exist because I don't have a CS degree but learned on my own. I lucked into this profession through an online leetcode style screener and your book helped me immensely,so thank you
> namely to weed out people who can't code.
You don't need Leetcode style tests to weed those out. Much simpler problems will do it.
I think we may have disagreement on what Leetcode means in this context -- but it has to be complicated and varied enough that simply memorizing the solution is not sufficient. It being interesting is a bonus for other parts of the technical interview.
Sure but there are varying degrees. I often ask people to write a factorial function. Quite a few fail at this basic task.
We agree - this is why programming interviews - whiteboard, virtual or something else - are here to stay.
You are not the only one. I've interviewed probably 1000's of engineers and it is striking how often one runs into candidates that can't code... or ones that operate at a level far below what you would expect.
Meh. There is a world of difference between 1337code problems and anything one encounters in the real life. Judging someone by that 1h slot on a domain they haven't worked on for decades doesn't paint the right picture. It does tell a lot about the priorities of the company though, so there's that.
I think it paints part of a picture - obviously you shouldn't hire just based on top score in an algorithmic interview. But if I interview someone for a JOB WRITING CODE with decades of experience and they refuse to write code and can't explain the difference between a linked list and an array, that's a good argument for reconsidering hiring them...
Sure, explain. Write? Not sure about that. The main question is what kind of code they are supposed to write. Have you actually used a linked list in a company setting? I know the difference, but can't say I've used it... ever, in a company setting. I guess if I worked for Redis or similar this would be base requirement, but for 98% of software development jobs I don't see where this could be useful.
My experience is the opposite - developers eager to squeeze every last drop, using some exotic data structure [*] or sorting algorithm which takes way too long to implement and makes code review a nightmare. For a feature that doesn't need it.
[*] not saying that linked list is exotic, it is just rarely needed in $DAYJOB in my experience.
Yes, I have used a linked list in a company setting, both in writing code and in technically leading things where understanding the behavior of linked lists vs arrays was important. But again, it's not the only criteria in these kinds of interviews IF CONDUCTED WELL - the specific experience you cite, of "developers eager to squeeze every last drop... makes code review a nightmare. For a feature that doesn't need it" is also part of what you're looking for. And you can ask a candidate who does that "hey, that seems unnecessary here and hard to undrstand, why are you doing that?"
Cracking the Code Interview is a great book and excellent for practice and brushing up. But I have found leet-code questions terrible for actually interviewing candidates. A lot of them boil down to whether the candidate knows the specific trick or can regurgitate the memorized solution.
(Maybe I am just bitter because I have more than once bombed a leet-code interview myself)
I interview a lot of people and my go-to coding question is actually a pretty simple question that might be found in a 2-year coding course. What I am looking for is production ready code, good error handling, tidy design, and understandable code. All things that leet-coding specifically discourages.
Leet Code style questions are a shorthand assessment for two things:
1. Raw mental horsepower
2. The ability to just repeatedly do focused learning, aka just grinding
And sure, it probably does favor #2 these days - but that is a critically important skill. You can trade one for the other, but everybody has some amount of both, and these questions figure out, roughly, your computed aggregate score of these.
They have a very high false negative rate, but an exceptionally low false positive rate for a 60 minute interview, so it works very well in companies with large interview candidate pipelines.
Why is 2, the ability to grind/memorize random problems, important for any company? I can't think of any company I've worked at, where that would be useful during my day to day work.
You don't think rote learning is a desirable skill of candidates that employers look for?
Can you think of anything we do for, say, the first two decades of our life, that could send this signal?
Maybe I'm in the minority, but I don't think the ability to memorize dozens of algorithms and then spit them out on demand is really that useful to most practicing software developers, nor is it a good signal about one's technical expertise.
It's def not "Raw mental horsepower" it's more knowing an obscure algorithmic trick.
People love to say things like this. In my experience on both sides of these coding interviews in FAANG companies, the questions are basically never algorithmically intensive.
The furthest I've ever seen it go in practice: binary search, BFS/DFS, hash tables. I've never seen any more obscure algorithmic trick than standard uses of these algorithms and data structures.
I'm not saying leetcode doesn't have more insane questions, but interviews tend to be straightforward.
I disagree. Many of the leet code problems can be solved by thinking them through and coming up with a solution without ever seeing the problem before. If the candidate gets stuck, the interviewer should act as a partner and offer occasional hints in case some sort of trick is involved.
Maybe we have different things in mind when we say "leet-code questions".
I don't know why leet-code style interviews would discourage the things you mentioned.
People keep saying this, but no one ever shares any meaningful data to make their case. Tech companies have been using Leetcode-style interviews to hire programmers for decades, and have grown in value from nothing to trillions of dollars in that time. The industry as a whole is worth tens of trillions, and the software these fake Leetcode programmers have built has eaten the world. Large companies have all spent billions on recruiting and internal processes and have come to the same conclusion - coding interviews work, and are very effective. Why should they stop? Vibes? Online comments?
I used to agree with the anti-Leetcode sentiment like the OP, but changed my tune fairly quickly once I started doing actual production-grade software engineering that goes beyond just simple CRUD and realized the things that Leetcode tests are applicable everywhere. It just kinda clicked one day for me and I started passing Leetcode assessments.
Sure, some interviews are pretty hard and some algorithms/data structures are not as common on the job. But given a complex enough system, you'll run into lots of situations where having this foundation will pay off. I mean, it's just computer science.
That's the thing about software engineering. You can get a lot done without knowing the foundational stuff. But then you're just a blunt instrument. Everything looks like a nail to a hammer.
I am the OP. Please understand that I am not against coding problems in interviews. Anyone who has done any interviewing will tell you that a surprising number of supposedly qualified applicants cannot code at all (usually because they have been doing project management for too long.)
And if you have a specific industry need to invert a binary tree or fill 8 containers with 32 differently sized boxes or whatever then go nuts. But I have found working through a 30 minute exercise with the candidate, asking them to explain their thought processes, and listening to what questions they ask is much better than just giving them 30 minutes to bash their head against a problem.
It is more effort for the interviewer though because it cannot be automated. But it does allow you to scale the interview by asking things like "What would it take to make your code thread safe? Imagine 4 threads. Now imagine 1000, what would you change?", etc.
So I agree with both things you said here - besides filtering those that can't code at all, you learn a lot by working through the problem with the candidate. And vice-versa. "30 minutes to bash their head against a problem" is not a good interview process.
I'm pro make them code and test their big o.
Honestly it's 30-45 minutes where you can establish whether the person can code, and whether they have the basic foundational knowledge to crack efficiency problems is pretty hard to beat.
Whilst there's probably diminishing returns on making the actual challenge more and more difficult, the general concept is a lot fairer than the majority of other interview types I've had thrown at me. ( Usually something they've solved internally, where they expect you to regurgitate the same answers without the same context )
The problem is leetcode interviews for CRUD jobs, and there is no accountability to really stop that.
This is in part due to job titles being meaningless. Senior Software Engineer has a very large dynamic range of technical ability needed when looking industry-wide. For example, if "Developer" was the non-leetcode title, and "Engineer" was the leetcode title (with harder interviews and higher pay), it'd make things a lot more understandable for everyone.
It's not a static situation. The questions have changed, to the point where solving them in interview conditions is a separate skill. When I interviewed people at Google, I asked interesting but quite simple questions and they gave me all the information I needed. As a candidate doing interviews elsewhere I have often been asked questions that are way too complicated to actually solve in the time.
How we got to this point : as average candidates train more in interview-coding, the interviewers pick harder and harder questions. It's got to the point where the only way to reliably pass is to have pre-canned memorized solutions to hundreds of existing questions. It's an arms race divorced from the reality of the job, which is done with real world tasks, privacy, little time pressure, and access to reference materials.
Hot take: these interesting, contained problems that you really can solve on your own are a finite resource, and every time you read the solution to one you permanently deplete that resource for yourself.
Hotter take: manipulating intelligence signals is more effective for achieving things than doing things to improve intelligence.
You can hedge against that by trying your best to solve the problem once before reading the solution.
[flagged]
That comment and yours both broke the guidelines [1], particularly the one that asks us not to "fulminate".
It's fine and welcome here to critique anything, we're just trying to make HN something other than a ragefest, particularly about topics that people have been saying the same enraged things about for a long time.
When the same things have been said about an issue for a long time, it's time to think about new ideas and new solutions to that issue.
[1] https://news.ycombinator.com/newsguidelines.html
[flagged]
It's fine to feel whatever you feel about technical interviews, but the guidelines ask us to be more measured when we post comments here. Several guidelines cover this in different ways:
Comments should get more thoughtful and substantive, not less, as a topic gets more divisive.
Please don't fulminate.
Please respond to the strongest plausible interpretation of what someone says, not a weaker one that's easier to criticize. Assume good faith.
Eschew flamebait. Avoid generic tangents. Omit internet tropes.
Please don't post shallow dismissals, especially of other people's work. A good critical comment teaches us something.
https://news.ycombinator.com/newsguidelines.html
IMO "easy/medium" coding questions have their place. I run quite a lot of interviews and I have many many "seniors" from known techn companies that can't do exercises that are glorified reverse for loops.
The idea all tech companies require you to know niche data structures is kind of a meme honestly. I'm sure some do but not the ones I've interviewed at at least.
Sure, if you think the candidate might actually be lacking basic skills, which wasn't obvious from his resume you obviously ask him some basic trivia. But establishing this as part of a process, including having companies which prepare you for this process is ridiculous.
What is the point of all of this. No other industry has this.
Because other engineering disciplines don't have joke applicants, because other engineering disciplines have governing bodies distributing credentials. If you're a PE, everybody knows you have a base level of competency in your field. Yeah you might not be a great engineer but you're not going to be the Civil Engineering equivalent of somebody typing questions into ChatGPT and pretending to not understand you when you ask why they're reading a script back to you.
I'm not necessarily arguing that software engineering should have some gatekeeping organization that you need to prove yourself to, but you take the good with the bad. In other engineering disciplines, a third party organization takes the responsibility of filtering out the unqualified people. In software, the hiring companies have to do it, so you end up with the first interview (at least) being spent just proving you're not lying about every single thing on your resume.
Yes and other engineering disciplines have certifications and organizations that require you to pass exams to prove you have the knowledge
They also tend to pay less
Preparing for interviews is a small price to pay
No other engineering discipline has such a low barrier to entry where everyone can self tech themselves at home almost everything people that go through the higher education pipeline can, and then extra on top due to how fast the industry evolves, where even having a degree might not make you qualified for a job today. In no other engineering discipline is all the tooling FOSS.
So the PRO is that anyone can become a SW engineer, but the CON is that when anyone can become a SW engineer you're competing with soo many people on an even playing field that weeding out the wheat from the chaff is tricky and no company had the perfect solution because it doesn't exist.
What other engineering profession things change so fast that tools from ~20 years ago (C, PHP, Perl, etc) are not useful on the job market anymore? What other engineering profession gets hundreds/thousands of applicants per open position? What other engineering profession has such a lack of standardization that every company works completely different, with different tools and different processes to ultimately do the same thing?
In most other traditional engineering disciplines it's not just the university degree or credential that matters to getting in, but a lot of critical knowledge can only be gained from mentoring and learning at the job from graybeards of the industry, knowledge you'll never get if you try to teach yourself, even if technically all the relevant courses and information is freely available online. Not to mention that in a lot of engineering professions the tooling is specialized, non-FOSS and very $$$, so your only chance of touching it is at university or a company who will pay you to get certified in that tooling.
How many 100% self taught, no prior experience people are applying to these positions and are accepted for interviews? Obviously that number is extremely low especially given the last couple of years.
Having a process which only exist for the 1% of least likely candidates is absurd. Even if you wanted to give these people w chance, obviously you don't need to subject the 99% of people to the same process. What is the point of asking a CS graduate with 5 years industry experience some brain teaser questions? There is literally no point, it tells you exactly zero about the candidate.
Also, you can self teach everything in most engineering disciplines. What part of Electrical engineering or mechanical engineering requires a substantial financial investment or has things you could only learn in a university?
Sir, this is a Show HN.
And therefore you aren't allowed to criticize it?
If what you are making is built upon a joke of a premise that should be criticized.
You are allowed to criticize it but you can't fulminate and you can't go on some generic tangent, just like pretty much always? It's both in the Show HN thing https://news.ycombinator.com/showhn.html and the site thing https://news.ycombinator.com/newsguidelines.html
How is criticizing the premise of something a "generic tangent"? If the premise behind something is bad the whole thing is bad.
Evaluating something obviously needs to account for the context it exists in. In fact talking about this particular Show HN is impossible without implicitly or explicitly taking a position on the hiring process. If the current hiring practices were good, having resources to succeed in them would be beneficial and praise worthy. Otherwise they only help to strengthen a broken process, although obviously it might be beneficial to individuals to game that process (which further demonstrates the problems with that process).
I don't see how you even could substantively talk about this post without evaluating the hiring practices it presupposes.
If the premise behind something is bad the whole thing is bad.
Then find a thread where the premise is being discussed, if that's how you feel, or write your own post about the faults of the premise. "The premise of your whole thing is invalid" is not something you can grumpdump on someone showing their work. The, well, premise of Show HN is people showcasing their work specifically - it's not an invitation for everyone to express their views on general things they dislike.
The idea that criticizing something by criticizing its premise is off topic or unrelated is ridiculous.
>"The premise of your whole thing is invalid" is not something you can grumpdump on someone showing their work.
Why? It is obviously extremely relevant and on topic. Also don't pretend this is some drive by "This sucks because hiring sucks". I specifically am criticizing the specific aspect this Show HN is targeting.
Why?
Because it's shitty and tedious? It's so shitty and so tedious there there are forum (beside basic human) conventions against it. They're right in the links above. Your comment is flagged dead. What further explanations are necessary here, really? "Don't be an internet jerk" is hardly an abstruse or unusual social concept.
Also don't pretend this is some drive by "This sucks because hiring sucks"
I don't have to pretend, it's the literal tangent that you took.
I do not believe that I even came close to breaking any rules or that I even went slightly off topic.
Of course I was "shitty", by not giving someone a pat on the back for their "hard work", simply because I think what they did is a waste of time and effort. Obviously I know that criticizing someone, who has put in significant work is very looked down upon.
This is also one of the reason I was flagged, the other wing people very invested in that hiring process for whatever reason taking issue with my position.
I do not mind a negative reaction to my comments, obviously I had to expect it. But my comment was on topic and it was flagged for going against the social convention of being generally supportive of people showcasing their work. If it makes me a "jerk" to point out that people have wasted their time on some stupid project, then so be it.
I do not believe that I even came close to breaking any rules or that I even went slightly off topic.
I'm afraid you're simply mistaken about that. It's not an ambiguous thing, it's repeated a bunch of times over and there are reams of mod comments about it. You don't owe anyone here pat on the back. You do owe everyone here basic decency or if you can't manage that, simply abstaining from bilecommenting.
This is also one of the reason I was flagged
You could ask the moderators to remove the flag if that's the case.
>I'm afraid you're simply mistaken about that. It's not an ambiguous thing, it's repeated a bunch of times over and there are reams of mod comments about it.
Again, I do not see which rules I would have broken. If there is some esoteric mod commentary, that it is off topic to talk about something more abstractly, than I am totally unaware of that and to be honest I neither believe that to be the case nor would I take that seriously. As far as the rules of the site go, I do not see how I violated them at all. Neither in wording nor in spirit, to be honest talking about things more abstractly seems to be explicitly encouraged by the rules and reading them again, after you linked them only made this more certain to me.
>You do owe everyone here basic decency or if you can't manage that, simply abstaining from bilecommenting.
I don't know what that means. My comment contained a substantive critique and I have not insulted any person, beyond pointing out what they did is a total waste of time. To be honest I do understand that my comment was quite negative and I agree that obviously many people reacted to this negatively. I fail to see how it is against any rules to make comments with harsh critiques that other perceive negatively.
>You could ask the moderators to remove the flag if that's the case.
Again, I expected the negative reaction. If people want to flag me for being critical that is their prerogative.