I think people miss that you don't need to ace these interviews to get hired. It's just more data points that allow them to probe the exact depth and breadth of your knowledge, as well as your general thought processes and how you go about investigating problems you don't already know the answer to. You're not necessarily expected to answer 100% of the questions 100% correctly. I'm not at Apple, but still a fairly desirable position at a good SV company where I was grilled on some extremely arcane details of things I claimed to have experience with on my resume. Some of them I knew instantly, some I didn't but had a reasonable wrong guess and the interviewer(s) explained the right answer and we moved on. That was fine. They explained beforehand why they were asking what they were asking and were very clear that I wasn't expected to be a walking encyclopedia, though I definitely had to show that I knew how to find and use the right part of the right encyclopedia.
Additionally, looking at the list I'm pretty sure the interview were resume based, too. They asked such a breadth of questions because OP had such a breadth of supposed experience and expertise on his resume.
I am fairly certain every apple interview does not involve questioning the candidate about their PyCon experiences.
I see nothing wrong going down a resume and asking about each point. It certainly sounds better than the leetcode infested mess the rest of the industry uses.
> some I didn't but had a reasonable wrong guess and the interviewer(s) explained the right answer and we moved on. That was fine.
You would be surprised at the number of candidates who would start arguing with the interviewer. Being able to learn new things on the spot during a pretty stressful event, admit one is wrong with no shame and move on is a great trait to select for.
At the risk of sounding like Stockholm Syndrome, why is this hilarious? If you want to work at a top tech company, the bar is much higher.
First round questions cover standard CS undergrad curriculum and second round covers the depth of his background. I'd say he's lucky his second round is tailored towards his (presumably Python) background instead of his interviewer's background. Other than the question about HTTP2/1.1, nothing seem too absurd.
I think one thing to keep in mind is that this probably highly selects for "jack-of-all-trades" candidates while rejecting candidates that might have more knowledge / expertise in a particular area, when most likely the job is only going to require specialization in some of those areas.
I'll discount the second interview since that seems heavily prompted from the interviewee's experience, but the first interview asks pretty in-depth questions (for a junior) in both C++ and web development. Chances are, developers aren't being hired to work on both - so why not focus on one or the other, rather than potentially kick great web developers out of the process because they don't know much C++ (or vice versa)?
> "I think one thing to keep in mind is that this probably highly selects for "jack-of-all-trades" candidates while rejecting candidates that might have more knowledge / expertise in a particular area, when most likely the job is only going to require specialization in some of those areas."
FAANG-class companies do not want one-trick ponies or even few-trick ponies. At least in my experience, they explicitly want to hire not just for the current job but for the long term, which means selecting for highly-capable generalists with the ability to rapidly specialize in any area. And, having spent many years at a FAANG class company, they are right to do so. I worked on embedded systems, physics simulation engines, network services on a gigantic scale, RF related systems, etc. All that stuff one learns in college that many HNers say is useless, well, I found that I wound up using most of of it.
macOS is at least 20 years old, and Apple needs to maintain it indefinitely. They need engineers who aren't going to accidentally break things for the 100 million strong existing user base. Nobody rapidly specializes in Mac development, there is simply no substitute for experience in this area.
The results are pretty obvious and depressing when you see Apple throw engineers at the Mac who don't understand the Mac. Low quality, bugs, constant accidental breakage, bad design in opposition to the platform standards.
Not every engineer can work on "the next great thing". You need a lot of engineers to work on the old great thing too. A mixture, a balance of engineers is important. A company gets diminishing returns from having all jack-of-all-trades engineers.
Google is the absolute worst at this. They're constantly creating new things... and then discontinuing them a few years later. Their follow through is terrible. Nobody wants to do long-term maintenance. Even though most of Google's revenue comes from the old things, such as search. (My impression that Google search is actually less accurate and useful now than it was 10 years ago.)
People love to make sports analogies, so here's mine: imagine a football team that put 11 all-star quarterbacks on the field. They would be the worst football team in the world. Every team needs role players.
I think this is the opposite of how FAANG or FAANG-like companies treat the hiring of SWEs. They don't want people to specialize in any particular area. They want engineers who can be freely moved to whatever product line or team has a need for years to come, possibly working on fairly greenfield stuff that nobody has pre-existing expertise on. But deep knowledge of the fundamentals of computing and software engineering are non-negotiable.
They're looking to build a maximally deep bench even if you don't meet a specific immediate need they have. It's sort of like the dichotomy you see in pro sports draft philosophies, where some teams focus quite specifically on finding players who fill existing holes in the current roster and some teams just try to draft the most talented person possible even if they can't figure out what to do with them right away.
The sports analogy is not great, because tech companies can't trade engineers to fill a need, and there are no multi-year contracts, so any engineer can quit at any time.
There's also no hard industry-wide salary cap. With the salary cap, the best way to maximize your overall team performance is to get superstars under contract when they're young and underpaid, because a team can only afford a few veteran superstars. Also, sports teams have a hard roster limit, whereas big tech companies can hire as many employees as they like. The analogy breaks down in so many ways.
The analogy is with the dichotomy in incentives between teams that have to win now versus teams trying to build for the future. Some companies need you to hit the ground running because they are presently making no money and need to get a product out the door as quickly as possible. Some companies are going to make more money than God next year no matter what and are more concerned with ensuring they'll still be in a dominant position ten years from now. That affects the kinds of candidates they're looking to hire in terms of narrow specialists versus generally talented people, independently of any constraints in the candidate pool and compensation markets.
Again, the sports metaphor breaks down, because winning and losing is a zero-sum game, whereas companies aren't necessarily playing a zero-sum game. Moreover, a team's draft position is inversely correlated with its record, so there's an incentive to "tank" to get better draft picks. ("Rebuilding" often means getting rid of your expensive best players and intentionally losing for a while.) No such analogous situation exists in business, it's just an arbitrary effect of how sports leagues are organized. It's actually designed that way to encourage competitive parity among teams, prevent any one team from dominating forever.
It's also that they don't necessary hire for specific positions. They know they'll need 500+ junior devs by next year so they can afford to hire then determine placement.
It's also why they are frequently the firsts on college campuses.
> First round questions cover standard CS undergrad curriculum
Hard disagree. Out of the four bullet points, 1 and 3 are standard CS, but 2 and 4 are hands-on programming and engineering topics that you don't get from college. 5% of graduates might know about all these details, 95% won't.
Of course that's fair if you want to be selective.
I've also found salary is not tied to interview difficulty. I've got really high job offers easily (3 hour on-site), and struggled to get the low paid ones because they're technical interview process is difficult/ boring (8 hour project work). Having said that, I think its more common to find higher salary paying jobs to be more selective/ difficult.
If there was perfect proxy for good people then $BIG_TECH would pay barrow of money for this.
10 years of experience says that person probably have seen a lot of software / projects / decisions and stuff.
Of course you could maintain one system for 10 years and struggle in new environment, but also there's difference between maintaining CRUD app for 10 years vs maintaining Linux kernel
For technical experience it's not a good indicator, for interpersonal experience it's spot on. It's easy to avoid doing anything technically difficult, but interpersonal situations arise unavoidably at a set rate, providing experience that you can't accelerate by having a weekend coding hobby.
Lots of questions are definitely for Senior level engineers or even devops, i.e. - "HTTP 2 vs HTTP 1.1". There is nothing useful for junior level developer to know the difference of such low level things. Anyway, junior engineer will have no chance to decide what HTTP protocol to use in his project in Apple.
Another example - "NodeJS event loop internals". Nothing useful for junior, senior level+ is assumed, if you want squeeze out of maximum performance from NodeJS V8.
>Lots of questions are definitely for Senior level engineers or even devops, i.e. - "HTTP 2 vs HTTP 1.1"
I think this kind of question just shows whether you're interested in web or not, because I bet that you could read differences between those two in 10min from some summary or RFCs.
Everything depends on how deep understanding between those two you had to show.
Even if you know differences between HTTP 1 and 2 it will not help you with web developement at all. In some rare cases web engineer can get performance boost for client to load data more quickly, but usually nobody cares about this.
Because most companies view seniority as a function of your domain experience, not your broad knowledge of generic CS, so you won't be considered for Senior positions without the right amount of experience.
Because most of the good free software hasn't been written by people at top tech companies. Because many people who pass these interviews write bad software.
Why is this scope of the interview a problem though? The intention is to get a good impression of the abilities. It doesn't mean you need really to do a perfect 100% on all questions and know every single detail.
And then, after interviewing a couple of candidates, they can choose what they do, or where to set the actual bar. And probably they also have certain priorities.
And I assume there actually are junior people who have experience in all the listed technologies. Maybe not so many, but there are. It's not so uncommon that you play with technology already during school.
>The intention is to get a good impression of the abilities. It doesn't mean you need really to do a perfect 100% on all questions and know every single detail.
Hopefully that is being conveyed to the candidate as well because if you're in an interview for hours, being barraged by a lot of technical questions and not having any proper answers to them, it's pretty much soulcrushing.
It hasn't happened for a long time but I remember, many years ago, being repeatedly frustrated by attending job interviews where I was questioned about languages/skills that clearly weren't listed on my CV and/or where I'd been clear with the recruiter up front that I had no knowledge or experience in these areas.
E.g., even now I have next to no knowledge of Python because I've never used it in detail. Nor do I claim to have done on my CV. An interview where I get asked "Lots of Python" questions (see the second round section on OP) isn't going to go well, and even as a veteran engineer with a fairly thick skin I'm not going to be terribly happy about enduring it.
This kind of problem is exacerbated if your interviewers haven't done sufficient prep so, instead of realising that you don't know anything about a particular technology, they take your poor performance in that area as an indication that you overall suck.
I understand why companies ask these standardised batches of questions: we all know that IT is full of jokers who claim proficiency in technologies where in reality they have very limited exposure and skill. But if somebody's actually told you they don't know something then you're simply wasting your time and theirs, and creating an unnecessarily negative experience, by going through the motions.
The thing with Google is that, because so many people want to work there, there will likely be somebody in that mass of candidates that has reasonable knowledge in all those areas, and they can afford to be that picky. Most companies can't which, overall, I think is a good thing.
I've been in this spot a couple times, and one thing I found helpful was to ask if I could do the question in a language of my choosing, even if it wasn't in line with their lingua franca. The one that said yes turned out to be a pretty enjoyable interview, because we chatted a bit about how implementation details differ between languages and how X could be done in Y, and vice versa. The one that said no... I think I got a better signal of job suitability from that one question than anything else.
>This kind of problem is exacerbated if your interviewers haven't done sufficient prep so, instead of realising that you don't know anything about a particular technology, they take your poor performance in that area as an indication that you overall suck.
Absolutely, I've been on the interviewee side of this a couple times, so absolutely try to ensure I have a list of questions for the candidate, including a number of references to their CV and github (or other public code repo). I'm there to get a signal on their suitability for working here, not to stroke my ego.
> I've been in this spot a couple times, and one thing I found helpful was to ask if I could do the question in a language of my choosing
This is a great strategy and, as you say, if they say no you've learned something useful.
When we interview we always make it clear to the candidate that they can pick a language with which they're familiar. We tend to ask for "C-like" at the application stage but have some flexibility around imperative/OO languages. E.g., Python or Ruby might be OK, as might JavaScript.
Same here, but the downside with this is the interviewer might not be too familiar with the candidate's language selection and therefore miss out on nuances about implementation details. It hasn't happened yet to me, but we do have golang here and I'm not familiar with it at all and am picking it up on my spare time.
Absolutely. I try to convey this in my interviews that I do have questions, but want to keep it low pressure and the goal is to get an honest assessment of who you are. If someone gets a question wrong, I explain why and ask them how they would alter knowing the issue.
One thing I've found pretty helpful with this is a code sample demonstrating mutable default args in python. Most juniors and a surprising number of mids haven't come across this even after 2 or more years of experience with the language, so they're surprised by it. I then explain how the issue happens, and then ask them how they would fix the function.
For me, its those kind of questions where you as an interviewer are able to provide a tiny hint or nudge when the person is stuck that gives much more insight. They're not getting the answer, and are doing the work themselves but doing that in a bit of an unnatural environment like an interview makes me very, very happy for them. I had an interview with a candidate who didn't know python much, but liked it for its conciseness for interviewing, but worked in golang regularly. Candidate hadn't heard of this, and was surprised by it, and after understanding the reason behind the behavior, we ended up on a pretty enjoyable tangental discussion of how other languages had similar gotchas and the experiences thereof.
Conversely, when a person is interviewing for a role at a much higher level than they're qualified for and are missing things despite hints, suggestions and outright pointers, its a significant letdown, and I hope those candidates are able to use these questions as guideposts of where to increase their knowledge and awareness.
It looks like a lot of the interview is targeted towards the candidate’s CV, eg it surely isn’t a standard question to ask the candidate about their PyConf talks.
It doesn’t look like a real interview itinerary at all to me. Leetcode forums are filled with Apple interview experiences and none of them are anything like this. Also, I’m also a bit skeptical of the python bits, as I can’t recall anything but indifference from Apple towards supporting python. MacOS ships with a very outdated version of it.
I've been involved with hiring (although at a company that's far from a household name), and the second half at least, sounds perfectly reasonable to me. They've taken the stuff he claims to know in-depth and explored it. That's the perfect place to dig deep. You don't take someone who has PyCon on their CV and get them to do fizzbuzz on a whiteboard - and there's no point getting into the weeds on topics they haven't even mentioned.
"What makes this candidate unique" is the best place to spend the meat of an in-person interview - and the best place for the candidate to sell themselves too. Its usually far too late into the process to waste anyone's time with asking every candidate the same stock questions.
> You don't take someone who has PyCon on their CV and get them to do fizzbuzz on a whiteboard
Disagree. I’ve also interviewed hundreds of candidates over the last couple decades, spanning a half dozen or so companies, and there’s always been a rule of consistency. Giving candidates wildly different interview experiences introduces bias, at the very least, but it also makes it very difficult to select the best candidate among a pool. There is simply no way to compare each and stack rank them, you might as well pick one at random.
Thanks. In particular, "junior" (which is very vague anyway) doesn't appear anywhere in the post. Confusingly, the Reddit post talks about an "internship" at Intel while the person's website identifies them as "Software Engineer @Intel".
A ragetweet saying "what the hell did I just read" without linking to the source turned out to be about as useful as expected.
I think the interviews at apple had such big scope because the applicant had it on its CV, they had other good applicants so they have to really choose the best ones and/or they were trying to figure out what to offer him/her according to his/her skills.
There are many commenters who are going to write something along the lines of: "If you want to work at top tech company"...
However given the recent quality/stability issues of MacOS and IOS I suspect more technical brain power is not what Apple needs. The "stability" of Catalina, and the roll out of Big Sur left a lot to be desired.
I would not attribute this to Apple's hiring process. It is very easy to have excitingly talented people being dragged down into oblivion by enterprise management decisions.
It means they should start trying to hire competent people. What I’m seeing in this list is more like: Did this person study CS and actually remember everything, and did they happen to look through a bunch of normally irrelevant stuff for shits and giggles.
Much of this seems to be asking questions about things the candidate has experience in? We don't know what either job they applied for was nor what was on their CV.
Yeah strongly agree with this. I suspect there is missing context in the tweet. It might have been that the position was something like “engineer on some language runtime/compilers team,” or that the candidates cv had a bunch of stuff about low level python/c++ implementation details.
Another reasonable hypothesis is that the candidate was just very strong and kept getting asked more questions. Eg maybe they are asked some question about c++ semantics or stl and this develops into discussing details of vtables and suchlike. Or maybe they are asked a general question about python performance and this develops in the expected direction towards discussion of the GIL, and then further into discussion of other runtime details.
It feels totally random that there’s some discussion of tail recursion next to knapsack problem. That feels to me like eg the candidate or interviewer makes some reference to it and there’s some discussion, rather than the interview being about tail recursion. Similarly, maybe the interview was maybe about 0/1 knapsack but the candidate solved it faster than expected and discussion moved on to fractional knapsack and then random time fillers.
Also note that there’s a few points where there isn’t much discussion. Maybe a different candidate could have had a lot more interesting things to say about the system design question about ratelimiters.
Maybe I’m wrong and this is illustrative of Apple’s minimum standards, but I would guess that it’s some very strong candidate who’s doing a lot of technical interviews and writing down experiences.
Came here to say this. Despite everyone being like "oh my god it is so much skill needed for a junior position", we should be asking ourselves if that was maybe because the application had an exceptional CV? From the twitter post it seems like most of what they asked during the 4hours was something the application had proficient experience in. Seems like a rather comfortable experience?
Indeed, people are freaking out about it, but honestly going down your resume and elaborating on each piece sounds like heaven compared to fast paced white board coding challenges.
Well that’s what it takes to compete at that level. If you want to work at Apple, learn a fuck ton of programming. If you want to work in the National Football League, learn to throw a football at 50 miles an hour with 3 inch accuracy while both you and the target are being chased by big strong men.
If you get a job at FAANG, you are pretty much guaranteed to be employed for the rest of your life due to the weight the names of FAANG carry.
Sure, other companies might offer similar challenges but if you've only worked at a random company X, it doesn't give you an advantage in future job interviews. Name recognition is more important than some realize.
As someone who worked at a FAANG and still struggled to find my next job, I can tell you that this is absolutely not necessarily true. It may moderately increase the number of recruiters that spam you, but in my experience, it did not otherwise make it any easier to find a different job. You're going to still have the 100:10:1 ratio. You're still going to get whiteboard-hazed. You make it sound almost as though you can just waltz through the door at most companies, simply for having worked at one of these FAANG companies in the past.
Yeah, pretty much this. I can't stress enough the difference living in a hot area for tech, having a famous school or some big names in your resume makes in attracting recruiters from top companies vs working for some random mom and pop shops in a unknown city.
It used to be like that, but these days I often encounter the opposite, with ex-FAANG people having stigma attached to them, though arguably mostly google. FB is I think second in that.
I once applied for a job at medium-sized startup, passed their phone screen, take home assignment and onsite, and then had a meeting with the CTO where I was told that they have had problems with ex-Googlers before, and then was rejected after that conversation.
That seems like a very narrow minded approach. I’d be concerned about applying to that sort of company just by hearing that they apply nonsensical filters like that. Can you give some examples, since you claim there are multiple?
Outside (even more outside USA), and also in terms of workplace environment "feeling" and choice of projects, things get a bit different.
Is there still clout? Yes, definitely. But it stopped being automatic badge of merit, at least according to friends who either work(ed) in FAANG companies, or were on the other side of recruitment involved.
No but that’s not true of the NFL either. For every Tom Brady there are a thousand guys who play for a year or two, make $1 or $2 million, and have to figure out what to do with the rest of their lives. But even getting to that level momentarily takes a ton of talent and hard work.
> ... there are a thousand guys who play for a year or two, make $1 or $2 million, and have to figure out what to do with the rest of their lives ...
What poor, unfortunate souls. Whatever will they do with their millions? /s
It does take a lot of talent and hard work, but that doesn't mean people who are working elsewhere (places other than Apple/Facebook/Google) aren't working hard or don't have talent.
It's as if the argument is: unless you work at a FAANG you're not hard working or talented. Much like people who believe a video game isn't a video game unless it's released on Steam. BS.
This is very hard on people who are already employed. Who wants to work 2 jobs simultaneously? The pay of a short-term contract is basically nothing compared to the pay of a full-time permanent job.
Suppose I apply to 20 places, and they all want me to do this? It doesn't scale at all.
They pay very generously for your time and have a long deadline. I’d much prefer doing that than going to 20 one day interviews with nothing to show for it at the end of the day.
That seems to be jumping the gun. You don't normally get an onsite immediately, you usually have to go through much shorter screens, the first of which may only be an hour max. So you don't necessarily waste a lot of time on any one company unless you go deep into the process, and you're probably going to be screened out early by lot of them. The take home assignments are generally supposed to be replacements for technical screens, but they invariably take a much longer amount of time.
There's also an investment differential. Every hour that a candidate has to spend in an interview is also an hour the employer has to spend in the interview. Whereas an employer can send you off with a take home project for an indefinite number of hours while they sit back and do nothing. Are they going to spend the same amount of time reviewing the project as the candidate did writing it? Extremely doubtful.
Many companies have similar project based interviews without pay. This is typically not part of the application process, but rather the last step in the interview process.
Four hours is on the low end, even for regular companies. Online assessments, phone screen, on site, various calls with hiring managers and internal recruiters, post-interview follow-ups, all combined can easily push up to 8 hours or more over a few weeks.
> Maybe it's because I'm old but I'm not doing 4hrs of interviews for anyone.
Really? That's your complaint? As far as interviews go, I can't see anyone but yourself complaining about the length of interviews these days. It's usually the ridiculous breadth of knowledge required (on the tip of your tongue ready) that people get upset about.
If anything, I'm usually wishing interviews with companies were longer so that I could assess the culture better. It's very hard to get a feeling if a place is the right place to work when you spend 85%+ of the time in interviews talking about yourself and then answering some leetcode/design/tell-me-about questions.
I once considered looking into some more niche FAANG positions, including some at Apple. Probably won’t make it. I just don’t have the time / capability to learn this stuff vs the domain knowledge for the positions I looked at. If I knew ahead of time what questions would he asked for why position maybe, but given again that the stuff I was looking at at the time was domain specific, not like Glassdoor will really help.
OP on reddit says that two of his offers got revoked! It must be so frustrating to give hours of interview successfully but still not getting that job.
Once you enter a big corp, all that CS knowledge they ask you gets flushed quickly and replaced with learning various internal tools, processes and corporate idiosyncrasies which are unique to each team/project/company.
Compared to Google, Facebook, and smaller companies I interviewed at, Apple was an outlier in terms of quantity of interviews. I was interviewing for a build engineer role, which is sort of DevOpsy as I understood it. More ops than dev. It was located in Tokyo.
Boston: 30 minute technical interview at career fair
2 back-to-back technical screen over phone
Tokyo: on-site with ~4 one hour technical interviews
Cupertino: on-site with ~4 one hour behavioral interviews
1 or 2 more phone calls with higher level managers (would have been in person, but COVID happened at this point)
I ultimately did not get the job, either because I was kind of a stretch in several ways or because of COVID.
Out of curiosity, I've looked at Apple's jobs page and it is... something different. There's plenty of self-aggrandizing BS that you'd expect from them, but the most basic info is just missing - e.g. they don't even provide a list of locations where they have job openings... This page is the most "design over substance" that I've seen from them.
Is their success rate zero? I don't think so. People want to work at FAANG so much they can afford to raise the hiring bar to hire someone with intermediate/senior knowledge on junior level.
Doesn't seem unreasonable to me... I think I'd be able to take a good crack at demonstrating understanding of all those things to the level of detail you can get to in a few hours of interviewing. I doubt I'm the only one.
