Apple’s tech interview scope for junior position
twitter.com
twitter.com
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.
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.
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.
"Senior" has only a little to do with technical experience, and a lot to do with what could generally be bucketed into "work experience".
[1]: I'm talking in general, not about this specific person :)
Seniority comes mostly from experience 5/10 years
Of course some companies give senior titles for people with 2-3 years of xp, but I think we can all agree that this is big "XD"
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
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.
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 this might hurt our ego from time to time, it’s up to them.
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)?
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.
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.
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 why they are frequently the firsts on college campuses.
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.
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.
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.
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.
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.
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.
>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.
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.
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.
"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.
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.
Indeed. Is there any scientific evidence that tech interviews are better than random selection?
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.
A ragetweet saying "what the hell did I just read" without linking to the source turned out to be about as useful as expected.
The post also says “ I wasn’t too excited until 7th January 2021 when my recruiter called me again and said “Welcome to Apple!”.”
In terms of working at Intel, the post said internship ending December 2020, and their LinkedIn profile says, “Incoming Software Engineer @Apple”.
I agree the tweet wasn’t great, but there is info in the Reddit thread to fill in the gaps from the source.
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.
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.
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.
Competition at the top is supposed to be tough.
I don't think so. I would decline a position at Apple, Google, Facebook, LinkedIn, etc.
There are plenty of other companies offering problems at a similar scale that are equally as hard.
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.
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.
There was a time when IBM and HP were great brands to have on your resume - today, their reputations are much reduced.
This is simply false.
I've never been out of work. Ever.
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.
You can't really compare with an anonymous junior engineer position.
You get 2 assignments and get paid for both.
First one - write a feature implementation proposal
Second one - they pick a feature or an issue from their open source code on Github and you have to implement it
You get paid for the whole process, the work is remote, pay is equal across locations.
Is this supposed to be a pro or a con?
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.
Neither does a 1 day on-site interview process. Give me the home assignment any day. At least that’s likely to be some kind of fun.
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.
True, but in my experience I always get far enough to waste hours upon hours interviewing only to be rejected in the final round.
I’ve yet to encounter the take-home assignment where I get rejected (so far it’s a 100% success rate).
Someone either solidly sinks their chances in that time, or they’re adequate.
Maybe I’ve never been in a position where I had to pick between two great candidates, but then, either one would have been fine.
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.
Knowledge != smart.
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.
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.
we need more security related questions than algos
bad algo can always be rewritten meanwhile leak cannot be reverted (it may be insanely difficult)
I do wonder how Apple comp is in Europe?