This totally changes when you're a specific candidate with skills Apple values. What this guy experienced wasn't an interview process. They had already decided to hire him before what he described as the interview process. They already know he's good, he experienced the talent acquisition process. The bit that happens when the company has already decided to hire you and is now doing everything it can to sell you on the job.

If someone outside of recruiting contacts you about a job at a company, you will not experience a normal interview process, because they're already quite likely to want to hire you.

Hiring managers will hire someone they already know or find themselves 9 times out of 10.

Do something that gets noticed or get to know people and network. Sending out cold resumes will have the lowest success rate of those three options.

[0] https://corecursive.com/shipping-graphing-calculator/

But my summary really doesn't do the interview justice. Highly worth listening to.

There’s a few cases of people walking into ‘secure’ data centers plugging in their laptops only to realize they’re at the wrong company. People while swipe badges, act befuddled because it didn’t work, and then get let into the building. Or get out of an elevator with a bunch of people and just walk in as part of a crowd which holds the doors for each other.

I'm glad people aren’t just continuing the practice simply because they experienced the practice.

System A optimizes for min(p(hire|bad_candidate)). System B optimizes for max(p(hire|good_candidate)).

System A has resume screens, long lead times, and Leetcode out the wazoo. System B has a few convos, short lead times, and review of actual previous work product.

Horror stories come from great candidates in system A. This article is describing how to get into system B.

This clearly does work sometimes, but it's not necessarily the best advice for everyone.

A lot of hires, even in companies like this, happen more from conversations that resumes and job postings.

As a hiring lead, there are a small handful of people I know well that I would try to create a job for immediately if they emailed me they wanted to join. As an employee, many job's I've had started something like that.

Still, I think a lot of folks could benefit from thinking through "how do I get into system B?" - because those skills are tremendously helpful in System A, too.

You start from scratch, you can pick something you're interested in building and maybe also feel you can succeed at. You make up your own requirements, as you see please, so things aren't ambiguous or changing in requirements constantly.

There's no prior legacy constraints, there's no time constraints, it doesn't require finding ways to deliver faster by leveraging other developers.

You get to spend as much time as you need, go watch tutorials, take a hiatus, come back to it when refreshed, fail multiple times and try again, etc.

You can choose the programming language, framework, library ecosystem, that you're more familiar with and comfortable with.

And so on.

So having someone that can show some cool personal projects I've found isn't always a great way to know if they'll be good in a work environment and on a team.

No ones gonna hire you because you spent a decade and have a half finished game engine written Haskell.

All of that freedom is fake and some even in contradiction with each other.

You cannot take your time, or you pick a larger scope project, you will eventually run out of savings, or get questions from family members about why your job search is taking so long.

If you filter out everything but smaller scope projects then you have a far smaller subset of projects that aren't as unique because everyone else has done them. If you just graduated from University, you lack experience with project management and as the saying goes, write what you know, and so that'll limit yourself to video games or web and that one niche subject you took at Uni.

This advice feels like what you would get from a rock-star who was young and stupid and naive and very lucky telling a kid that if he just makes music and sticks it out he'll get scouted by a record label, When in reality he just was lucky enough to market pop-derivative music at gigs, while not realizing the kid likes to make music from sampled traffic noise and his favorite album is Music for Airports.

This is a high risk endeavour and you either need to make conscious decisions that mitigate risk heavily and are compatible with your personality, and the end goal of being financially secure.

A candidate that has a good portfolio and can pass an algorithm and design interview, and described prior work experience on projects that seemed involved is your best bet of course.

No, it looks like you're missing the point. Leetcode is not for people with special skills. It's for people with NO SKILLS other than "can code". Well if the only thing you can do is write code, you better be really good at writing code.

in fact any candidate that doesnt ask clarifying questions and goes deep into coding right away - has a chance of going into wrong direction and is flagged as red flag.

As an interviewer I always lookout for candidates that dont ask questions, dont start with test cases, assume in their mind what is their understanding of ideal solution - and start coding. These are very inexperienced people who do that

Or maybe it’s making the tree upside down, so all leaves become roots, and the root becomes a leaf. But when we do that, do we just invert all the edges or transform the whole tree?

Maybe it’s referring to changing a red-black tree into a green-white tree? Or turning a splay tree into a merge tree?

Howell (the homebrew 'google didn't hire me because of inverting a binary tree' guy) confirmed that they meant swapping right and left children of all nodes.

If that’s the hang-up on hiring him, they need to get the log out of their own eyes first, because shifting to the quality level of Homebrew would be a big improvement for a whole lot of their software.

SV is full of mediocre engineers; so it fails at guaranteeing you got yourself a star. And I don't think anyone needs more anecdotes to think great candidates lose for arbitrary/subjective/misunderstanding/random reasons

--

I'm 15y into my career with a degree from CMU; I am treated like royalty everywhere I work ... and yet I still absolutely dread, hate and repeatedly have bad experiences interviewing for jobs.

I've considered switching careers numerous times because of the emotional distress I go through just interviewing. And that's before we even talk about the insane amount of time every prospective employer demands of you!

I have worked an average of 40-hour/week jobs for my entire 30-year career. What's this "demand" nonsense?

If it's making you so stressed out as you claim, then the obvious step, to me, would be a change of scenery.

And yet I can't escape leetcode interviews. In fact I recently sent a spree of CVs and got automated rejection emails for most of them.

I don't buy your take.

Granted I don't live in a tech hub so my options are limited but 100/day feels like you're just spamming aimlessly and wasting your energy on quantity instead of quality.

You're far more likely to get 100 rejections doing this than if you research a handful of the positions and send targeted resumes to those.

Even at the staff/senior staff/principal levels you will still have to face the same LC gauntlet they give to new grads.

it will open many doors :)

I’m hiring too, but few of my applicants include a GH link. I’ve never seen a GL link, much less Gitea, etc.

And mind you, I’m looking. Hard. I’ll often Google the person to see if I can find a GH account for them. I hit rarely, and it’s weird.

Today one of my applicants had a GH profile and a README, a couple dozen projects in various stages of abandonment, etc, and I was deliriously happy.

I’m not very experienced in hiring (this is the first opening that I’ve written the JD for, reviewed the applications, wrote the tech interview questions, etc), but we’re clearly doing something wrong. We have a few great applicants (mostly from here and Reddit) and a whole lot of low-effort, low-value noise.

Software jobs, especially at the kinds of FAANG companies largely being discussed here, are quite a stretch for the term "wageslave."

Entrepreneurship isn't for everyone, even those who've tried it before.

People are so easily offended these days.

Having said that, if you work for a company and you get fired and blacklisted, you still don't eat. If you work for a wage, you HAVE to work for somebody or you starve. If you work for somebody, that somebody has a lot of sway over how your life looks. Better be good at kissin' ass.

Also, if you don't think the US healthcare industry will take every penny of your life's earnings upon your eventual and inevitable deterioration, you're fooling yourself.

FWIW, I'm a wage slave too.

It certainly can be like that especially early on. Hopefully you would grow enough to hire good people to manage the business. If you work for somebody though, that will never happen.

All the slavery with none of the wage.

>If you work for somebody though, that will never happen.

The alternative to starting a business that you'll hope will be self-sustaining and still earn you a respectable living is to work for the highest bidder, invest, and become financially independent. Odds of the latter are much higher for the average software engineer than the former.

You really don't. There is no way you can starve in the USA unless you do it on purpose.

Please note the literal use of the word 'starve'.

Cupertino is an hour away Santa Cruz beaches. 3 hours away from skiing (or boating) at lake tahoe. 1 hour away from one of the best NBA teams (GSW). 30 minutes away from Stanford. 1 hour away from Berkeley. Some of the best average temperatures in the country.

Maybe they live in a "shitbox fixer", maybe they don't.

You might consider that people like and care about those other properties though.

a lot of hour drives away from everything? London or Tokyo it is not.

> Maybe they live in a "shitbox fixer", maybe they don't.

I was being rather generous at $2M on a $300k salary. Let's just assume the spouse makes that much too. Where do you place the odds of getting a nice house at, in that area? Of a similar quality that would run around $200-400k in the rest of the country. It's the suburbs. You're going to be inside your home more than you would in a city.

> You might consider that people like and care about those other properties though.

The point is $300k in SV isn't living large. You save more for retirement or to move out. Great. But you still have to leave to realize that benefit. You're just planning for some tomorrow that usually never comes for most people.

That's odd, my impression is that a lot of people go to the Bay, save a lot, then leave.

Do we have any statistics on this?

Maybe most of your time is spent on a computer.

and Nebraska has nice places too, especially if you have a family.

Try to raise a family with 5 kids in sf, and compare to Omaha. I would pick Omaha 10 out of 10 times, if I was not a millionaire

What am I, a farmer? I would pick not doing that 10 out of 10 times regardless of how much money I had.

>ah, yes. The American Dream of living in a 50 year old shitbox fixer that costs $2M in the suburbs of Cupertino.

So you’re right, folks living outside of metropolitan areas need to work on their insecurities and learn to be nicer to people that prioritize other things in life.

More like well-justified feeling of intellectual superiority, of being able to afford 5000 sq ft home with few acres of land, and raise a family with 5 kids on a single income, and not having kids wade their way through poop and needles on the way to school, not having to smell urine and marijuana on the streets of neighborhood

mainly because cutting edge R&D type technology has been developed in the area and alternatives to SV have not developed yet. its not even pay - I would say bay area pay is bad, because of cost of living & taxation.

But opportunities for growth are unmatched in bay area

because $300K will demand much much more than 30k job.

300k job leads to stress, anxiety, performance calibrations, mental breakdowns, overwork, competition, lack of job security etc.

30k job could be very relaxed, could be part-time gig where you work few hours in a week.

so work-life balance is really tilted worse for higher paying jobs

To be clear, it can be true, there are lots of stressful high paying jobs, my point is that it's not necessarily true.

I know low paid people with stressful jobs and highly paid people with less stress.

It's not like your savings and investments are adjusted for the cost of living when you move.

In the extreme case, you can earn as much as possible and accumulate enough to live on indefinitely in a cheap country. This is obviously better than just earning a low salary in the cheap country for the same amount of time.

If someone with 300K+ TC gets offended by this term, playing world's smallest violin for those snowflakes would be most appropriate.

The part in brackets isn't something to hand wave about. Depends a lot on how you want to spend your time, also.

For example, if you had an idea about planting trees via drones and a big company said "come to our company and we can get this launched at scale as early as 2026". Then you think about how long it would take to do it on your own and you'd still have to convince investors and hire people and stuff.

If at the end of the day, what you care about is planting more trees quickly, you should probably join that big company. (of course there are risks too, where they cancel the project or divert its direction).

And also, not every startup found cares about achieving some grandiose mission. Some just want to get rich which is totally fine.

The biggest stumbling block with leetcode is that you shouldn't be programming like that in real life.

"make a linked list" no, just use a library like everyone else.

"Implement addition in python but with string inputs", "no you can't use the built in x" All of that "clever" shit should be filtered out at PR/MR/diff review time.

All of this "clever shit" is exceptionally bad programming. We don't live in the 80s anymore. we don't need to make our own sort algorithms. just. use. a. Library.

> "make a linked list" no, just use a library like everyone else.

> "Implement addition in python but with string inputs", "no you can't use the built in x" All of that "clever" shit should be filtered out at PR/MR/diff review time.

Sure, those statements (just use an existing library) are what you'll do in practice especially as a beginner. But there is value in asking these kinds of questions.

One is "do you know what's going on under the hood?" On another post I just saw a comment in which someone advocated counting the number of occurrences of something in a list by filtering it and then getting the length of the result. This is almost certainly a terrible solution as it allocates memory (which has to be freed) in what can be done in a single quick pass. By asking you such a question the interviewer can learn if you have some idea of the tradeoffs and why something might be a good or bad idea.

These are the kinds of decisions that can have order of magnitude impacts on runtime, which can have huge impact on the company's costs.

Likewise doing arithmetic with strings as inputs would expose interesting but not super complicated questions about how arithmetic works, how you parse a numeric value out of its written representation (detest the word "conversion" for this), what are interesting bounds. If the job is really so high level that you don't have to think that there's an actual machine involved, then yes the questions aren't useful. But how many jobs are really so abstract?

> We don't live in the 80s anymore. we don't need to make our own sort algorithms.

No, but sometimes you have to make a choice based on the data to be operated on.

> These are the kinds of decisions that can have order of magnitude impacts on runtime, which can have huge impact on the company's costs.

Then the questions should be more like: What data structure, library, method, steps, would you use to solve this problem and why. What are the tradeoffs of your choices, etc?

All of this can be answered in fairly high level pseudocode too and still show that they understand the concepts etc.

The more code you write, the more you have to maintain. Sure, of course there are times where you need to re-implement something from scratch. But those times are rare (or should be). Making something from scratch without strong justification is a strong signal, just not a positive one.

Now, as you point out, "when would you write x from scratch" is a great question to ask someone. I am vary wary of people that are willing to overspend innovation tokens. But thats a design/systems/culture question, not a coding question.

the signal I want from a coding test is the following:

o Can they demonstrate and understanding of the programming language?

o Do they create readable code?

o Do they ask questions?

o Do they follow the style of the programme they are modifying?

o Do they say "I don't know"?

o Do they push back on weird or silly requirements?

all of those things make working with someone much easier. None of those questions require "implement algorithm that only exist in Computer Science courses". They can all be answered by something like:

"here is a program that fetches a json document, but it breaks often, please make it more reliable"

That is far more realistic, and more likely to what they'll be doing.

The dirty little secret about most coding jobs is that actually, the important thing is getting something functional and stable for the business, so it can make money. Then after that its responding to feature/bug requests. As a programmer, your job is to convert business logic into computer logic. 99% of the time, this doesn't mean making artisan libraries that improve some tiny metric by 20x.

I find I get 90% of the insight from simple questions like "write a function to shuffle a deck of cards. Don't worry about simple typos like forgetting a semicolon."

You learn a lot from how they set things up (make a suit class, and a vector of card classes? Or just use the integers 1-52?) and talking about that. Do they think about the problem (and, as you say, ask a couple of "requirement" questions) before diving in?

One of the best hires I remember was someone who got this problem wrong (went to a lot of work to leave the deck unshuffled). We gently asked if it did what was required. Hi smacked himself on the forehead and said, "I'm a fucking idiot" (in front of us in his interview!) and quickly corrected the bug. Great guy.

And if you didn't like the experience you wouldn't want to work for us so the interview would be a success too.

My god, yes. We had a two-part problem that we used for the "work skills" part of the interview. Part 1 boiled down to writing a two-level nested for loop that was simpler than fizzbuzz. Part 2 was using that loop to solve the rest of the problem, which was far more complex. I lost track of how many candidates spent 40 of the 50 minutes just writing that loop.

It really depends on what you're working on. A package to manage a dentist's office should be as off the shelf as possible. I don't care about I/O and try to do as little as possible, using whatever's off the shelf, but my HFT buddies are bumming the hell out of it, customizing the kernel, and whatnot. You may use elastic search to save you time and money, but the folks working on it have probably run over it so much there's nothing but custom code left.

It's all context.

I’ve spent about the last year optimising text CRDTs so they’re actually usable in practice. A few years ago, 800mb of ram usage and 5 minutes processing was common to open a document. Now we’re talking 2mb of ram and 20ms. That is the difference between something not being viable and something being usable everywhere. And yes: my code involved a lot of custom data structures and algorithms. There were no libraries in cargo which did exactly what I needed.

This thread is full of people bemoaning “leetcode problems” for being irrelevant in software jobs. But I use them all the time in my work. Software engineering is far more varied than any of our individual careers.

Everyone who's on the other side of the Leetcode debate from you wants the exact same thing - an interview process that is representative of the actual day-to-day work.

As a Web developer, inverting a binary tree is not a thing an employer has ever asked me to do.

As the GP commenter said:

> It really depends on what you're working on. ... It's all context.

I brought it up because many (most) commenters in this thread seem to be claiming that this knowledge and skill is never useful. That its ridiculous to ask about this stuff in any job interviews, except as a ritualistic hazing ritual. This is also absurd.

> As a Web developer, inverting a binary tree is not a thing an employer has ever asked me to do.

I've never had an employer name any data structures explicitly. Its our job as the software experts to know which tools and technologies are relevant. But with that said, I can't remember ever using custom data structures in frontend website code either. If I were hiring a web developer, there are so many things I'd rather spend time talking about in an interview. (HTML & CSS knowledge, web frameworks, design skills, raw programming skill, etc.)

Those commenters are making generalizations because many (most) jobs in the industry do not find that knowledge and skill useful. Certainly specialized edge positions exist.

If pure CRUD companies only looking for JavaScript specialists are also using leetcode screening, they're missing the point.

I think it's really not about "beginner" vs. "expert", but moreso about the specificity of your role. If you're tasked with making general cloud services, it's probably fine. As your role gets closer to core systems/algorithms engineering, obviously that changes.

> But there is value in asking these kinds of questions.

There is value knowing, but the dynamic of an interview make things like this harder to ask/harder to answer.

> One is "do you know what's going on under the hood?" On another post I just saw a comment in which someone advocated counting the number of occurrences of something in a list by filtering it and then getting the length of the result. This is almost certainly a terrible solution as it allocates memory (which has to be freed) in what can be done in a single quick pass.

In the real world the validity of this solution depends on its input and use. Also in the real world, especially if you're not on one of the above-mentioned specialist teams, it's usually more important to be readable and maintainable instead of just purely performance oriented. So a single pass solution that's harder to grasp at a glance becomes less desirable than multiple passes as long as your performance requirements can afford it.

> By asking you such a question the interviewer can learn if you have some idea of the tradeoffs and why something might be a good or bad idea.

Totally, but the issue becomes "Can you figure out an algorithm on a whiteboard", instead of the (as you've already agreed) correct path of "Can you work through tradeoffs of one implementation vs. another". I think this question could pretty easily be presented in a way that isn't a quiz and also allows the programmer to demonstrate their problemsolving ability without seeming adversarial.

Why should I need to? Let's take Microsoft's .Net sort implemtation.

It will intelligently determine which is the optimized sort given the conditions it's facing.

Heapsort? Mergesort? Quicksort? Radix Sort.

And the most-possibility optimized versions of each.

This is what data scientists do. We don't need programmers standing at whiteboards writting BubbleShort and being told it's wrong. In the real world, you call .Sort() and get on with real work.

Sure, you can hand-roll your own sort for hot-path cases but that's likely been taken into account anyway!

I agree leetcode style interviews are artificial, but I think they persist because few people have identified and popularised effective alternatives. At least with leetcode you've shown people in front of you have been prepared to go learn arcane stuff and apply it. It's not good, but it's better than nothing.

I was once asked to do the Gilded Rose kata[1] for one ~200 headcount Series D "startup", and it not only resembled real work - it's a refactoring problem - but it also showed their engineering culture. When I joined, I found smart people who weren't leetcode robots, but thoughtful engineers trying to solve tricky engineering problems. I "stole" Gilded Rose to use in other companies when interviewing until I joined my current employer (a FAANG, heavily prescribed process), with great success. I would like to see more katas that are as good at testing real world skills.

Also, something I've only ever been interviewed for twice in 25+ years, which I think is underplayed: pair programming and handling code review feedback. Do this more, please. If you hire people not knowing how they're going to respond to a principal engineer telling them "we need you to think about 4 other things that weren't in the original scope given to you by the PM, can you please go deal with them", why are you surprised when toys are subsequently thrown out of metaphorical prams?

[1] https://github.com/emilybache/GildedRose-Refactoring-Kata

For example, if the position is mostly coding C then just get them to explain how some X interacts with some Y and how that interacts with some Z. Maybe with a copy of of K&R and get them to point to page so and so.

Do that a few times, maybe use a whiteboard, and I think any experienced C developer will be able to tell who's faking it and who really understands within 2 or 3 iterations.

Even if there are no experienced folks in the company, then it will take longer but, after an hour or two it'd be pretty difficult for anyone to fake a solid understanding of hundreds of pages of K&R.

I get the wider point you’re making, and yes, a chat can help. Elsewhere in a reply to this I talk about how I personally like to do that, but the problem is, a significant number of people can talk about coding but can’t actually code.

I once interviewed somebody who had passed 3 previous calls. Asked them to implement fizzbuzz. Couldn’t.

That is a real problem. It’s not myth.

As such, I’m not hiring somebody without seen them writing code the same way I wouldn’t hire a designer without seeing their actual personal portfolio.

We removed pseudocode from our pre-screening due to this. Some people are absolutely great with English and pseudocode, but can't write a for loop, in their "preferred" language of their choosing. I'm sure they could be great at programming...eventually.

This is basically my interviewing POV. If you've done the work, you can talk about the work intelligently if I ask some questions about it. If I ask you how you would think about solving problem XYZ, you can probably verbally think through how you would solve the problem, what a solution might take.

In-person time I used to like to ask a question I got from here: “Tell me about your favourite coding work or side project”. We’d then dig into choices, trade offs, obstacles and how they got around them.

My favourite answer to this was “an OpenGL implementation for the X Window protocol which I wrote in Common Lisp”. Just getting through the first layer of “Why [x]?”, took 15 minutes and we spent an hour talking about all the facets. Hired him, was a superb colleague.

What you're really asking for is a candidate to spend extra time inventing a convincing git history.

I really think the only way this actually works is if the problem is on a page which you can only view after you start a timer or something.

Or do it on site and watch them.

This is all high pressure but if you really want to time box, there can't be a way around it.

I don't think that candidates who spend less time or turn in incomplete take homes are necessarily at a disadvantage. Sooo much can be discerned from a take home even if it's not finished. I can evaluate a candidate's familiarity with modern syntax, how they organize functions, how readable their code is, whether or not they used ChatGPT/CoPilot or copy/pasted from an online tutorial (surprisingly easy to discern when you're evaluating many submissions), and so on.

All of that tells me a lot about how well someone functions as an engineer, as well as what level they're operating at, and it doesn't require the completion of the take home problem.

The take home serves two purposes: (1) should the candidate progress to the in person interviews? (2) if the candidate stumbles in the in person coding, can I deduce from the take home that they do actually know what they're doing, and the stumbling was a side effect of interview anxiety?

I can tell a lot even from an incomplete take home, about whether someone is likely to do well on the in person interviews, but I mostly find it extremely valuable for (2), as a tiebreaker.

It hasn't happened yet in this cycle, but I can imagine a situation where someone turned in a fantastic take home and then brain farted during the in person coding, and, thanks to the take home, got hired.

Refactoring is a task that's mostly about reading, understanding context, and a bit of rumination.

I think having them design the library, or a fraction of it, from scratch, would give a more momentum.

I have done this as a take home test and I am ok with this as long as it doesn't take more than 5 hours.

Astrology persists, but that's not a testament to its efficacy.

You can always just google how to invert a binary tree or whatever and get a solid answer in no time. Which means it’s easy shit. Unless you’re one of a few devs doing PhD level work in the industry, that CS-heavy “mathy” stuff’s not the hardest thing you’re dealing with, and being good at that indicates almost nothing about your ability to deal with the hard problems you will encounter on the job.

(or else you’re greenfielding at a startup and are doing everything on easy-mode anyway, aside from problems you create for yourself on purpose or by accident)

To be sure, there will always be some senior/staff/principal engineers who sit in a room by themselves and code all day without talking to anyone, but, typically, the more senior you get in an organization the more your job consists of things other than writing code. When you're a junior or a mid, however, writing code makes up the vast majority of your day.

Weird. Why would someone pretend that?

In a company like Google (or Google 15 years ago really) there are problems with many possible solutions, but some solutions are better than others. The aim of leetcode recruitment is that it filters for people who can not only solve hard computer science problems, but also recognize what problem they're solving and find good solutions rather than just solutions.

"I can implement this with a library" is only a good solution if the library is solving the problem in the right way. If the library is solving the problem but solving it in an inefficient-but-working way that is not good programming. At the end of the spectrum where Google exists you need developers who know the difference.

The problem with leetcode is that it doesn't actually filter for people who can understand problems in a general sense. It filters for people who know leetcode problems.

Yep. And even then, you need to know what you’re looking for. Years ago I wanted a library which implemented occlusion on vector shapes for plotter art. I had no idea what terms to search for because I don’t have a strong enough background in graphics. Turns out there are algorithms which help - but it was years before I found a good enough library.

And if you know what to search for, there are so many terrible implementations out there. Look for priority queues on npm. Half the libraries implement custom binary trees or something, despite the fact that using a heap (an array) is way faster and simpler. If you don’t know why a heap is better, how could you possibly evaluate whether any given library is any good?

If I ask you a question along the lines of "write me a function to tell if two number ranges intersect" and your solution is to grab a library instead of writing a simple predicate...then perhaps the role is not a good fit.

"Use a library for everything" is how we ended up with left-pad on npm.

bollocks, that's because javascript doesn't have a standard lib.

> You do know we hire people who have to _write_ these libraries

I know, because I'm there. I'm working in VR/AR. We have a number of people who are world experts for doing what they are doing. Do I go off and re-make a SLAM library because I don't like the layout? no because I have to ship something useable in a normal time frame. I can't just drop 3 months replicating someone else's work because I think the layout is a bit shit, or I can't be bothered to read the docs (I mean obviously there are no docs, but thats a different problem)

But, and I cannot stress this enough, having more than one person making similar or related libraries is a disaster. Nothing gets shipped and everything is devoted to "improving" the competing libraries.

I don't think "valid applicant" and "doesn't really grok strings/types" are compatible, outside of intern/maybe junior positions. The filter works.

Another possibility is nerves. Early in my career I was very nervous in interviews and I have sympathy. I have fucked up the most basic search algorithms completely and spewed gibberish when asked to explain the complexity of my solution.

I have sympathy for that, but the only way to get through interview nerves is exposure therapy. At least in my experience.

You’re given `99999`. Increment it. A naive approach would turn this into `9999:`. Making this work is a bit complicated and involves memory reallocation if you’re in a C-like language and you need to increase the length of the string in order to increment it. You’ll probably want a system where the caller passes a buffer of sufficient size to use for rewriting the string, in case you overflow. Make sure to have a way for the caller to pass the buffer length. You don’t want to allocate because that’s not the way it should be done in C, callers should generally allocate. You could use atoi, increment, and itoa to go back again, but that’s probably “cheating” from the perspective of a leetcode advocate, they likely want you to do this without the stdlib conversion functions.

There’s a bazillion reasons why this sucks as an interview question. There’s no way a correct answer is just something you’ll “get in 15 seconds”.

If you're not allowed to use atoi and itoa, it's still not all that difficult to do in C. Incrementing ASCII characters and handling carries is really trivial.

I'd be kind of worried if I was hiring a C developer who didn't know the basic things you described above. I'm not sure why you think those are esoteric concepts that we shouldn't expect developers to know.

This actually does seem like a great icebreaker-type question for a C developer. I'm less convinced every developer should be able to go into that level of detail if they are doing Javascript or Python or whatever. Ideally they'd be able to at least reason through some of this and demonstrate some understanding of some of this, but I'm not sure it is a great icebreaker question for all developer roles.

An O(1) in-place solution with a sane API exists in C++ and the form of it is also a handy indicator of whether candidate who proposes solving this in C++ is familiar with more recent standards or not.

Are you starting to see why this is a good icebreaker? It has all kinds of discussion potential.

That baffled me for a moment, then I realized you were talking about the general case of a uniform random input where a carry for the 1s digit has probability 0.1, a carry for the 10s digit 0.01, etc., and all 9s is the pathological worst case, right? That's what I get for coming into the discussion sideways.

Of course there is a trivial solution in pretty much any language, for example something like str(Decimal(x) + 1) in python. That's dead-simple and anyone should be able to do at least that.

The later addendum that they want someone to know how data is store by the computer seems to imply that they want an answer that doesn't use these conversions, which gets a lot trickier depending on the context. I think you'd still expect someone who does C/C++ work to get there pretty quickly, but it is more than 15 seconds - you have to think about some corner cases and how you handle the string having to be resized in some situations.

But in some languages, it isn't obvious to me how you'd do it (especially since strings are immutable in many languages) and I think it is maybe a bit unfair to ask someone who does Java or Python or whatever to do it off the top of their head.

Problem solving isn't orthogonal to having genuine expertise. Loads of awful, brittle, hard-to-read, but working, code gets written every day by people who are good at finding a solution but haven't RTFM, so to speak.

for example, if you are using strings to do addition, why the fuck aren't you allows to to atoi? also, why are you using strings to hold numbers?

everything to do with that question is something that you'd insta-reject in a diff/pr/mr.

Surely converting from string to int, validating it, catching errors and generally making it nice, is a much better test?

Its like going to an interview for a copywriter(someone who writes text) for safety sign company, and they ask you to make a riddle in English, but you can't use any words that are derived from Latin. Sure it shows an impressive command of both etymology and english, but its totally opposite to making clear, easy to understand text.

That you have the capacity to sit down and rote memorise a bunch of different techniques and practice completing a these kinds of tests indicates the likeliness of success in absence of other hard evidence of likely future performance. In a way it is the same function as university entrance exams.

That these companies continue to do this for experienced candidates and not just recent graduates without a track record in employment is more perplexing.

This assumes that they don't get similar number of people applying to the experienced positions who are lacking skills.

For example, I know some Java devs who could put down 5+ years of professional experience but are still very junior when it comes to problem solving skills. They are capable of following precise instructions and there's enough work of that nature to do - but an open ended "there's a bug that has a null pointer exception when running in test but not dev or production" is something that they're not capable of doing.

If they were to apply to a position that said senior java developer based on their years of experience and there was no code test as part if it, they might be able to talk their way through parts of it and there is a risk that they could get hired.

For a senior java developer position at Google, would it be surprising if they got 500 applicants with 5+ years of experience?

How would you meaningfully filter that down to a set of candidates who are likely to be able to fill the role?

Also, some Leetcode problems just have unnecessarily unfriendly descriptions. For example this one, which is quite simple to implement, but which has an unnecessarily obscure problem description: https://leetcode.com/problems/count-and-say/

Of course, hiring someone purely on how good they are at leetcode would be... dumb.

One "subtlety" this misses is that leetcode-style trivia tests only work for those who are willing _and able_ to grind leetcode etc.

There are many who have the aptitude and experience but have e.g. children, or interests outside of programming which means they do not have the required free time to spend rehearsing for this kind of interview.

This is simply not true. The smartest people I graduated my CS program with can pass leetcode style interviews without practicing. They live and breathe this stuff.

Are these problems overemphasised? Absolutely. But they don’t expect you to grind. They exist so they can find my smart classmates to make sure they get offered a job.

FAANG want dedicated engineers who don't have the distraction of family and/or sick relatives.

They don't want people who need to finish _promptly_ each day to put their kids to bed.

They want their pound of flesh in exchange for a high salary and ability to add "Worked at FAANG" on their CV.

If you have the time and dedication to grind leetcode for months the you've passed their requirement.

This is hilariously out of touch.

Most of the FAANG people I know have kids.

Nearly all of their managers have families.

The one person I know who has two special needs kids specifically sought out a FAANG job for the stability, compensation, and work life balance it afforded.

Serious question, not rhetorical, in case it doesn't come across.

If you cannot sketch out a simple linked list on a whiteboard, you’re not an engineer and have no business being hired as one at a place like Apple, full stop.

I was asked to sketch out a hash table on the whiteboard. It was trivial, because a trivial hash table is trivial.

well, unless you have a engineering degree, you're not actually an engineer, but we'll gloss over that. (big hint CS isn't an engineering discipline, otherwise testing, requirements gathering and cost analysis would be a big part of the course. )

I was once asked to implement a distributed fault tolerant hashtable on a whiteboard. I'd still never make one from scratch unless I really really needed to. (and I've worked on distributed datastores....)

but that wasn't part of the coding test, that was part of the design test.

Which is my point, re-implementing things for the hell of it, is an antipattern. rote learning of toy implementations of some everyday function doesn't give you a good signal on if the candidate understands why you should use x over y.

and again, my point is this: If I catch someone re-implementing something in a code review, they need to have a really good fucking reason to do it, otherwise it'll be rejected.

If you can't hammer out a technical interview using off-the-top of your knowledge, you're in the group they're trying to weed out.

This is not true. There are dozens of types of engineers and that word doesn’t mean civil engineer. There are audio engineers who work on music and film ffs, get over yourself.

That's not a requirement in the US.

People always make weird arguments about lc, but whats the point?

Just put effort into it or not, no excuses needed

Our team can get to be very picky about people because ... well, we need to be.

I'm sure some companies have lousy interview practices, but algorithms and data structures are super important if you want to hire someone who's actually competent, who can think for themselves.

You can’t make blanket statements about software like that. Our field is way too varied.

For example, if you’re doing high frequency trading, then performance absolutely 100% matters. And knowing your data structures and algorithms backwards is part of that. On the other hand, if you’re building the website at a large company, the hard part of your job may be interfacing with the rest of the business. So networking and navigating corporate politics will be an incredibly important part of your job. And if you’re on a small team making a product for consumers, then your work will succeed or fail based on usability.

We could brainstorm dozens of other skills which might be important. Which of these skills matter the most depends entirely on the company and the role.

What they aren't good at is consumer-facing web services with graphical frontends, at least since Gmail or so. Even there, businesses seem to like the G Suite.

Chrome: hmm - was Chrome developed after Brin & Page left? I never realized this but OK you got me on that one if that indeed is the case.

Go: I liked it initially and I love the performance, but i don't necessarily love the language syntax and design.

The rest: mostly tools which make scaling Google's infrastructure easier. I don't count these as outstanding accomplishments but I suppose you may have had me here too (albeit the scope I was referring to mostly referred to regular ppl not infra teams but meh I suppose I'll give you this one as well).

if you dont do that in leetcode interview - you will not make it, or you will be graded as junior/entry level engineer.

No senior engineer will be passed without doing what you described during the leetcode interview

where there are much greater selective pressures in India and China to excel at this than there are in the US, raising this irrelevant bar to absurd territory if you value your time

Is there any evidence that candidates who do well on design interviews but fumble on leetcode would be any worse at the actual job?

people who cannot leetcode - a simple data structures & algorithms inteview - cannot understand runtime nuances of what they write.

This is how you end up with N+1 algorithms and exponential runtime.

For example look at all modern front-end in javascript - usually leetcode is more relaxed for front end, and you end up with ungodly gobbles of unnecessary loops inside loops wrapped in loops that traverse DOM for no good reason and freeze the browser.

it is the javascript people who import node libraries that contain 3 lines of code, instead of writing it properly

Primed recall can remain strong for many years, but leetcode often penalizes googling around to refresh your memory, even though that is what almost everyone should do before taking any further steps toward an implementation. Depending, it's often also the correct thing to do before choosing a library, the parameters to a function, code base organization, and lots of other details.

Of course, domain experts may be very strong in their specialty, but that's a special case with narrower scope.

I can hypothesize that testing for a "fast study" may have more predictive power. I have seen some interviews that are designed for this, leetcode adjacent but less antagonistic.

But anyway, I am spitballing, to be real with you.

You thought the point of leetcode was to simulate live work conditions? lol

Imo this process is flawed though because just one or two rounds of technical interviewing gives you enough information about whether the candidate can code. After that you need to understand how the candidate thinks since most of the job is spent doing things that aren’t coding. These are better probed by design questions, asking the candidate to critique some code, asking the candidate to explain a project from their resume and then propose alternatives and trade offs.

Too often you get people who pass this interview process that can code at a basic level but hinder your team by giving poor feedback, having a fixed mindset, being a bad communicator, not being able to unblock themselves etc.

It’s fine if you are just looking to grow a new grad though, although former interns are better.

Microsoft and Apple were the first companies to understand this truth so deeply, so I'm not surprised Apple is still into these practices. If you are young, use them to your advantage; just - please go in with eyes wide open, because the industry doesn't really have your best interest at heart and never will.