Live data from Hacker News

Getting a job at Apple without going to college or doing LeetCode

aheze.substack.com

91–100 of 399 posts

Re: Getting a job at Apple without going to college or doing LeetCode

#91
post #87

Earlier quoted context omitted.

> o Do they ask questions? 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 "requiremen…

If you ask me a question that boils down to “write a card shuffling algorithm”, I’m going to do less well because I’m being taxed by the thought of “Why is this person asking me to shuffle a deck of virtual cards?” During the interview, I’d probably just google “best algorithm for shuffling deck of cards in ”, and I’d tell you I was looking it up. If you tasked me with shuffling cards on the job, that’s what I’d do.

You could just ask, and we'd answer "it's just a simple problem so both of us can see what it's like to work together." You'd be surprised how many people show up who don't actually know how to write a for loop.

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

Re: Getting a job at Apple without going to college or doing LeetCode

#92
post #75

Earlier quoted context omitted.

I'm not going to defend "leetcode grinding" and its pathologies but TBF this is problematic: > "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 especiall…

> Sure, those statements (just use an existing library) are what you'll do in practice especially as a beginner 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 ou…

> 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.

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.

Re: Getting a job at Apple without going to college or doing LeetCode

#93

Earlier quoted context omitted.

I think it makes sense to use LC or something like it. Is there a better way to judge the 100 random developers who've applied to your position? - 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 of…

It’s simple: don’t hire devs by the army.

How is that an answer? Obviously they need bodies to turn the cranks. The machine must continue!

Re: Getting a job at Apple without going to college or doing LeetCode

#94
post #32

Earlier quoted context omitted.

I think it makes sense to use LC or something like it. Is there a better way to judge the 100 random developers who've applied to your position? - 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 of…

Especially for Senior Developers I think systems design questions are more interesting. They usually don't just have one right answer and you need to discuss the advantages and disadvantages of the different approaches. They require knowledgeable interviewers of course. Then again, I'm not working in a huge corp, so I don't know if this scales.

> Then again, I'm not working in a huge corp, so I don't know if this scales.

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.

Re: Getting a job at Apple without going to college or doing LeetCode

#96

This is just "one" experience, certainly not the norm. Even as an experienced engineer of 15 yrs I'd to solve leetcode (LC) style problems on the whiteboard a few yrs go. For better or worse (depending on whose perspective you see), LC allows companies to judge you based on a common framework of solving algorithmic problems using computer science fundamentals (data structures and algorithms) in a language of your cho…

Some of the highest salaries I know are in core ML at big tech or some of the foundational labs like Allen AI. While whiteboard coding interviews are often part of the process, it is generally pretty basic LC. 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…

Allen AI pays well?! Do they ever hire vanilla engineers or just researchers, applied scientists?

Re: Getting a job at Apple without going to college or doing LeetCode

#97

The problem is that "leetcode" is a definitely a thing that exists in "FAANG" interviews. 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…

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

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.

Re: Getting a job at Apple without going to college or doing LeetCode

#98

The problem is that "leetcode" is a definitely a thing that exists in "FAANG" interviews. 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…

The problem is though how do you evaluate for real work without a portfolio of experience? Real work projects take weeks - perhaps months - to design, build, review and release. How do you test for that, really? 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…

Refactoring is the best kind of test! It has a slight bias for programming languages but the bias can be mitigated by having refactorable libraries in many languages.

Re: Getting a job at Apple without going to college or doing LeetCode

#99

Earlier quoted context omitted.

Didn't the guy who made Homebrew fail his interview at Google because he couldn't invert a binary tree? That's a guy who has built a popular product in the wild and can clearly code but failed because of the leetcode barrier at all IC levels.

You sound like you're trying to make a point. Make a point.

I agree. Every hiring process will have false negatives. Pointing out every one doesn’t invalidate the effectiveness of the process

Re: Getting a job at Apple without going to college or doing LeetCode

#100
post #51

Earlier quoted context omitted.

Under Cook, Apple products have become bland and overpriced in most categories (the M_ processors are a huge exception), but it's also wildly successful. The stock price is 7x what it was when Cook took over. He's one of the most successful CEOs of all time. Unfortunately the only conclusion we can draw is that consumers don't care about: - software quality - bugs - voice assistants ...and do care about: - hardware q…

I don't agree customers don't care about bugs, software quality and voice assistants, you can hear them complaining in literally every forum for Apple users. 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…

I really respect Ives as a great product designer but not a great UI designer in my opinion. iOS 6 Skeuomorphism was taken to the extreme so that iOS 7 felt like a breathe of fresh air. Now everything just feels bland.
Post reply on HN