At my old company, we never did take home assignments or whiteboard interviews. We just sat candidates down and pair programmed with them for a couple hours on whatever we were working on at the time. We paid them the same hourly rate we were making, (but didn't charge the clients for it).

If the candidate obviously didn't know what they were doing, we ended it early. Usually you knew within 15 minutes.

One candidate hated the interview process, and walked out. One candidate, likely a future business leader, argued vociferously for a higher hourly rate during the interview, and later with the founder.

But I would describe our success rate for finding good programmers who were easy to work with as "extremely high", and our rate for false positives as "I can't remember ever having one in about 4 years of working there".

The overhead for the engineering team to run these was not zero, and not everybody enjoyed doing it. But some people did, so we had them do it more often. I have no idea why this isn't a more common practice, I would recommend it to anybody.

Can you go a bit more in depth about the pairing session? Most companies I've worked at, even if the person coming in was familiar all technologies we were using, I can't imagine them grokking nor just "skipping over" the datamodel and system architecture/design. All non-trivial projects I've worked on had a "bad" codebase as a result of deadlines, pivots and misunderstandings. The code is always steadily improving, but never good enough that someone can just waltz in and get to hacking on it.

I can't answer for the parent, but I've done similar style interviews. Because the candidate is not familiar with your codebase, you must be the expert. Your job is to let them drive as much as possible, while you "unstick" them when they trip over what they can't possibly know. It is a collaboration, which is part of what makes this a good interview style IMO. Sometimes a candidate will offer an otherwise good solution, but it won't work well within your codebase -- in this case you explain why, and then you iterate.

Yeah, usually we would give a little bit of context, and then look at the sprint tickets in Jira, and take one. The candidate was not expected to be familiar with the codebase or product at all beforehand, and they weren't expected to become an expert on it during the course of the interview. But coming up to speed quickly is one of the skills we liked to see, since that was part of the job.

They should be able to 'hang', in the sense of being familiar with how we approach problem solving as programmers. They should ask questions when needed, and answer questions as they arose. The goal was to just figure out what level they were at in general, and what it would be like to work with them. They weren't expected to come up with the best possible solution, because usually there wasn't a single right solution.

We would ask them questions like "well, you saw the ticket, how do you think we should approach this?" or even just natural things like "this function we just wrote isn't working, what's going on here?". The point is that they are working on real problems — literally real problems — and not abstract CS exercises.

Since we mostly did pair programming every day, the other thing you'd get a sense of is how easy someone is to work with. Not everybody had experience pairing, which is to be expected. You found out quickly who took to it, and who wanted to be a lone wolf. We didn't not hire someone because they weren't good at pairing, but we factored it in. Some people just did not communicate very well, which is a problem.

(This also gave them a good sense of what it would be like to work with us, and sometimes people decided not to take an offer because they didn't like the way we worked: good outcome for everybody)

They would usually do two rounds of this, both on the same day. Morning session, then an afternoon session. We offered to take them to lunch in between, which exposed them to more of the team, and let us talk to them in a more casual setting. Part of the interview would also be a private talk with one of the founders, and an HR person (in a different session).

The people the candidate paired with would provide input like: "I would recommend hiring this person" or not, but didn't make the decision themselves.

Here, I should admit that we did have a set of artificial problems we'd give candidates if we were hiring for a skillset that did not have a real project to test them on. We did both web and mobile contracts at this (consulting) company, so if we were hiring, e.g., an Android dev but didn't have an Android project for them to work on, we'd have them check out a repository and work on a fake ticket instead. Usually this was with a developer beside them, but I can remember times when the candidate had to do it solo.

This is great. If I had my own company I would do basically the same:

1. have a look at the candidate's github / stack overflow profile. If you like what you see, invite him/her for an interview; 2. have a couple of pair programming sessions as you described, with different team members (and don't let team members influence each other during the hiring decision); 3. invite the candidate for lunch and see how he/she treats others (basically an asshole test)

> 1. have a look at the candidate's github / stack overflow profile

Not everyone has a github or stackoverflow account!

> I have no idea why this isn't a more common practice

It used to just be “the practice”. The folks who don’t do this are trying to automate hiring.

> The folks who don’t do this are trying to automate hiring.

Or they are trying to emulate Google and similar companies without understanding why they do it.

I'm 15+ years of experience, I funded a few high level projects for corps and a few startups including hiring my teams. I was always conducting my interviews by making some work with the candidate and I found it best approach.

And quite recently I sat on another end of hiring table. I'm good at algorithmic challenges like letcode or hackerrank, I always liked puzzles like this. And yet, last interview I failed. Purely because I got a bit nervous and did not manage to deliver fully working solution in 15 minutes in front of interviewer. And that after passing their hackerranks and answering their general system questions. I guess their approach was all or nothing. Is it good or bad, I don't know. But from hearing their problems I knew their problems is something I eat for breakfast :)

This is great for small companies, but large companies are interested in standardizing the interview process. Leetcode is great for that since the outcome is pretty binary.

Sure, great for metrics, terrible for actually doing the job.

Leetcode can never compete with or allow a candidate to demonstrate real multi-dimensional or multi-systems thinking. You may be able to write some bass ackwards arcane algorithm and prove you’re “31337” but can you make that work at scale with a data store that you have no information about? How’s it going to get the data to operate on in the first place? Will your data retrieval query cripple a prod database? Read from replica? How far behind can that data be without making your fancy algorithm useless? How will you parallelize that work set? In-request or background job? Multi-threaded or single thread? What about changing state in multi threaded contexts? Database indexes? Schema design? How will you handle failures in your algorithm? How will you handle malformed data? And most importantly, does what you’re doing benefit the user, or just your epeen?

Leetcode is bullshit. It’ll never let somebody show you they’re good at anything other than solving bullshit problems. And you’ll lose everybody who CAN work within the larger context by chasing candidates who’s chief skill is solving bullshit problems.

Leetcode is a proxy IQ test. Anyone who can do leetcode can learn how database indexes work (hint: it uses Data Structures and Algorithms) but not the other way around.

I mean yes, it does filter for those that are willing to put up with some bullshit to get a job. But you haven't convinced me that the group that's unwilling to put up with this is unqualified.

There are many senior people or folks with families/etc that don't have the time or patience for this ridiculous cargo cult hazing ritual masquerading as a hiring technique.

I would say your assertion that "leetcode is a proxy for IQ" is a bold statement to make without some bold sources to back it up.

I've personally met a number of people that are great at these small scoped problems but suffer at broader systems engineering.

> the group that's unwilling to put up with this is unqualified

Companies that get a lot of applicants care more about false positives than false negatives. So they're fine not hiring a lot of qualified people, as long as there's a low chance of accidentally hiring an unqualified person. Apparently LeetCode-style problems work for that type of screening.

companies can win by hiring exceptional people with deep experience. the cost of not hiring these people has been unquantified. i would never want to be in their position. imagine a startup hires that one person who will make a billion dollar difference?

The startup isn't likely to be getting resumes on the scale that the big tech companies do and can afford to spend the time to look at each resume and maybe even do an interview with each candidate.

However, if you are getting resumes on the scale that the larger, well known tech companies do, then the individual attention cannot be paid on each resume. At that point, one looks more at a quick filter to try to remove the risky hires.

If you've got 1000 resumes and 80% of them are bad hires, and after an online assessment that takes it down to 200 resumes of which only 50% would prove to be bad hires, that is a significantly improved pool to consider.

Yes, it is possible that a great candidate was removed in that filter, but its also possible that one still remains in that pool.

Startups may be cargo cutting big tech interview processes, but the process has value for big tech companies and any others that have more resumes than they can reasonably deal with.

cost of living is driven by FAANG and startups use the same leetcode hiring process as FAANG, but pay less. the equity you get has a miniscule chance of becoming valuable.

It is true, most of the leetcode problems use the same underlying collection of approaches. If you don't know them (by memorizing them), you probably won't solve the problem. There is some value in knowledge of those approaches (algo and DS stuff), but these toy problems are not a good way to evaluate how someone would use then in a real life situation.

"95% of programming is data structures and algorithms" - it's just not. 95 percent of programming is gluing together libraries, refactoring code and reorganising what you have to solve new business requirements.

Your focus on performance (albeit important) above all else makes me question how much real world experience you have building large scale systems. (Unless you're a systems/embedded developer).

But this is the crux of the issue: using metrics that don't map well to what we're trying to optimize for. Perhaps your trying to optimize for finding great performance focused, low level software devs? If so that's different that my goal.

>can you make that work at scale with a data store that you have no information about? How’s it going to get the data to operate on in the first place? Will your data retrieval query cripple a prod database? Read from replica? How far behind can that data be without making your fancy algorithm useless? How will you parallelize that work set? In-request or background job? Multi-threaded or single thread? What about changing state in multi threaded contexts? Database indexes? Schema design? How will you handle failures in your algorithm? How will you handle malformed data? And most importantly, does what you’re doing benefit the user, or just your epeen?

Some of these questions are perfectly valid during LC coding rounds. Others would be more appropriate in a system design round.

Agreed, but I see the impulse to standardize as the source of a lot of the problems people have — by people, I mean both good engineers, and the companies who can't hire them.

Honest question, how would you handle hiring at FAANG scale without standard processes?

For reference we had an opening in my team and 1600 people applied.

This process still relied on screening, including technical screens. The biggest difference is that it substituted a day of whiteboard interviews with a day of pairing, which we found to produce better results, and candidates really liked too.

Apple used to have a per team interview process(don’t know if it has changed). While the interview experience can vary a lot, there are certain pockets/teams that are spectacularly brilliant and have the freedom to maintain the bar & conduct targeted hiring.

Having 1600 applicants for a SE role is not a unique, but definitely a very niche, problem to have...

go on linkedin and message the people you think can do the job based on prior work and experience or degrees. trash the rest.

sure, let's spend time solving Leetcode problems instead of understanding how HTTP works.

This!

> I have no idea why this isn't a more common practice

My maths teacher once said in class during lecture, "Kids, when you venture into the outside world, you will realise 'common-sense is not a common thing!'".

the goal of the leetcode interviews is to get into who is the smartest mode, so the cost of hiring can be driven down. those who conduct the interviews are unaware of this. the process you describe would result in paying people more which is not what FAANGs and those imitating them want.

This is exactly the right way to do it. Not only do you find out if the candidate can program, but how well they can pick up unfamiliar code, tools, etc, can they communicate, can they work with others, etc, etc, etc.

Leetcode bears little resemblance to everyday programming. Of course it's sometimes necessary to understand big-O, and that various data structures and algorithms exist, and which ones you might apply to certain problems, but coding them from scratch, from memory, within a fixed time? Pretty much never.

> but coding them from scratch, from memory, within a fixed time? Pretty much never

This is definitely true, but having to do it quickly and on-the-spot is one way of measuring just how comfortable you are with it. You might never have to do it in an hour, but being able to is a proxy, however weak and indirect, for your competence, and guess what, I only have an hour to talk to you.

I love and hate leetcode interviews. I enjoy the challenge, and I hate being put on the spot and knowing that poor performance on one specific problem might result in an unwarranted thumbs down. I sincerely hope any interviewer whose chair I'm sitting in treats them the way I do, which is that it isn't important that you come up with the optimal solution; it's important that you can think through the problem and come up with any solution, however inefficient, and then honestly evaluate this solution (including big O) and point out how it could be improved. You probably don't have time to implement that improvement, but you've demonstrated competence in both thinking and coding along the way.

Edit to add: When I'm preparing to interview, I practice leetcode-style problems, but not so much to memorize all the questions and their answers as much to just practice my quickness for thinking and coding on that type of thing. It feels kinda silly because, as you point out, that's pretty much not a part of the job at all, but it's very very helpful to exercise your mental muscles for that sort of thing so you don't stumble over the simple mechanics of the problem. It feels absolutely great when you get a question you've never heard before but you've put yourself in the mental state to solve it and you kill it. And like it or not, I've personally found that people who enjoy this type of challenge are often the exact types of coders I want to work with.

I don't agree it's a good indication of competence; leetcode skills are almost orthogonal to the skills required in general programming.

It might be different if you're being hired to develop a new video codec, or distributed consensus algorithm or whatever, but for the typical large web property or enterprise database, leetcode is all but irrelevant.

Code cleanliness, code communication, defensive programming, properly considering edge cases etc, flexibility, API UI design, and how other people interface to your code, etc, etc, all these things matter far more than advanced algorithms, which will rarely be required.

> I don't agree it's a good indication of competence

my statement was that it's "a proxy, however weak and indirect, for your competence"

If this interview process is so golden (based on your metrics of success) why isn’t every one doing it?

Not OP but here are a couple reasons:

* It doesn’t scale well to huge organisations.

* It’s not standardised “repeatable” in the sense that you cant generate datasets from this that let you correlate interviews with subsequent outcomes and improve hiring metrics company wide

* It requires expertise in pair programming, which most companies don’t have

Basically, OP’s hiring process is an excellent example of “doing things that don’t scale” to gain an asymmetric advantage as a small organisation.

They don’t need to derive metrics, they can invest the time, they have a team who are skilled at pair programming - so they can have this hiring process and other people can’t.

Brilliant.

I disagree with this take to an extent. Take it to the other extreme and you get folks who can’t even solve fizzbuzz. So some coding bar is good.

Leetcode is a very learnable skill, and I would argue any decent programmer can learn it well enough to pass an interview. I for years thought I wasn’t good at it, then I actually practiced and I got job offers at google and Facebook. I have also optimized code quite a few times using algorithm skills I picked up practicing for interviews so it’s not totally a waste.

There is a limit though, and some companies are pushing it with absurd questions that you couldn’t reasonably solve unless you had seen it before.

In summary, algorithms are useful and learnable, but some companies take it too far.

Here's the thing, large tech companies aren't looking to hire engineers, especially juniors, who are great at being an engineer because that's incredibly hard to test for in an interview and almost impossible to scale fairly. They're looking for people who will devote their life to the company and can quickly learn new skills. That's exactly what leetcode tests for, so it really isn't surprising at all that every tech company does leetcode interviews. Really the answer is either commit to the grind or go for a job at a non-tech company.

> They're looking for people who will devote their life to the company and can quickly learn new skills

This doesn't reflect my lived experience in SV. People I know who learned leetcode skills and got into big companies usually work less than people who passed more practical tests and get into smaller companies.

I'd say big companies are trying to hire employees who are a "good" mix of:

1. Smart

2. Conscientious / willing to work hard on the right things

3. Existing CS knowledge you know well enough to explain and apply.

For some vague handwavy definition of "good"

(2) is probably worth expanding a bit. Many people are willing to work very hard on the wrong thing, this extends to engineering. As an example, a common failure pattern you might see is someone constantly struggling with how React works and what they really need to do is sit down and read the ~15 pages of documentation. But they never do, and just keep putting in 10 hour days with subpar output.

I've met some legit geniuses (think Putnam winner) for whom basically no studying was required to pass these interviews. Companies paying top dollar are happy to have them. For people like who are less smart and need to dedicate ~100-200 hours of focused studying and practice, companies paying top dollar are happy to take our mix of smarts and willingness to do that work. But once in the company I haven't noticed any expectation to "devote my life" to it.

Right, I think you've explained it better than me. I was just going for the idea that the point of leetcode isn't to figure out if someone is currently a great engineer, but if they have what it takes to become one. Everyone complaining that leetcode isn't related to their day to day job is missing the point.

> an quickly learn new skills. That's exactly what leetcode tests for

I don’t know where people get this idea. Leetcode used to test programming proficiency

I feel the only reason companies continue to take leetcode to absurd levels is because (a) they think harder questions would get them better engineers and (b) other companies are doing it

> Leetcode used to test programming proficiency

The discussion is exactly this, that leetcode is used to test programming proficiency, but it's an inadequate bar.

The parent is postulating that it's a lie; that actually leetcode tests for malleability, and we're getting bent out of shape because we think it's a poor test of coding ability.

However it might be a good test of malleability, and that might actually be it's intended purpose, but that's not communicated.

I don't know about malleability, but I know Big Tech uses it to filter down the number of applicants. They get 200 applications in an hour so HR needs a way to pick a few that won't get them sued.

Understandable when big tech does this.

200 person tech companies are doing the same.

Not quite but almost: Leetcode doesn't evaluate programming proficiency but ability to solve complex and abstract problems using programming. Doing so doesn't require being good at programming but being good at solving problems, and doing so using a programming language. It doesn't require knowing a language well, but only well enough to solve the problem.

This is fine, except when the candidate knows substantially more than the interviewer about how to solve the problem. I was once asked to implement a spsc circular buffer, and I used C++11 atomics rather than a mutex. I wrote up a working solution, but most of the interviewer's followup questions fundamentally didn't map to my wait-free solution. I spent most of the time explaining to the interviewer how atomics and non-blocking algorithms work. The FAANG rejection email came a few days later.

So I don't think these interviews evaluate the candidate's ability to solve complex and abstract problems. They seem to evaluate the candidate's ability to grind contrived sophomore-level computer science homework. Experience solving the real-life version of the problem rather than the academic one is unwanted.

this illustrates the problem very well. your lock free solution is superior yet the interviewer had no clue and you only know about this solution due to experience which is not what leetcode optimizes for.

I've had zero or near zero gotcha string problems in my professional career, which are many of the leetcode problems.

Find the (gotcha) in this string and emit len(gotcha) ... Now do it computationally efficiently (or be able to explain tradeoffs to other resources).

String problems are rare, though may come up more in search engine companies.

But manipulating sequences comes up a lot in many contexts. Usually it's sequences of more complex things: instructions, packets, files, polygons. It's hard to assign tests directly on those, because you have to explain the objects themselves first. So it's a reasonable shortcut to test ability to manipulate sequences of characters.

Don't forget: in 45 min, without bugs

oh and do it in Go* ... Good F'ing Luck .

Go makes normal string operations tricky due to rune being an alias for int32, ranging a string gives []byte indexes ...

https://go.dev/play/p/33jCwNG6Eu6

It's a bit sucky but you can use the standard library function "utf8.DecodeRuneInString(a)".

> It doesn't require knowing a language well, but only well enough to solve the problem.

I guess that really depends on the language. IMHO, if you can solve a reasonably complex problem using a language, you know that language.

I am on the interview team for the company I work for and I wrote what some consider to be our canonical python solution (fastest and simplest) for one of the problems we use. I had to look up the syntax for a "for loop" because I hadn't written python since my first year at university. To me, being able to stitch together simple concepts present in almost all mainstream programming languages doesn't mean I know python, it means I know how dynamic programming works. I don't know the python ecosystem (history, present, or future), know the standard library, know what idiomatic code looks like, deeply understand what makes the language unique, have the mindset of a python programmer, etc. Maybe I just have a high threshold for feeling like I "know" a language.

i did a leetcode interview in c++ and didn’t remember some syntactic details of lambdas and that was the end of it. please stop with this nonsense that interviewers are understanding and that you can look things up or that you will be able to take your time to produce the optimal solution to a problem.

Well I can't speak for other interviewers especially at other organizations, but I try very hard to make it a positive experience. In fact I'll give as much help as necessary to get to a working solution, within reason. I would much rather fix the lambda syntax myself or help the candidate find an example on stackoverflow so we can go back to the interesting part. If the interview ends with a working solution but needed a ton of help, the candidate probably did not pass but maybe they learned something. And maybe they'll tell their peers that it seemed like a place where they could fail without embarrassment, collaborate, and learn.

This doesn't seem right at all. I can kludge together a solution to an arbitrarily complex problem in any language, but that doesn't mean I'm writing it in a way that can be extended and developed upon by other people. The latter is also what takes up the majority of development time.

A one-day interview can't test you on things that take up the majority of your career time.

As I understand it, programming is only part of it, a big part is just seeing if you will study hard to learn meaningless stuff

If they’re so interested I have a massive catalog of things that can fulfill such a requirement.

> Really the answer is either commit to the grind or go for a job at a non-tech company.

There is quite a world outside these mammoths Google/Facebook/Amazon/(MS, depending on how their IBMization is going these days) and their minions/wannabes. Personally I would not work for any of these even if they paid me in gold bars.

Off topic: what’s this IBMization at Microsoft?

Yup exactly, that’s the whole thing. They want people who will devote their lives to meaningless tasks

> devote their life

Sounds like they are trying to breed a cult...

More like, sounds like the parent comment you replied to has no idea what they are talking about.

I worked across a couple big tech companies mentioned in the thread, and I've met maybe a couple coworkers at most who "devoted their life to the company". And that's across almost a 3-digit number of people i worked with in some capacity over the years. People take vacations often, they work 40 hours a week or less on average (over the year).

One big thing about most teams at big tech companies (probably sans Amazon, from what i hear, haven't worked there myself) is the work/life balance being an important priority. We had a manager giving stern talks to the few teammates who would reply to work emails on their days off ("you left for a week of vacation in Hawaii, why are you replying to work emails or even brought your work laptop with you? Please stop doing that and enjoy your vacation, everything will be totally fine when you come back.").

I don't even care to defend any company, that's their problem. But seeing the whole "cultism" and "expected to dedicate your life to the employer" accusations just make me feel like I am reading some alternate timeline fiction story.

I didn't mean it in a "cultism" way at all. I was more saying that the point of leetcode isn't to discover if someone is a great engineer but to discover if they are capable of becoming one. Big tech figures if you're capable of becoming a great engineer you either already are due to experience or soon will be because they'll make you into one.

They've decided things like ability to devote time to a meaningless skill that is required to get the job, attention to detail, and problem solving skills are what is required to become a great engineer and see that letcode is a good way to test for those things at massive scale.

They are exaggerating but not all wrong. As hiring manager my job is not to train you for your next job. I'm hiring for productivity and that takes time. If you are going to jump ship before you "pay" back the company then I'd rather skip on you. There is no test but I want 2-3 years if you take 9 months or more to get going and I'd be foolish if I didn't want more.

Lots of programmers think they are 10x but few are. Even my best senior engineers took 2-3 months to settle in and contribute more than they take and juniors are bigger gamble.

The best proxy now is will you spend 1 hour on a simple set of tests, if not you are not serious or are shopping for counteroffers.

I appreciate the cynicism but isn't it more likely that they use it just because everybody uses it?

Yeah, it's clear these people have never hired for a company. I've sat in on a thousand hiring committees, helped design these processes, all that boring shit, and the idea that someone would say "let's do Leetcode challenges so that we select for people who are willing to subordinate their lives to our company" – presumably followed by a "mwahahaha!" – is fantasy, it's something out of a movie.

I mean, look, it sucks when you can't get a job. I've been there (when I briefly tried to escape programming for a different metier) and it's awful. But pretending that the entire outside world is a dark mass of malevolent forces arrayed against you.. well, it may be psychically necessary in some Freudian, Jungian sentence, to prevent ego death or whatever, but in the long run it's neither (a) true (obviously), and (b) nor is it going to do your mind and mindset any good.

> But pretending that the entire outside world is a dark mass of malevolent forces arrayed against you.. well, it may be psychically necessary in some Freudian, Jungian sentence, to prevent ego death or whatever, but in the long run it's neither (a) true (obviously), and (b) nor is it going to do your mind and mindset any good.

Maybe you can post this in the endless Russia threads posted here, which seem to have crowded out the endless China threads.

I guess what you're saying is that apprehension about the motives of of corporate executives is so irrational, it's akin to a psychological problem.

It is low of you to conflate the two. While both companies and russia pursue goals in somewhat pragmatic manner, the former aims to maximize profit while the latter aims to execute an entire nation and take their resources with calculated brutality (most war crimes committed were under direct orders).

> I guess what you're saying is that apprehension about the motives of of corporate executives is so irrational, it's akin to a psychological problem.

No, that wasn't what I was saying there, but coincidentally, yes, I would agree with that statement. For one, 'corporate' is a phenomenally lazy word used to invoke some mental image of besuited sociopathy, from a million children's movies and internet debates. In the real world, 'corporate executives' - human beings, mothers and fathers, working in management careers at (large) companies - are humans doing jobs, like any other humans doing jobs.

I've been involved (as an engineer) in C-level meetings with people like that, as well as worked alongside them in the same teams, and my experience - thoroughly unsurprisingly given what I said above - is that they are pretty ordinary human beings on the whole. I'm sure there are differences between companies in terms of their cultures or values, but that's company-specific and not discipline-specific or seniority-specific.

I get that your experience is that these are people who mete out decisions from on high, which affect you in sometimes-negative and always-unforeseen ways, and that makes you feel like a mediaeval peasant might have felt towards his feudal liege. And maybe it's helpful, from a cathartic standpoint, like I said above, to picture them as evil baddies from kids' movies. But no, the reality is more banal.

(Incidentally, I think those who worship company CEOs - and suchlike - are equally stupid, from the Elon bros to the HackerNews types who recite stories about startup founders as though they were superheroes. These people underestimate the role of chance and – in a way, very similarly to you – overattribute the differences between execs/founders vs regular workers to a proportionate difference in their inner essence [in their case, they think intelligence & industry; in your case, you think amorality]. Both are fantasies.)

At some point the metric becomes the goal itself.

Ie. Leetcode style programing is/was used to filter out engineers that couldn't program. And the problems themselves were relatively easy, reverse a tree, build and LRU (which is not trivial at all).

But then there is an army of prep information, and people are just optimizing for Leetcode style programing. Then companies have to raise the bar again, and keep asking even harder questions. ie. build LRU from scratch was considered hard, now it is just a 'medium' level.

It has taken to stupid levels, where it is not anymore a metric of 'is this person a good engineer', but more of a 'how much this person did prep'. i.e. it becomes a measure of effort and desperation, and not just sheer ability.

That's why you see so many stories, of engineers preping for leetcode only, getting in, and not being able to do their job and getting piped....

Also, personally, the best thing that I did to make me a better engineer was creating an app, a backend, and full service, with paying customers. That taught me much much more than spending months on leetcode ever did. Brushing up some CS concepts and Data Structures, and some coding, does help you to become a better engineer. But doing just that, it doesn't make you a truly useful engineer at all.

Exactly! 10 years ago, I was a strong proponent of leetcode style questions instead of using college GPAs to hire engineers.

It’s the ‘Cracking’ idea that has thrown this whole process off. People have started over optimising for the metric

And it may be worth observing that, as far as I know, this sort of thing is totally unique to programming. No other branch of engineering does it. I've certainly never had to do any unusual prep for an interview--though, admittedly, my handful of jobs since just out of grad school have all been through people I know.

> Take it to the other extreme and you get folks who can’t even solve fizzbuzz. So some coding bar is good.

Sounds like the epitome of a slippery slope, to be honest.

Some people are going to say FizzBuzz (or similar) are a good enough bar.

More people are going to say 2Sum is a good enough bar.

Even more people are going to say Longest Common Substring is a good enough bar.

{...}

And the cycle will continue, because people who will have been asked such things will (most of the time) feel like 1) they've been asked it before, so now they must ask it, 2) they can solve it and feel anyone can solve it (in theory this is fine but in practice, not everyone can solve a problem in 45 minutes that they've never seen or never fully solved before).

Which reminds me of when I was going to college and I frequently had professors or TA's say X problem from the problem set is an "easy" one. Well, yeah, you're the professor or TA (for a reason) and you're the one giving it, of course you'd know how to solve it and such.

> algorithms are useful and learnable, but some companies take it too far.

This is my take too. So I don’t see where the disagreement lies.

Except it’s not just some companies doing it. All companies paying over a certain threshold seem to be taking this to ridiculous levels.

And please do share your ideas for what people should do or what finally convinced you that you weren’t bad at this

> All companies paying over a certain threshold seem to be taking this to ridiculous levels.

They can afford it. And assuming they are a tech company, they need that in key roles. You cannot write things that scale without solid knowledge and intuition in designing and analyzing algorithms, something that can be learned and furthered through experience.

Now of course it's true that not every job in a larger tech company is like that, so there would be some room to adjust the interview based on the exact role. And there actually is. But overall, if you have a massive amount of people applying every week, why take chances, why not take someone from the pool who can demonstrate the skill and allow for some horizontal movement within the company, into a tech-heavier team?

> And please do share your ideas for what people should do or what finally convinced you that you weren’t bad at this

For me, back then, it was something that was fun for me. Part of why I got into computer science in the first place. I would be totally lying if I said I didn't study for the most relevant of my interviews, beyond what I would have done without them.

But I distinctly remember for example freshing up some graph algorithm skills not by doing leetcode examples (I don't think "leetcode" was already a thing back then), but by arbitrarily taking the Debian package database and do fun self-made exercises like: Let's find the largest strongly connected component in the debian package library, i.e. the largest set of packages where installing one will always install all of the others.

I work at a mid-large tech company ~5k engineers.

> You cannot write things that scale without solid knowledge and intuition in designing and analyzing algorithms, something that can be learned and furthered through experience.

The point is not whether people need to learn algorithms, they of course need to, but that Leetcode questions seem to test people’s ability to solve riddles more than their ability to design algorithms

Bingo – I've seen some of the interview requirements – like 20 mins to solve an LC medium, and you can only hit "Run" once so you have one shot...!?!?

Basically if you weren't already familiar with the question and knew the trick you're screwed.

Plus they're really blatant about it too – the recruiters will _actually tell_ you to practice LC, and to try again in 6mos/a year if you didn't make it this time!

> the recruiters will _actually tell_ you to practice LC,

Here they do this before you even take the interview for the first time

The recruiters actually email me all the leetcode prep material and tips

Exactly, even before the first interview, that’s what I’ve seen too

> The point is not whether people need to learn algorithms

No, I said design and analyze algorithms, which is a distinct skill from "learn algorithms" (although that certainly helps). And which is certainly very riddle-like.

To second this point, part of being a good programmer means picking up new skills quickly, and then applying them.

Leet code is very contrived. However, learning leet code, then applying it in an interview shows you have the aptitude to learn quickly.

> Leet code is very contrived. However, learning leet code, then applying it in an interview shows you have the aptitude to learn quickly.

I feel very strongly that this premise is flawed. It shows that you have aptitude for a very specific type of learning.

I lead an engineering org at a small startup. We teach our engineers to dive deeply into the customer value prop to find ways to deliver the simplest technical solution to their problem. You don't need leetcode skills when you can identify simpler, more accessible solutions to a customer's need.

The reality is outside of very specialized technical businesses (or business components), most engineers jobs are not to build technically advanced solutions.

I agree. We lost two of our worst performers to FAANG companies. They were both junior and came from top schools. Communication was a huge problem and both wrote very sloppy code. We would assign trivial tasks to them that would take an average developer 30 minutes or less and they would struggle even with heavy mentoring. I was the mentor for one of them and I really tried my best, but there was little improvement over several months and luckily they moved on.

Now I'm mentoring two devs who didn't study CS in college and only completed a coding bootcamp and they're working out amazing.

Yup this is a pattern I’ve seen as well and why I think Leetcode is on the way out. People will figure this out

Yes, exactly this. Leetcode isn't just an irrelevant skill in these situations, it's the wrong skill. Algorithmic optimisations are pointless if you can't assess how much value they generate.

MAANG seems to use Leetcode as a legal proxy for conscientiousness and IQ without testing for other relevant qualities such as strategic insight, creativity, and other skills that are essential for a successful business.

There's no problem with testing for basic coding ability, but if you're not selecting for broader skills - preferably with some diversity - you get the same old leet monoculture causing the same familiar delivery and stability issues.

I think this style of interviewing also serves as a proxy for age discrimination and/or to detect personal work/life balance values that don't favor the prospective employer.

If you aren't willing to dedicate a considerable part of your unpaid, personal time to an activity that they mandate, you aren't a good fit for them.

This argument can be used to justify forcing candidates to learn how to do double-entry bookkeeping (or insert other skill that you won't use on the job) just to see if they can learn. Yes, it checks if they can learn, yes, it is somewhat related to the area, but maybe there's a better way?

I've been 10 years in the industry. If recruiter tells me I need to prepare for an interview in ways other than looking back at the projects I've done, then the interview is not testing for what is important on the job.

> I've been 10 years in the industry. If recruiter tells me I need to prepare for an interview in ways other than looking back at the projects I've done, then the interview is not testing for what is important on the job.

Some people lie on their resumés.

If they're good at lying in person, it can be difficult to detect that.

If they're able to deliver working code of some kind under the pressure of a job interview, then they're almost certainly about to actually program at least a little, so you can trust me of what you see in their background and what they tell you about their achievements.

I'm personally skeptical that leetcode really tests what most companies need in a programmer, but it's probably better than nothing.

> Some people lie on their resumés.

My point isn't that I want to only chat about my resume - just that the problem you give me should be something I may encounter in the new job, ergo I do not need to prepare for that since my entire career prepared me for those (unless I want to reskill and the new job is different than the old one, then some preparation may be warranted).

> If they're able to deliver working code of some kind under the pressure of a job interview, then they're almost certainly about to actually program at least a little, so you can trust me of what you see in their background and what they tell you about their achievements.

Sure! But if the assignment is depending on stumbling upon a brilliant idea, instead of solving a problem that you may see in your day-to-day job, then I don't think it's useful. Think "trim a string" or "split a CSV" [1], not "find the longest increasing subsequence". And maybe also explicitly stick to ASCII encoding for string-based problems (but TBH, if a candidate asks about encoding, they probably know their stuff, or at least know where the gotchas are)...

> I'm personally skeptical that leetcode really tests what most companies need in a programmer, but it's probably better than nothing.

Agree that it's better than nothing. Disagree that we can't do better. :)

Edit: [1] ... maybe w/o relying too much on standard library if those are built into the language you chose.

Yep, that all makes sense.

FWIW, I agree we can do better than leetcode.

I'm personally a fan of an approach I saw someone else describe here, where you literally have the candidate do a few-hours freelance gig for you, paid at a decent rate. Triage some of the low-priority bugs so when you're interviewing you have a little stack of relatively self-contained, well-defined tasks for candidates to pick from. Probably good to have someone pair with them, if the candidate is willing.

You get to see them work in a real context, they get paid, you can learn about how they work, and it seems like a win-win to me.

I also think it's good to be open to other options - if a candidate has a different way to show they'll be good at the job, let them do that. If burntsushi wanted to work on a company's CLI tools, I'd hope a link to the rg repo would satisfy everyone that he knows how to write a good CLI.

> However, learning leet code, then applying it in an interview shows you have the aptitude to learn quickly.

That’s not why they were introduced. Leetcode using tools like hackerrank were introduced because college GPAs were very bad indicators of programming proficiency and a lot of people also did not have a CS degree.

The questions weren’t this bad before.

And these competitive programmers aren’t necessarily fast at learning things either.

leetcode was introduced because the founder in india could not get a job because he didn’t have a degree. so he made a platform where people could prove how good they were.

the trouble is that this just trains code monkeys to memorize optimal solutions to a set of problems and to quickly reproduce them.

it does not optimize for real engineers who have the experience to build good software and to come up with creative solutions to hard problems.

It also shows you have the time to prepare. Not everyone has that luxury - think working parents with some other challenging happenings thrown in and you have an advantaged and disadvantaged class of people for these interviews

The cynic in me says that's intentional. They want young, enthusiastic people willing to work for less that they can throw away when they're done.

It's more than cynical: https://www.britannica.com/event/Griggs-v-Duke-Power-Co outlines that IQ tests are unconstitutional due to racial biases.

It was out of that judgement, that companies started to require degrees for office jobs of all sorts, as you could discriminate based on education but couldn't on an arbitrary IQ test. And naturally, tests on the topic of a job can also be administered.

And I do think you're right - Leetcode does select for recent graduates who likely were taught in a throwaway language for academic purposes. And selecting for young college graduates are highly likely what they're searching for, as they also do not know their worth.

I had a 3 and 2 year old when I prepared for interviews and I did alright enough to get a job at a FAANG (and it's not Amazon). I took about 2 months and blocked some time every single day. I still managed to cook meals for 4 and put two kids to bed, and wake up at 1am and 3am for night time milk feedings... yes that's not delegated to a housewife it's done by me.

Glad that worked out for you. After a day of watching my now 1.5 year old the brain fog sets in. I tried grinding Leetcode for a while but the pace of progress was glacial and nowhere near the recommended pace for BigCo interviews. I'm glad I went back to doing my own thing even though nothing has come of it yet. Doing Leetcode felt like memorizing party tricks that wouldn't even guarantee a job at the end.

Honestly, do you want a BigCo job? Would it make you happy? The experience of being a tiny cog in an unthinkingly vast machine is more alienating than you might think, even if you like the money.

I think lots of those who stay on long-term in that environment, say >3-4 years, effectively become institutionalised, condemned to spend the rest of their life philosophising about whether they can ever be L8 material. These are people who are, by and large, smart but not wise. Yes, the money is good, for an employee, but it barely equals what even a small business owner could make - and these are people whose smarts would allow them to thrive in the software niche, at least with a minimal amount of commercial nous.

The truth is that FAANG (or FAAG, considering what's going on at Netflix?) keeps these people there by creating a value system. If you've ever read the internet-classic 'Five Geek Social Fallacies' post (https://plausiblydeniable.com/five-geek-social-fallacies/), you'll know that people like us - frankly - are suckers for taxonomy. If you tell them that they are the best because they work for you, and the only thing that can make them any better as an engineer is creating maximum returns for the Borg, and surround them with others who mirror and validate that behaviour, they will fall for it for the rest of their lives.

Don't fall for it. There are a fuck ton of smart people at FAANG companies – that's one of the few marketing points which is unvitiated in its merit, they do scoop up very many of the smartest (again, smart-not-wise) people in the world – but that doesn't mean the only way to be smart is to join. It doesn't mean you - as a unique human being - will be happy there. Carve your own path, be suspicious of people selling you axiologies and hierarchies, find a middle road between excessive cynicism and excessive credulity.

It's something I consider every couple of years. But unfortunately I see a lot of similarities in the hiring process for much smaller interesting companies hiring remotely that seem to be cargo culting BigCo hiring practices. BigCo from my example were just the only ones to be open enough about what will occur during interviews. Is it something fulfilling? Probably not, but I have 5 years of practically unpaid work to get caught up on.

What exactly did you do during that block of time? As someone in a similar situation to you I'd like to begin getting some practice, but I'm not sure where to start. Are there any resources or websites that stood out as being particularly helpful?

Naturally, but how is that a flaw?

I recently went through a round of interviews at big tech companies, and I found that the coding questions were less stressful than I was initially worried about. Leetcode problems are fair, and it just isn't true that you need to know the trick to pass. It allowed me to get in the door at a company I would have had no chance with otherwise (no CS degree, no top school, small no-name companies, etc)

System design on the other hand... that can be hard to prep for!

The reason companies provide so much info upfront, and even send candidates to leetcode.com, is so that everyone knows what to expect. Not everyone is on HN or is even aware of these types of interviewing trends.

Woodworking is also a learnable skill that's completely unrelated to on-the-job activity.

Why not ask candidates to build a desk? As a take-home project! If you're truly kind, you'll let them keep the desk even if they don't get the job.

The algorithm test is standardized. If you make up your own weird test, candidates won’t play ball. Personally I’ve turned down companies that had a strange interview process that required extra preparation. It’s not worth it when I’m trying to churn through a dozen interviews (without my current employer noticing). The leetcode prep process is unpleasant, but since I have to do it anyway, adding one more company doesn’t take any extra studying.

Go work in an industry. Any industry that isn't IT, I suggest manufacturing and raw resource industries like farming and mining. After a year and you get your head around what's going on automate some of their business process or collaborate some some of their data into a form that's easier to interpret.

Sell back to your employer or their competitor. Congrats you've just started your career in coding and you didn't do a single whiteboard riddle I interview. Also your doing real work for real people and making actual differences in day to day lives. Not just some faang companies pleb work, bleeding metrics from the masses.

You’ve also built a mental model of how large systems interface that takes years to acquire from the other direction.

this is actually our company/startup for the ChemE type companies.

it is just hard to find software/data science people interested in manufacturing/engineering

Yep, get in through the backdoor.

this is good advice.

Much better advice than “get used to ‘em” as alternatives to the status quo do in fact exist.

My advice is to get good at leetcode "the right way". Don't memorize problems. Instead, learn the underlying algorithms.

Learn heapsort, quicksort, how to find medians, how to derandomize and calculate the running time of the quicksort/median algorithms.

Learn how hash tables, red-black trees, and b trees work. Learn why vectors allow O(1) append but only if you amortize the analysis.

Learn depth-first and breadth-first search, learn A*, learn all-pairs-shortest-paths. Learn enough dynamic programming that you could implement a memoize decorator.

All of this is valuable knowledge. It'll pay off to learn this in the long run. Yeah, interviews overrate its importance. It's good to learn it anyway. If you learn that stuff and you are good at the basics of practical programming like string and array manipulation, you'll be able to do well at interviews.

As much as I agree with your advice in general my interviewing experience is completely the opposite. To begin with reading algo books/being aware of the topics you mentioned doesn't necessarily translate to solving leetcode _puzzles_. The last time they simply asked me to implement quicksort was almost ten years ago. What is even worse, usually you have about 30 minutes to solve a puzzle. You won't have time to think even if you are capable of thinking under such circumstances.

Where I completely disagree with the original statement is that leetcoding hurts mostly experienced developers. What else are fresh graduates supposed to know well if not algorithms and data structures? Experienced developers are from generations when few people majored in CS and spent formative years interviewing long before anyone heard about leetcode. And they have too much experience with building real software to tolerate artificial puzzles.

I won't argue that being able to apply different patterns to problems is incredibly useful, but a lot of these are also fairly domain-specific. It really depends on what your typical work is like.

I've worked on teams that dealt with messaging queues and associated backend systems. In those cases it was rare, if ever needed at all, to see or use any kind of graph searching algorithms.

Sometimes some forms of memoization were helpful when it came to system issues that required a meaningful but efficient backfilling strategy. But they were almost never in the same form that typical DP interview problems are.

I would argue many of these patterns can be helpful to test candidates with but only depending on what roles they're interviewing for.

I've seen more "trivial" problems that test for the same kinds of answers that interviewers usually want anyway.

Usually the messaging is something like "we want to test that you can write code. We want to test that you can iterate over and consume/aggregate some data. We want to test that you can evaluate this codes performance." You can do all those things with simpler classes of problems than some of the brain teasers I've seen. And I don't mean the usual stuff like how many tennis balls fit in a school bus, but leetcode style, overly complex problems.

>Learn heapsort, quicksort, how to find medians, how to derandomize and calculate the running time of the quicksort/median algorithms.

i've done around 800 leets and never had to learn any of these.

you can do a whole bunch of leets if you just learn the following and fill the gaps along the way

1. data structures: tries, maps, lists, heaps/priorityques, stack, dequeue.

2. graph: shortest paths, dfs, bfs, cycle detection, topological sorting, union find.

3. binary search

After all this knowledge you still won't be able to solve "Next Permutation" or "Integer to Words" or "LFU Cache" within a 45 min Interview if you haven't seen the problem before or never practiced enough leetcode for it to become subconscious and automatic.

If you learn all this and you can't solve LFU cache in 45 minutes, go back and study the parts about heapsort, red-black trees, and B trees.

If you learn all this and you can't solve "integer to words", go back and do some more practical programming. Build your own blog in Django or something.

If you learn all this and you can't solve "next permutation", well, yeah sometimes interviews ask you dumb theoretical stuff that you will never use in real life. Them's the breaks.

Let’s not forget the emotional element of these interviews where you’re being asked questions that mean very little about whether you can perform in the role. but many pretend that they are. For me the day long “technical” interview loop is a flashback to gradeshool hell. It tests my anxiety levels at least 5x more than my skillset.

It’s a common thought among my circles that interviewing is the hardest part of being a software engineer - once you’re in somewhere it’s a lot easier.

There needs to be something better.

It's often the hardest part because many people think they can hit the ground running after following a Udemy programming course.

Engineers are expensive to start with and inexperienced/over-confident engineers even more so due to the potential damage on the product.

Tough interview stages like leetcode are a simple method HR can employ to establish a baseline competence.

Personally I have zero interest in grinding for months solving riddles and when interviewing I always check what the stages involved are. On numerous occasions leetcode has been dropped upon request - no harm in asking!

> It’s a common thought among my circles that interviewing is the hardest part of being a software engineer - once you’re in somewhere it’s a lot easier

I’ve heard a similar sentiment from my circles too. But lately

I’ve also met people for whom it’s the exact opposite: they can clear the first round of the interview and they fail in the subsequent design rounds (which in my opinion are a lot less challenging)

I’ve also met people who manage to get hired but are soon overwhelmed with the real work that they have to do and some even get pip’d

| It tests my anxiety levels at least 5x more than my skillset.

I'm not so convinced that these are two distinct things. I want coworkers who can maintain their level of skill under extremely hostile, stressful conditions. I'm not going impose those conditions on them, but I can't necessarily control the myriad third parties or circumstances that might.

I am not particularly good at competitive programming, but at some point I did invest quite some time into it. Contrary to my username I have a pretty decent memory and I can remember easily if I've solved something similar.

At some point I've interviewed for a company who gave me four exercises to solve in an hour. Normally, it would've been impossible to solve them without previous knowledge. Funny part is that I knew the idea for all 4 and the only difficulty was to write things quick enough so I can finish everything in time. 57 minutes later, I was finishing all of them, to the surprise of the interviewers who were watching me coding.

I had the all time best score for that company, and everyone thought of me I am some kind of genius, which was certainly not true, because I know my limits, and I am far from it.

Nevertheless, everyone was a little disappointed by me in the next 6 months. I was quite junior, and had junior problems.

I haven't done whiteboard coding interviews for a long time, but this was a problem back when we did. We started by using generic coding problems that someone got from somewhere (probably a popular book or website). Occasionally someone would show up and basically recite the solution from memory.

Having 4 different problems is usually an okay defense for this because you can spot when the candidate recites some answers from memory but then struggles through relatively easy questions they obviously haven't solved before.

The fact that you had all 4 memorized defeated that heuristic, of course. The smart companies are careful to rotate their problems and customize them in ways that will trip up most recited answers.

> I had the all time best score for that company, and everyone thought of me I am some kind of genius, which was certainly not true, because I know my limits, and I am far from it.

> Nevertheless, everyone was a little disappointed by me in the next 6 months. I was quite junior, and had junior problems.

I mentored college students and recent grads for a while. A lot of them had been convinced by the internet that they just needed to memorize enough LeetCode problems to squeak through a FAANG interview and then they could relax for a decade or too until early retirement. It was like all of the Reddit memes about CS careers collapsed into a single narrative.

I spent a lot of time reminding them that high paying companies have high expectations and it's not as simple as collecting $300K/year to do nothing. Of course, they didn't really want to hear it from me.

There was a Google talk some years ago that brought up this same idea with regards to people who did programming contests: https://m.youtube.com/watch?time_continue=51&v=DdmyUZCl75s&f...

You make the assumption that Google cares about their false negative rate when ranking candidates, ie not hiring somebody they should have hired. The process is optimized for minimizing the false positive rate, ie hiring somebody they shouldn't have hired.

I don’t care that Google is doing this.

It’s a problem that everybody else is using the same process. (I blame it on CtCi)

I've started ignoring companies that hire using leetcode or whiteboard algorithm questions.

Even if you make it through the interview process, you're going to be working for people who cargo cult their business practices and surrounded by coworkers who are willing to spend vast amounts of energy on stupid things to accomplish their goals.

It's a massively negative indicator for company culture imo.

I can't remember the last time I actually enjoyed using Google's software or their libraries, I don't know why I'd work for a mini-Google.

100% Leetcode is now a great metric for me on company culture.

Is your company able to back the trend when it’s obviously wrong?

I agree, but in general I've found if you want FAANG cash, it's better to just be good at leetcode and deal with it.

I prefer money over perfect culture though.

Right, all the most valuable tech companies in the world have hiring practices that are "obviously wrong." I'm not saying they got so valuable because they're using this style of interview, but if it were so incredibly ineffective, how would they have become so successful?

Because this hiring process came _after_ they were already successful?

Yeah they didn't start this way, with the exception of Google, its a recent invention... and now a cargo cult sped on by comments like this

one thing tons of people don't understand is that interviews are two way streets. companies are getting to know you, but you are also getting to know the company.

as you said, i would never work at a company with bad interviewing practices because it means that either the employees were hired by these bad practices OR the practices changed and no one cares.

what does "cargo cult their business" mean?

Copying the whole 5-7 interviews thing with leetcode stuff because FAANMG does it

No that's not true, the vast majority of companies/positions do not do this.

Most companies that pay very well and are competitive do it, and the reason is because we get so many crappy applicants that it remains to this day the least risky, cost effective way to filter out bad developers.

Sorry but there’s a lot of ways to filter devs, you would need to back this up with data.

Here’s another avenue, show me your OSS work if you have it. That give me a far better picture of how you develop than LC ever could. Don’t have OSS, then a take home test also works perfectly fine or a programming exercise that’s realistic

There are not many that are as cost effective and scalable for the number of applicants that a tech company can get.

> Here’s another avenue, show me your OSS work if you have it.

For the complaining elsewhere in this thread about how leetcode filters for people who have free time to work on it and thus selects for upper middle class... this is even worse in that regard. Furthermore, the contributions of a new grad are... often "poor".

The take-home test is similarly derided in many circles that refuse to do leetcode and the "write this program" is even less transferable to doing interviews at other companies.

With OSS you're at least coming out with a product that is useful to the ecosystem and you can show off for the rest of your career. It'll take you about as long as the LC nonsense does.

You think you have more data than all these companies who are worth Trillions of $$$ because they actually hired smart engineers?

I've also worked for companies worth billions of dollars that had tons of really smart engineers and didn't do LC. Its a cargo cult at this point, plain and simple. Google made it cool, now other people have jumped on, not because they have data but because they want to be like Google

Blaming it on CTCI is like blaming it on needle manufacturers for people shooting up with heroin. The issue is more fundamental. CTCI is just giving a methodology for people to get through the interview process.

The issue is that SV cargo cults extremely hard. A lot of startups copy the big companies (and often the founders of small companies are from big companies - so they take what they know with them). Then everyone is like, "SV is so cool and full of money! Let's copy everything they do to emulate their success."

That's all it is. I'm not a fan of the author (for personal reasons) of CTCI but I don't think she or the existence of the book is the issue.

Microsoft was one of the first big tech companies to popularize these styles of white board coding interviews. Back when I was in college, Google had just lowered their hiring bar from "must have PhD" to "well BS from an Ivy League may be good enough", CTCI was seen as a way into Amazon and Microsoft.

I’m not seeing everyone else doing it. I wish they were because I prefer those interviews over something that pretends to emulate real work. I want every company I interview with to do leetcode and most of them don’t.

Just went through a round of interviews in the past 6 months (~20 phone screens, 6 in person loops, 3 offers). Not all of the companies do it. If you don't like the process, then politely decline the interview. (you probably don't want to work there anyways).

The worse to me are the interviews that ask you technology specific commands (for ops positions, especially k8s) and/or specific language constructs.

Come on, there's enough, far more than enough, out there which is not like this.. just change your expectations.

if that's the case, it doesn't explain why Google's software and product quality has been declining steadily.

[Disclaimer: Two-time Googler here, obviously speaking only for myself.]

Sure it does. Collaborative software development is a low-pass filter, not a high-pass one. If you put 100 people on a team and tell them to develop a product, the product quality will track the least controversial ideas, not the best. With more people, the set of uncontroversial ideas gets progressively smaller, and trends toward the features that nobody really cares about because those are the only ones that don't provoke strong emotional reactions. The simple fact that you added more people is what made the product shitty, not that the people were incompetent or poorly-skilled.

I've been in design discussions where we've had a room full of incredibly accomplished people, folks who've written major open-source projects or launched consumer products with billions of users, and the eventual decision was more brain-dead than anything that any one individual in that room could've come up with. And everybody knew it too, but you don't want to piss off highly intelligent and accomplished people, so you make the decision that everyone can kinda live with rather than the one that will wow users.

The lesson here should be "Don't hire unless you absolutely need to", not "Google hires stupid people."

Surely this is a consequence of management and corporate ideology, rather than a natural outcome of having some arbitrary number of devs in a room. A good project manager doesn't allow great ideas to die on the vine unless there is pressure to do so, and that pressure is not coming from the team or customers -- it's coming from the top of the company.

For all of his and Apple's faults, Jobs aggressively fostered a culture of "good is the enemy of perfect," which placed the focus on polished features instead of the dull hum of incremental development. And that bucking of homogenization is what led to such a rabid base of loyalists, as consumers tuned in to that momentum of (albeit perceived) innovation.

Google, on the other hand, has never really had a fan base to speak of, and the few remaining loyalists are rapidly disappearing. I genuinely have never met a consumer or dev who believes Google is at the bleeding edge of any feature. That is wholly reflective of Page and Brin's ideologies, who fostered a culture of "over-engineer, refactor and ship incomplete," which is exactly what you're describing. Angular, for example, is the perfect representation of the Page/Brin ideology, and that's why nobody uses it.

It's the rule. Steve Jobs is the exception.

HP, IBM, Cisco, Sun, Netscape, Google - they were all visionary when they were small and bloated and inefficient once they got big. Apple too - do you remember the late 80s and early 90s, when Apple had a zillion PowerMac models, plans for Copland that never shipped, multiple new programming languages, the Newton, and basically a lot of ideas but shitty execution?

Steve Jobs basically managed to rein it in by being an asshole - he had both the product taste to be right, the charisma to convince everyone else of it, and the insensitivity to not care whose feelings he hurt. Elon Musk is similar. But note that the flip side of this is often a crisis of succession: IMHO Apple really hasn't been that visionary or helpful since Jobs died, and have basically pushed out a series of incremental improvements.

Yeah this is so true, I’m experiencing this at my current org. Does anyone have advice on how to avoid these pitfalls?

Don't put 100 people in a room. Put 4 or 5 in a room max.

You need a feedback loop to sanity check features some how, but you also need vision and the courage to release stuff that not everybody wants. Every good product I've worked on has had team members who thought the newest features were stupid. Too bad, you aren't the target audience, get over it.

Accept that you'll be releasing features that are either wildly liked or hated. You are going to be hitting both ends of the bell curve more often this way, embrace and accept it.

Put some potential users of the product in the room. Show them mockups. Iterate. Get user feedback. Repeat.

> if that's the case, it doesn't explain why Google's software and product quality has been declining steadily.

Why do you assume that poor products are poor products chiefly because of code?

The discussion here isn't about code. It's about quality of engineers hired. If their software and product quality is steadily declining then that says something about their team. Perhaps they are incredible coders but don't have good business skills or "customer obsession".

> If their software and product quality is steadily declining then that says something about their team.

My understanding is that Google internal politics are completely dominated by their promotion process [1]. I view the outcome of google products not as the result of poor hires, but the inevitable consequence of the organization's incentive structure. If pay (doubling or tripling) is dependent on launching new stuff, your best people will ship new stuff! If pay does not go up for maintaining old stuff, it will not be maintained. If pay does not go up for improving old products, old products will not be fixed. It doesn't matter which people you plug into that system, you will always get the same results.

1. https://news.ycombinator.com/item?id=31262428

That's not a valid metric. Every effective monopoly has a climbing stock price while it's product quality is declining, this is why they have such a terrible time when there's finally a market upset, they can have decades of bad practices to overcome just to stop their descent.

Come on! Showing 4 more ads per video on YouTube would boost their stock price while making me hate YouTube PMs even more

having worked there they had a decently high false positive since the hiring bar wasn’t consistent. workers choose what questions they want to ask. seen some onsite loops have two seperate dp questions while others have “design tic tac toe” and 2 sum.

plus a lot just blindly memorize thousands of leetcode answers but aren’t great coders.

I know leetcode hate is a popular theme on this website but frankly I think it’s overblown. You can basically solve any leetcode easy or medium if you understand like ten basic concepts (that you should know anyway) and then spend maybe a week reading solutions for the more trick questions. Leetcode hards require more memorization, but honestly, if we’re going to talk about pointless studying take a look sometime at what med school and law school students have to do.

In perspective, is 3-4 months of studying to get a job really that big of a problem? I spent longer than that studying for the SATs.

I think the hate isn't for the 3-4 months of studying to get your first job, it's the sense that you'll need at least 1-2 months of studying to get every subsequent job (since you won't be touching leetcode-like problems in the course of your actual job). That's not a big deal when you're young, single, and childless, but it's overwhelming if you don't have a lot of free time.

> it's the sense that you'll need at least 1-2 months of studying to get every subsequent job

I think it doesn't have to be this way if you focus on the fundamentals when you prepare, as it's easier to refresh a reasoning that clicked the first time than a complex algorithm you understood only superficially. And these fundamentals are enough for leetcode problems of medium difficulty.

2 months of studying every 2 years for job switch is 8.3% overhead. Do leetcode jobs pay 8.3% more after-tax than non-leetcode jobs?

Probably more like 100% more tbh.

Yup, 200k -> 400k, sounds about right

So I guess try to get your first LC job before your personal life gets demanding, then hold on to that job for dear life so you don’t have to grind LC again?

This is a decent strategy, I approve.

Is this the norm in the US/SV?

Very skeptical of someone who switches every 2 years... you also become only really efficient after 6 - 18 months.. not only the code / legacy / wider system your stuff integrates with, but also socially knowing all the right people, context of all the bigger processes, a good chunk of domain knowledge ingrained??

People under 35 change on average every 20 months in the US. People who are focused on salary and career achievement. There are a lot of people who get a job and blank out on cruise control and wake up 10-15 years later and wonder why everyone else is making more than them. But the talented people are usually switching every 2-3 years. It's not uncommon for someone to spend an extra year at a company to have a child, plan a marriage.

It’s quite common among the Silicon Valley scene during the tech boom. People bouncing between startups or even between FAANG level opportunities. Switching companies annually even (though not for many successive years).

Sometimes it’s not the worst strategy as the hidden truths of a startup reveal themselves over the course of a year or two.

It's surprisingly common, and a great way to filter out candidates if they have a history of job hoping.

Your math is wrong. People aren't literally doing LC for 2 months straight without eating or sleeping. If we assume it means you study for 2 hours a day that's only an overhead of 0.7%. I still think that's an overestimation of the time you would actually need.

> (since you won't be touching leetcode-like problems in the course of your actual job)

That is not universally true.

YMMV. I studied zero hours for the SAT and did well. There are honestly no hard questions, just a lot of them in a short time.

I have studied at least a hundred hours for leetcode and I still have never passed an interview at a well paying company. Leetcode hards are legit hard.

I'd love leetcode-type tests if you only had to do it once. Or even with a smaller every-five-years refresher to retain certification or whatever. And then not worry about it at all during interviews.

Yeah people in India/China spend 2-3 years grinding complex maths/physics puzzles just to get into a college and Americans can't put in a few hundred hours of hardwork to get a high paying job. It's probably lack of rigour in American schooling system that's behind this entitled mindset.

A lot of those people in India and China commit suicide, have mental breakdowns, or end up living generally unsatisfying lives. Their system is entirely unenviable.

There's a difference between 'entitlement' and recognizing that a system is flawed such that it doesn't necessarily select for the best candidates, only those who are willing to play the game hardest, which doesn't necessarily correlate with the best on the job performance.

The zero sum burnout games many Chinese and Indian students play are also a good example of such a system, and I think it's a positive feature of American culture that it's objected to.

OP here.

I’m in India. People spend 2-3 years grinding leetcode questions too. So you can imagine how difficult the tests have become over the past few years and how pointless this whole test is.

If the grinding is not going to translate into a business advantage, then it is pointless.

You are right. The problem is not solving the question, but solving it in 15 minutes with the optimal algo/data structure. Practicing can easily get you there. Also. In the grand scheme of things it's nothing compared to the job/comp bump.

SATs are also a very bad way of evaluating anything meaningful

They're useful as a second piece of evidence if, like me, you did poorly at classwork because of undiagnosed ADHD.

The flip side is that a DS&A toy problem grind is an actionable item that approximately anyone who can already bear the cost of their own training can work on, with legible indicators of their progress.

I know it's popular to throw shade on interviewing for "wasting" candidates' time on this instead of "learning to build actual things", but even if DS&A toy problems aren't the best-correlated with actual work performance, the fact is that (a) they're well-enough correlated, by the standards of scalable interview assessments (b) contrary to popular belief around these parts, presenting "actual things" is much easier to bullshit your way through than a few hours of talking through toy problems (c) every job opening gets a deluge of bullshitters.

You do realise that these leetcode rounds are virtual and there are “agencies” on the internet that would take this test up for you?

When I interview people, I have to make sure that the person actually wrote the code by asking some arbitrary questions about it in a subsequent rounds

We’ve had cases where people committing this fraud did manage to slip through the cracks but thankfully here it’s very easy to fire people once we found out.

I think learning to excel at algorithm interviews will make you a better engineer. It's not memorizing questions, it's learning to solve a variety of interesting problems you seldom get in your day today. You may think, if "I don't get those problems day to day, why learn to solve them?". This is similar to an airline pilot saying "Engines work well on my flights; why should I learn how to handle engine failures?"

2-3 months of devoted effort on algorithm interviews has given me some of the best ROI / time for engineering growth I've had in my career.

It's more akin to expecting the pilot to know how to replace a wiring harness in the avionics bay; someone else handles it and they'll never need it in practice.

I guess you just swear off ever doing an algorithms problem? This doesn’t seem comparable at all - there are feasible circumstances where you need to know this stuff.

> I guess you just swear off ever doing an algorithms problem?

I swear off memorizing the answers to them. If I run into a problem that requires a leetcode-style solution, I'll find many available bits of information to help me solve it.

My advice? Start memorizing the riddles.

Consulting jobs require case interviews - they're pale imitations of actual projects that translate loosely at best. And every company uses them.

Trading jobs ask probability questions - they're idealized versions of what traders do all day, requiring tangential (at best) skills like mental math and memorizing niche formulae. And (almost) every trading firm will ask them.

Tech jobs ask leetcode questions - they're vaguely correlated with tech skills (you can't learn leetcode without learning to program, I guess?). And (nearly) every company asks them.

All of these industries put up somewhat-arbitrary filters just to get a manageable signal, however imprecise, on the endless morass of new grads trying to break in. They ask them because they work: the pool of candidates who pass them are of a higher average quality than the pool who fail.

They're biased, arbitrary, and often quite silly. And they've persisted for a half century. Get used to 'em.

> Get used to 'em.

No.

I’ve spent the last year or so reinventing the hiring process at my tech company to expressly avoid algorithmic puzzles and leetcode nonsense, and I was able to do this because I patently refused to accept the status quo.

You can do this too. Anyone can. I’m basically a moron and I managed to convince our talent team to radically change how we do things; if I can do it I feel like the bar is pretty damn low.

The only real requirement is that enough of us simply refuse to accept how things are today. Right now is a fantastic time for the tech industry to adopt change because your talent recruiters are probably struggling to find and retain new developers and are almost certainly willing to listen to suggestions on how to stand out.

> I’ve spent the last year or so reinventing the hiring process at my tech company to expressly avoid algorithmic puzzles and leetcode nonsense, and I was able to do this because I patently refused to accept the status quo.

I think companies that break out of the leetcode habit are going to do well. There's a lot of great talent out there that's being passed over by these tests.

If the job is to solve leetcode problems, by all means, test the candidates for that. If the job is to solve real life problems, there's almost certainly a better measure.

I will never judge someone based on that kind of problem. I believe the data that results is just bad.

Edit: I should add that leetcode is useful for developing programming and problem-solving skill. I've done tons of problems, myself, and have fun solving them... and learn from them. So I do recommend it for a challenge. But not for interviews.

> I think companies that break out of the leetcode habit are going to do well. > There's a lot of great talent out there that's being passed over by these tests.

Agreed. And there's a lot of great talent that doesn't even want to try with some of these companies solely due to the hostile interview process.

I recently took a year off, and started interviewing in March. I spent a fair amount of time in fear of interviewing, doing LeetCode pushups and feeling miserable about my performance, and wondering if I could swing retirement rather than go through another fucking hazing ritual. Excuse my language.

I resolved up front not to submit to any kind of take-home test, proctoring software, or algorithmic nonsense unrelated to the actual job of shipping software. A polite "No thank you" was what I planned. But the plan was thwarted!

I was pleasantly surprised by the technical interviews I actually got. They were mostly nicely constrained problems that were real-world and not algorithmically nasty. One was a little unintended "collaboration" in the form of helping a senior dev debug their own "what is wrong with this code?" exercise (it probably went smoother for the next candidate they interviewed). In short, it was actually kind of fun.

I started a new dream job this week. At 61 this is no longer easy, but the company is enlightened enough to support me while I get up to speed, and it's fun to help mentor the folks just getting into the industry.

There are decent companies out there. Hopefully the terrible ones will start getting a clue.

Strong agree with all of this.

Ideally, interview questions should be directly related to the domain of the position. Show the candidate what they will actually be doing if they accept an offer.

The whole process should be a two way conversation.

Agreed. As a hiring manager, I’ve also explicitly, purposely come up with coding questions that reflect normal work: call APIs & issues, sync data issues, model data for usable systems.

The hires, then, focus on the right customer problems and don’t spin on creating random, useless code.

Everyone from mgmt to ICs, technical and non-technical, are happier.

Yeah, I've worked in tech 6 years now and never had to do Leetcode to get by in interviews. That being said, I never interviewed at FAANG. But many teams set a bar easier to pass than leetcode that still ensures good engineering skills

> now is a fantastic time for the tech industry to adopt change because your talent recruiters are probably struggling to find and retain new developers

Unfortunately, this will likely change much sooner and more rapidly then most of us expect. The music is stopping and chairs are about to be removed. It was great while it lasted, but all good things come to an end.

Sure. Someday. Same thing has been said since the 90s

And it's happened a couple of times since the 90s.

After working though the dotcom bust and the subprime fiasco it seems a bit dramatic

although I'm also not beyond my means and have some savings this time (didn't last time and it got hairy)

in general i worry more about other people in much worse situations that I'm unable to help

I’m not sure I agree, but I’m positive this isn’t a barrier to adoption right now. Recruiters are really looking for an edge to provide differentiation, and “friendlier, faster process” is a big one.

What has changed in the past 20 years? Because this sounds like the same shit I’ve heard since entering the industry. And it isn’t like this topic is new at all.

Would you be able to share the kinds of questions you ask and have had success with? :)

We basically adopted the MINASWAN interview, which Jesse Spevack can explain much better than myself in his talk [here](https://youtube.com/watch?v=c4K-ORZmrGk&feature=share).

The overview is that for each candidate we spend 20 minutes reading through code we provide to them to demonstrate comprehension, and then we give them 45 minutes to pair with us on reimplementing that same code from scratch.

What that code is doesn’t really matter, it’s more about getting a chance to work with them and start a conversation, and starting with trying to explain a provided example really smooths the way into the pair programming.

> 45 minutes to pair with us

Do you require pairing on real work? How do you handle candidates who need quiet to think? Going by the continual complaints about open plan offices, there seem to be a lot of us.

We require that ICs are able to work with others effectively; we have a very large engineering team working on issues related to health care and collaboration is effectively mandatory.

We keep the pairing as short as we can and we provide breaks between the short sessions to be as friendly as we can without being unrealistic as to what the candidate should expect in the actual job.

Your hiring process sounds great. Is there a link where one could apply?

Sure, you can view all of our open positions here: https://experience.covermymeds.com/open-positions (and then narrow down the list with the “all teams” drop down and selecting “technology”)

If you’re looking for a general SWE role: https://mckesson.wd3.myworkdayjobs.com/CoverMyMeds_External_...

How much time and resources does it cost to successfully hire one candidate?

Substantially less than our previous process.

We went from a process that took weeks to get through (multiple interviews, about an hour each, with a full code day at the end) to a two step process. Talent reaches out to the candidate and has a thirty or so minute chat to make sure the candidate meets basic hiring requirements, and then we have our MINASWAN process which is a single three hour interview, including two breaks for the candidate to get off camera and catch their breath.

The participants are: - the candidate - a hiring manager - between two and four developers for pairing - an open invitation to the hiring team’s devs for a closing panel interview.

The feedback we’ve received from candidates has been overwhelmingly positive, even for those who didn’t receive an offer.

FWIW, happy you're doing this! A better process would make so many peoples' lives better.

The ONLY people who should "get used to 'em" are new/recent grads looking for a junior-ish IC job. For them, it's just a fact of life: they had to learn history & biology to get their CS degree; they have to learn leetcode to get a job.

Interviewers should make a better process, as you're doing.

Honestly, I think I would encourage junior devs to shop around before just accepting the leet code life. Unless they’re in dire need of income—in which case, do what you need to do—the kind of company willing to treat you like a game show contestant may not provide the best culture for learning and growth.

If you can avoid the BS you should definitely do so.

So what'd you come up with?

I answered this in another comment before I saw this, feel free to respond to it if you want to chat about it: https://news.ycombinator.com/item?id=31453571

> I’m basically a moron

Google and other companies are actively trying to avoid hiring morons.

I’m not sure if you’re just being snarky or you’re trying to make an actual point here, but I can tell you that this kind of commentary reinforces the egocentric interview process we currently suffer through.

Solving puzzles doesn’t prove that you’re smart, and not memorizing them ahead doesn’t prove you can’t do the job. Unless you’re really on the edge of the industry—designing rockets for NASA or surgery tech or something—most dev jobs aren’t really all that hard, and we should stop pretending they are.

> most dev jobs aren’t really all that hard, and we should stop pretending they are.

I agree with you about GP's commentary, but I don't know that I agree with this statement.

Getting something working is often relatively easy. Shipping v1.0 is often relatively easy. But it starts to get gnarly as you build out capabilities, add services, split concerns up, have to maintain compatibility with previous versions, dependencies multiply, the amount of data you're dealing with massively expands, and so on. Most problems have one or more inflection points, whether that's around performance, or scale, or volume of data, or whatever, that when you pass them make that problem substantially harder to solve.

Still, these are all issues that come with a certain amount of success. Not necessarily crazy success: I'm just talking about the kind of traction that companies that grow to earn millions to tens of millions of dollars or pounds per annum experience.

The really hard part of being a dev, of course, is knowing what the right thing is to build. Often, because users tend to struggle to articulate their needs, the only way to find out what to build is to start by building something that you know is probably going to be at least a bit wrong, if not massively wide of the mark, just to get some feedback. And then you have to iterate, sometimes quite painfully, towards an actually good solution from there. Of course, this isn't something you can assess with a leetcode interview.

I don't hate interviews where the candidate is asked to write some code. I think writing code is a valid form of assessment because I've encountered enough jokers over the years who couldn't program if their life depended upon it - yet still manage to carry a job title like "software developer" - that I need some way of weeding them out of our hiring process. One reason for this is that I simply don't have gobs of spare cash to pay large salaries to people who are fundamentally incapable of doing the job they're asked to do.

Note though that asking them to write code does not equate to leetcode. We'll generally give people access to an IDE containing a template project and common tooling they would use on a day to day basis in the job. We also select problems that have some relation to our systems rather than asking hardcore questions about algorithms and data structures: we give them internet access so they can look that stuff up if they need it to help them (just like the rest of us do in our day jobs).

Cynically, a lot of interviewing I've seen over the years seems to be about the interviewer trying to appear to be the cleverest person in the room, and I think leetcode often falls into this category. I find this perverse and unhelpful but I guess these interviewers are just insecure, angry people.

I ask candidates to write code, but I tell my interviewers that the point is not completing the task but rather the conversation around it.

If they can’t write code at all, obviously it’s a hard pass because we’d just be setting them up for failure. But, if they’re maybe not the strongest dev ever but ask good questions and provide good observations I will be fairly likely to hire anyways. Honestly having people with room to grow just gives the rest of the team opportunities to teach… which in turn helps them to grow too.

I also tell my interviewers that we absolutely must start with the assumption that we will hire the candidate, and passing on them requires objective concerns. I really work hard to relate to my team that we are not so special that we should only hire the absolute best of all experts. What we do is not rocket science, and we don’t need rocket scientists. We need collaborative, intelligent team members to help /us/ grow.

All of this is to try to limit the impact of ego on the hiring process. It’s not about the candidate proving that they’re good enough to work with us, it’s about us being good enough to be worth working with. The candidate should meet the bar of helping us to make that statement true.

To be clear, dev roles can be difficult, demanding jobs. I’m not diminishing that, just reigning it back into the realm of reality. The industry treats hiring like people are going to die if we make mistakes, and unless that is actually true maybe it’s worth asking if what we’re doing is actually reflective of the job requirements.

> To be clear, dev roles can be difficult, demanding jobs. I’m not diminishing that, just reigning it back into the realm of reality. The industry treats hiring like people are going to die if we make mistakes, and unless that is actually true maybe it’s worth asking if what we’re doing is actually reflective of the job requirements.

This I agree with.

I'd also say that our worst mistakes have generally not been technical, though I don't want to go into the specifics here.

It matters more that you get the right person with the right skills for more senior hires, because they can have an outsized impact on business and delivery outcomes. I've seen the wrong person running a team lead to 6 months of rework when they left, as an example.

> Note though that asking them to write code does not equate to leetcode. We'll generally give people access to an IDE containing a template project and common tooling they would use on a day to day basis in the job. We also select problems that have some relation to our systems rather than asking hardcore questions about algorithms and data structures: we give them internet access so they can look that stuff up if they need it to help them (just like the rest of us do in our day jobs).

This is the best way I've found to assess if the interviewee can actually do the job. If you're trying out to be a violinist in an orchestra, they'll give you some sheet music and ask you to play your instrument. Leetcode would be like sitting the prospective violinist down at a piano, then asking them how to resolve exotic chord progressions and grilling them on obscure music theory. Yeah, any great violinist who studied at a decent music academy probably learned that stuff and still remembers it, but it's still a stupid test for the job you're asking them to do.

> Cynically, a lot of interviewing I've seen over the years seems to be about the interviewer trying to appear to be the cleverest person in the room

I'm even more cynical. People who were hazed to get where they are tend to want the new people to get hazed too. To them, it's only fair. And make no mistake, leetcode is hazing: it's not a test of ability, it's a test of how hard you're willing to grind for the possibility of giving a company your labor.

I think it can make sense in only one instance: for entry-level positions, if the person is trying to break into the software industry and they don't have a relevant degree. These people simply won't be able to do the same stuff that someone who's had a relevant position (or even just an internship) would. Navigating an unfamiliar IDE alone might kill them. But if they've done a bootcamp and they can crush some hard puzzles, they're probably competent enough to train up quickly, and it they're eager and they seem like they'd be great to work with, it can absolutely make sense to bring them onboard.

For everyone else, I just want them to show me what they've done in the past, and I want to test them on a problemset similar to what they'd actually be doing on the job just to make sure they're not full of shit. This is usually much less stressful for everyone involved, and provides a much more accurate signal.

The reason Google doesn't do this is likely for HR reasons: for a given position, they have to try to give the exact same interview questions to each candidate, as steering individual interviews in different directions on a whim can open them up to discrimination lawsuits. For example: women applicants might have less technical backgrounds on average, be given leetcode problems, and then the company could rightfully be accused of giving a typical woman a harder set of questions than men.

But there's opportunity there. While companies of Google's size are forced to formalize and lock down their interviews pretty hard out of an abundance of caution, smaller companies have a lot more freedom to tailor interviews to the individual candidate to figure out if they're right for the job. Great hiring managers figured out years ago that you can build a stellar team by snatching up the really talented folks who either refuse to play the leetcode game or happen to have a life outside of work. They're easy to identify if you're looking for them.

> I think it can make sense in only one instance: for entry-level positions, if the person is trying to break into the software industry and they don't have a relevant degree.

I'm not even sure I think it's necessary here.

We have a guy working for us who's a former nurse, and was still a nurse when he interviewed with us. He'd started programming on the side as a hobby, and our job ads were pretty explicit that we didn't really care about your background as long as you could program and were a reasonable human being, so he applied.

We still have a very short (20 - 30 minute) pre-screener interview before our main interview (90 - 120 minutes). That pre-screener has three objectives:

1. Figure out if the candidate is really interested in the job. We're not expecting people to turn tricks to show their enthusiasm or anything ridiculous like that, but we've had enough candidates that give off a "totally can't be arsed" vibe that we're basically just looking to screen those out.

2. Quick read on what the candidate is like as a human being.

3. Answer the question: can they write any code at all?

For (3) we have a whole raft of simple problems that require the candidate to write half a dozen or so lines of code. We'll generally explain the problem, given them an empty method or function and ask them to fill it in.

One example is write a function to reverse a string: this one's interesting because, in C# as an example, there's a functional solution, and an imperative solution (of course, there are several variations). The functional solution is enough to understand whether they at least grasp the basics of functional programming. The imperative solution will tell you whether they know how to use basic control flow and iteration, understand arrays (a string is really a wrapped array of characters), know about mutability and immutability, etc. Most of our code is OO/imperative, with some use of a more functional style where appropriate, so we generally encourage in the direction of imperative.

All our pre-screener problems are kind of like this: basic numeric or string manipulations, because our systems contain a lot of numeric and string manipulation. Definitely not leetcode: most of these problems don't require any knowledge of data structures more advanced than an array. It is literally: can this person code in any language similar to what we use here at all?

Our former nurse nailed the pre-screener first try - didn't even get caught out by any off by one errors. Whereas I've seen plenty of "senior developers" completely fail at these very basic tasks.

Our full interview involves a more in-depth pair programming exercise. Again, our former nurse nailed it, where plenty of more experienced candidates have made a right hash of it.

We took on our former nurse with both him and us realising that he'd have loads to learn, but four years later he's still with us and doing incredibly well.

This is obviously anecdata, but it does show that you don't necessarily need leetcode to assess someone entirely new to software development.

Solving complex riddles may not prove you're Einstein, but it's a pretty good filter for morons.

Disagree. I’m very good at puzzles.

then you shouldn't have said you're a moron. You seem somewhat contrary, which leads to its own problems, at least for me.

Disagree. I’m highly agreeable.

Only on the internet, that someone working for a cost-center division, building an piece of internal software used by 20 users, gets to lecture how a $2 Trillion Dollar, building multiple Billion real-world user products, generating > $500,000 per engineer profit should run their hiring process

That’s making a lot of assumptions about who I am and what I do based on nothing.

> They're biased, arbitrary, and often quite silly. And they've persisted for a half century.

Half a century? Absolutely not. It's a recent phenomenon (in software jobs).

All through the 90s and 00s it wasn't like this.

For what it’s worth, it was like this in my interviews at Microsoft in the late 80s.

The point is that leetcode is an instance of the class interview_riddles; the class has persisted for a half century.

> you can't learn leetcode without learning to program

A lot of people learn the jargon and sound like they know how to program, but don't. Failure to filter these out can be very expensive for a company. They have a strong incentive to ask for a programming demonstration to filter them out.

The worst part is it's biased towards those who already have the time / security to devote to it, aka those from the upper class. Vicious cycle.

That bias is generally true for any education-based employment that requires a significant upfront investment.

One big issue with these problems is that they are timed. So if for whatever reason you get stuck, stressed, distracted and take an extra 10m to reverse a linked list you're filtered out.

> My advice? Start memorizing the riddles.

I don't have a strong opinion either way, I got with the Leetcode grind program for my current position, but I really wonder about this: is it really possible to memorize these questions? Last I checked Leetcode has over 2000 questions, anyone who can memorize the solutions to all those is some kind of genius savant and should be hired anyway. Or is memorizing meant in a different context here?

Memorizing is meant in a different context.

Ultimately the problems boil down into a few "types". So you are memorizing the types.

https://dev.to/fahimulhaq/14-patterns-to-ace-any-coding-inte... https://neetcode.io/

As a sidenote: this holds true for other types of arbitrary-interview-riddles. There's only 3-5 "frameworks" you need to memorize/apply for consulting case interviews. Finance probability problems typically test one of ~a dozen prob/stat formulae + ability to multiply 3-digit numbers in your head.

After all, it has to be manageable for the interviewers to make sure all the questions are roughly equivalent in difficulty.

I have used hackerrank/leetcode previously just sporadically to learn a new programming language. I used it for the first time to help me get another job earlier in the year.

However, I have continued to solve 1 problem a night because what I realised is after 15+ years in the industry, I don't have a good grasp of some concepts anymore.

I'm slowly getting better at identify types of problems and apply what could be the most efficient data structure/algorithm in solving the problem. Once I solve the problem I go have a look at the solutions to see a more efficient way of solving it and try to store it away in my memory banks for another day.

The thing I don't like is when interviewer asks follow ups such as "Can you do the same solution but using O(1) space complexity". Unless the job has a restriction on running on limited hardware resources. I feel like it's unjustified asking such follow up questions because most of the time that is a very specific solution for the problem - or maybe I'm just not good enough to come up with such a solution yet.

> anyone who can memorize the solutions to all those is some kind of genius savant and should be hired anyway

But that's the problem. Why should they be hired?

The actual job will not consist of regurgitating those memorized solutions.

I'm impressed by someone who can memorize 2000+ solutions, same as I'm impressed by the acrobats at Cirque du Soleil, but I don't want to hire from either group for a software engineering job because that's not what the job is about.

Realize that in a lot of companies most people are mediocre at best; nowhere near "leet." It's worth studying psychology to understand that many of the swords held over your head in interviews/scouting are plastic and held by insecure people.

Doing so takes the pressure off and helps you to realize that there's a ton of opportunity out there if you want to get to that level.

The truth, though, is to build stuff, practice, and don't stop. I've circumvented most of the gatekeeper stuff because I intentionally hustled freelance/contract work early on and got to a level where I had a portfolio of high-quality work (i.e., leave money on the table short-term to make big money easily long-term). Now if companies turn me down, they look like fools.

Always worth asking: "how do I circumvent the hoops?"

Also (via Derek Sivers):

> “The standard pace is for chumps.” - Kimo Williams

Feel free to email if you want an opportunity to practice/gain experience: ryan.glover@cheatcode.co.

I find interviewing skills are more important than job skills in terms of income.

Trying to get a 20% raise by doing a good job I've found to be a protracted difficult task, but a 50% raise by interviewing? Much easier.

You do need some job skills, but in my experience being fired for not being good enough is rare, and can take a lot of time - during which you're getting paid.

Another thing I've found is I pick up the most exposure to new ideas in that first 12 months in a job.

These two things together means being able to get a new job easily is very useful.

But getting a job is different from doing a job, don't expect the two activities to have much in common. It could be better, but hey 3-4 months of evenings spent programming to get a big step up in the job market is a pretty good deal if you enjoy programming :)

(Personally I've found leetcode useful at becoming a better programmer, though I didn't approach it as memorizing riddles.)

I'm at a FAANG right now. Havent interviewed in years, lead projects on one of the most critical services at my company. Just interviewed at a startup, they asked a design question, and immediately nixed me for not having the correct "design process". Meaning requirements gathering, scoping, etc. 20 minutes in the interviewing engineer basically checked out.

My resume is very good. Its a little scary, because this experience is actually common. No one trusts anything, and nothing you have done is worth anything, unless you are well known. You need to study whatever textbook answer they are looking for.

Sounds like they care more about process. Process-centric companies tend to not do well in the long run.