Getting a job at Apple without going to college or doing LeetCode
aheze.substack.com
aheze.substack.com
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.
I'm glad people aren’t just continuing the practice simply because they experienced the practice.
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.
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!
If it's making you so stressed out as you claim, then the obvious step, to me, would be a change of scenery.
I have worked an average of 40-hour/week jobs for my entire 30-year career. What's this "demand" nonsense?
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.
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
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.
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.
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.
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.
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.
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.
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 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.
it will open many doors :)
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.
If you can make that much remote out in Nebraska then sure, fine.
There are people doing a lot worse. But when doing much better looks like that, what even is the point?
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.
main point being is that if your income doubles, your savings rate will double, but your work related stress will double, and arguably your health (mental and physical) will deteriorate at 2x faster rate
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?
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'.
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.
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.
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.
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.
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.
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 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
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.
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.
or overwork with boat load of feature requests and bug fixes and Ops workload - this is the reason why faang's offices are so fancy, have free food, laundry, massage, and bunch of other stuff.
These fancy offices are for engineers to pull all nighters, not for tiktokers to show off in social media.
if you are 9-5 with 5 kids - you are not gonna make it in venture capital funded Silicon Valley world. 9-5 is for regular "enterprise" engineers at Initech or Dunder Mifflin Paper Company in Lubbock TX
Serious question, not rhetorical, in case it doesn't come across.
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.
As a parent of young children, I think this is greatly exaggerated.
If you're a skilled developer with several years of experience then you shouldn't have "grind" leetcode for 10s of hours per week for months on end. It's trivial enough to do a few problems per week on a break or during some down time.
I think too many people refuse to even start because the difficulty has been exaggerated to the extreme. When I was mentoring college grads some of them would grind leetcode for months and months and even delay their interviews, then walk away dumbfounded when their interviewers didn't ask them anything resembling a Leetcode Hard. Many of them got questions that were basically Leetcode Easy questions.
They had all been convinced by the internet that they needed to grind Leetcode until they were miserable, but it's not really true unless maybe you're starting with almost zero knowledge of algorithms and data structures.
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?
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.
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
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.
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.
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.
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.
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.
Astrology persists, but that's not a testament to its efficacy.
You thought the point of leetcode was to simulate live work conditions? lol
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?
> "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.
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.
> 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.
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!
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.
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/
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.
That's not a requirement in the US.
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.
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)
Weird. Why would someone pretend that?
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.
I don't think "valid applicant" and "doesn't really grok strings/types" are compatible, outside of intern/maybe junior positions. The filter works.
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.
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”.
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.
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.
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.
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'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.
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.
- They may not have formal education, you can't judge on that.
- They may not have active GitHub projects, you can't judge on that.
- They may not be active on social media or have any kind of fame, you can't judge on that.
- They may not have built anything they can show off like this `Find` app, you can't judge on that.
So what can you judge them on? LC makes that pretty simple: "can they answer some standardised questions about algorithms and data structures, showing that they have at least some basic knowledge of what's going on in computers?"
It's not without downsides, but I also struggle to see a better option that can scale to the armies of devs that Amazon, Google, etc, all hire.
As a grizzled veteran, I LOVE System Design interviews. I love giving them and I love taking them. At large companies, System Design is definitely part of the process. In the world of FAANG, multiple coding rounds with a System Design is common for more junior developers, where a senior interview would have multiple System Design rounds with a single coding round.
> They require knowledgeable interviewers of course. In my round of FAANG interviews, the best System Design rounds were at Google. One was a more typical "design service x" scenario, and the other was "improve and upgrade service y w/out any downtime". Both were related to technology there and were things the interviewers played major parts in designing. Awesome conversations all around and I'd probably do them again just for the fun of it.
The most awkward one was at Facebook. The first design interview was good. It was a little uncomfortable because it was related to technical area I knew little about, but I enjoyed boiling it down to goals & principals and working from there and having the conversation with the senior engineer giving the interview.
The second was given by someone far more junior who was both an inexperienced interviewer and who had clearly not ever designed a system. It was obvious that they were going from a script, so there was little to no discussion or feedback about anything not covered. As a result, I "succeeded" more through guessing what was on the script vs. having an actual system design discussion.
System design has a ton of bias in it and it's my least favorite type of interview because of it.
The crux of the evaluation often revolves around have you built something amazing before? For most new grad folks it is the work done as part of their PhD thesis, but for non PhDs it often boils to amazing past work. And it’s a similar process for more experience folks except the reliance on LC fades even more.
If this works well for cutting edge ML why shouldn't it work for everything else?
On the flip side, I’m fairly sure the hardware / system software teams have rigorous hiring processes.
GP didn't seem to be saying they didn't think about that software. They were saying they didn't have a good reputation, which is true.
Apple is actually astonishingly bad at software considering the amount of money they have to do it properly. Even Google eventually got Android to a place where it's very resilient and rarely buggy, but iOS has bugs for me almost daily where I have to reboot to fix it.
Siri being bad is probably more to do with data collection / privacy. I’ve not looked into it, but that’s my assumption.
However some preinstalled apps on Macs are indeed terrible. Within a week of getting my Macbook I found ways to crash two apps with normal UI interactions. And it kind of baffles me how much the app for displaying pictures has trouble with opening pictures.
Currently entropy is getting to Apple in many ways. iTunes and Apple Music didn't use to be mediocre, but are now. Siri is very mediocre. OS quality is declining although still pretty good. Hardware division is excellent, but most hardware divisions are.
What did he get out of that in the end? Just more janitor work?
Unfortunately the only conclusion we can draw is that consumers don't care about:
- software quality
- bugs
- voice assistants
...and do care about:
- hardware quality
- integrated ecosystems
- cameras
- battery life
An ecosystem has stickiness, so many things go wrong, that people strongly care about, but the overall equation still tips in favor of "I'll stay".
The UI design went completely downhill in iOS7 with Forstall leaving and Ive taking over. I love Ive, but he's not perfect at all. Currently it's almost as if it's slowly, slowly, slowly recovering, but we'll see. Vision Pro's OS also shows some excellent design sensibilities, although the product as a whole is a solution in search of a problem.
Tim Cook needs a "product guy" to help him round out the management team. He was/is an insanely good COO, though.
My layperson friends seem not to know iOS has any bugs at all. They just seem to think software in general is flaky.
And all those complainers still keep buying these things, so they don't care enough to switch.
> Tim Cook needs a "product guy" to help him round out the management team.
Why? Objectively speaking, why does he need a product guy? The company has been performing incredibly well as-is, and that's all he cares about and all he's paid to care about.
Their brand doesn't seem to be suffering either, so they're doing well in the short and long terms.
Product design is, at this level, about your overall philosophy of product, and product portfolio, how they feel, how they fit together, and what is important, are we going pros, are we going consumers, why, how, etc. What do we want to see more of in the world, what is useful, how can we make it useful, and humane, and intuitive yet powerful. That's the product guy's job. Jobs, Ive, Forstall were product guys. Ive unfortunately kind of sometimes leaning into odd obsession with minimalism.
I care but once in a while I have this project I need to run Windows 10 for and I'm reminded the grass is greener on my side.
Same for Android tbh.
Edit: to summarize, Apple is still the least shitty option.
I only recently upgraded to Monterey and I find Apple Music borderline unusable in comparison. There are lots of tiny little bugs like how if you sort a column it no longer holds your position in the library -- previous versions would ensure that the song you had highlighted remained highlighted and in view. There's larger bugs like how Home Sharing doesn't work with wireless headphones.
(I have no point of comparison with other programs like Foobar2k, I'm just comparing how bad Music itself has gotten over the years)
On this point regarding the lack of leet code at Apple versus other big tech:
> Is it a coincidence that Apple was the only Big Tech company that didn’t do layoffs?
Yeah, I do think it's probably a coincidence. On the whole, a higher focus on leet code in hiring is probably a negative thing, but I doubt it has such big effects as to cause layoffs.
I actually prefer hiring and working with self taught programmers especially when it comes to juniors vs CS grads. They have less bad habits usually and a stronger appetite to work things out for themselves.
Though this could be just my own bias having not graduated in a CS degree, anecdata and all that.
I dunno, I don't think the size of their cash-on-hand account is luck.
And as others have said, Apple does rely much more strongly on contracting than the rest of the Big Tech.
It definitely has pros and cons though: I've worked on a handful of teams at Apple and was very lucky to have been able to work on super fun and interesting stuff on all of them, but an outsider confronted with 1000+ vague listings on jobs.apple.com is effectively playing the lottery of whether they'll get to interview for a team that's a good match for them.
I find LeetCode type sites good for warning up my brain in the morning. I start one or two every morning and it really good for batting practice. As a tool for hiring, Im not so sure.
The same industry that will tell you how discriminatory standardize testing is, will also force you through a gauntlet of tests.
Do as I say, not as I do tech.
Good eye on the manager/employee, but it almost feels like winning the lottery.
The part that had me laugh a bit is:
> Is it a coincidence that Apple was the only Big Tech company that didn’t do layoffs?
I will say no it’s not a coincidence but it’s a direct relationship to growth and spend, like any heartless corp. Apple continued to have the growth curve they wanted so they didn’t need to. One day that will not be the case and they will fire people to keep it. The company is owned by shareholders
For example, I don't really want to code in my free time. I have long accepted that I don't care. I don't have energy for anything but small-size side projects.
I do, on the other hand, like solving puzzles, so LC is somewhat preferable to me, out of the two choices. To each their own.
1. They're inherently adept at problem-solving and can navigate these challenges with negligible practice.
2. They've got the grit to persistently grind through even the most monotonous tasks.
Companies are on the lookout for candidates exhibiting either of these traits. Personally, I'm not a fan of these interview styles.
I'm a bit surprised and in denial about this.
Maybe this was exceptional hiring practice during the COVID craze which has also resulted in most of the recent layoffs?
I say that simply because I've personally and of everyone I know, have never encountered an interview that didn't involve that.
That detail is so important, should be in the title.
Internships are the exception. Good grades, good projects to show, sometimes connections, and a bit of luck is what you need. Then good performance during the internship and being on a team that still has head count to make an offer at the end of it.
But internships tend to be ageist. If you're too old, or are past that fresh out of school phase, you probably won't qualify for them.
To be fair, and somewhat surprisingly, I never have personally or know anyone that applied at Apple. So I do have a gap in first hand experience withe regards to Apple specifically.
Still, I would be very surprised if it was so different.
And as another commenter responded to me, it wasn't, the position was for an internship, so it makes sense now.
So at least in big tech, it's been this way since prior to 2012.
It be interesting to know when the practice started, by what company and all the history behind it.
But it does seem like it's been around a long time at this point.
But then, one interviewer asked about a graph theory problem which the first step was to first find all the strongly connected components and group them to one, and then required a couple more non-obvious proofs of specific properties of the graph to get to the solution. Definitely significantly harder than the typical "leetcode hard" questions.
Uh, when are they supposed to have done that?
It's the classic failure of overshooting cutbacks, driving away talent, and harming future talent acquisition. This is generally an anti-pattern Apple avoids by neither overhiring nor doing layoffs and becoming gunshy with interns and hires. It's quite astute business acumen to avoid megacorporatitis.
It wasn't a job, it was an internship. OP is also planning to go to college.
A more accurate (and less shocking) headline would be: "Getting an internship at Apple before going to college".
It would indeed be surprising if Apple routinely hired FTEs with no undergraduate degree.
You do
Everyone has a kick for the survivorship bias. At the end it is just that.
How about other who made similar apps? How about all those aspiring game devs who actually put games, web developers who launched products or even some guys who made something apple would want?
The OP managed to get lucky.
I came into Google through an acquire, and one where the usual interview process was waived. They needed us to continue working on the thing we worked on, and they went through our job histories and talked to our mgmt and slotted us where we would fit and for people that didn't "fit" they were mostly given 1-2 year contracts instead.
And while I lasted there 10 years after that, it really didn't do me any favours. Going through the process and succeeding would have been far better for me. A lot of people around me at Google had imposter syndrome, but I was an actual imposter; didn't do the interview, and didn't have a CS degree. Made worse by the fact that I was a site (Waterloo) where the vast majority of people -- including all the mgmt and site leads -- went through the rather rigorous program at U Waterloo, and were damn proud of it, and so ...
Just sayin', this is not a path I'd recommend. Google in particular is kind of run like a big university. Complete with their own equivalents of thesis committees (promo/calibration etc. etc.), an obsession with publish-or-perish, and campus cafeterias (and even equivalent of dorms). And their interview process is highly highly biased towards recent college grads who studied hard and recently in their algorithms and datastructures classes and are ready to whiteboard that up with confidence... It's a shared culture, with a high degree of conformity (that most of the people there wouldn't see/admit-to because of their conformance.)
I'm glad to hear Apple doesn't fit that mould entirely? Myself, at Google... if the money hadn't been so far beyond what I could get elsewhere, I would have walked after 6 months to a year.
Personally, I'd consider taking the joke reference to extreme pornography out of the article.
I'm happy for OP that his hiring process went this way, wasn't this also how John Calhoun got into Apple?
The actual answer to avoid leetcoding is to go through the frontend engineer route in the companies which don't leetcode frontend engineers.
From my experience everyone else ask for leetcoding.
Good for you found a preferential way in but from what I've seen process generally trumps on bringing friends in.
Do you have DEI metrics and objectives and if so, does that factor into the interview process and style?
I tried to make that in 2017, before Apple had their own OCR API. It was using Tesseract (via gali8/Tesseract-OCR-iOS) but the performance just wasn't quite there yet.
I asked the interviewer if it was typical work for someone working on the iCloud web app platform and he lied through his teeth, swearing it was.
I’ve got better shit to do.
More of this should be the norm not just for an 'intern' role where the bar is much lower but specially for senior engineers where experience on the relevant technologies should matter more.
Interesting. I have never done a single leetcode question. 70% of my job is writing backend code in Golang and Python with the odd bit of C and shell scripting every now and then.
What am I doing wrong?
If everyone start practicing leetcode and similar questions used in interview, then whole filtering talent process seems moot.
Now it's 8 years later. I am working at another FAANG, working on something far less interesting than I would have at Apple, have way less money, and am probably 5 years behind where I would have been if I took the job
Hmm? More reality distortion field?
I also personally managed to drop out of both high school and college.
> I remember that my manager specifically pointed out that he didn’t care about where I went to school or my GPA — he said something like “it only matters what you can do.”
And of course at some point in your career nobody should be asking for your GPA or school anymore because by then there should be much better ways to communicate your ability.
I got discovered due to my frequent shitposting in the comments section of TechCrunch.
I don't offer any career advice.
sure, they have extra time to see you work before the conversion, but its still very expensive to host interns, especially ones you aren't confident in converting.
Luck is definitely a factor in interviews. You can never be fully prepared even if you 100% match the posted job requirements, so you better hope your interview relates to stuff you are prepared for....
This is, of course, just anecdote, but one of them was a good friend who failed their internship interview and passed a fulltime interview just 6 months later, both at Google... so there wasn't that much of a skill difference in-between.
So you know what?
Massive congratulations to this student being so good that they don't need to take a LeetCode interview. Leetcode is not the only way.
Perhaps the ones that do have to take the coding interview probably haven't built something interesting themselves...
Either way, Leetcode, Hackerrank tests for hiring etc are all garbage. Great that this student's work speaks for itself enough to get an internship at Apple.
Well done for them!