Apple Interview – 1995

https://www.engineersneedart.com/blog/interview/interview.html

by iloverss • 4 years ago

238 103 4 years ago

engineersneedart.com

iloverss• 4 years ago

An ex-engineer recounts how they got a job at Apple in the 90's.

smilespray• 4 years ago

There are no ex-engineers, only recovering ones.

MontyCarloHall• 4 years ago

I should pause here and point out that an interview at Apple was an all-day affair. Pairs of engineers would meet with and interview me for perhaps an hour. The first pair of engineers might grill me on some esoteric topic like code design, afterwards the next pair of engineers would sit down and maybe cover programming language specific questions.

This took place in 1995, and sounds pretty much exactly like a technical interview panel today. Were people similarly disgruntled about the process back then? The author certainly doesn’t come across that way.

twawaaay9• 4 years ago

No, people were not.

What changed is the demand grew enormously and in response, as in every other business of life, a lot of people who only have passing interest in it got into it because it pays well.

So now you have companies have to sort through huge pile of mediocre candidates. This causes the process to be very noisy, a lot of screwed incentives and a lot of false positives and negatives.

Applicants are now hedging their bets and applying to multiple places means that they are unwilling to spend entire day in each one. And companies (those that do not understand how important hiring is) also have incentives to spend less effort on hiring.

And developers became much more cynical. Partly because of high demand they are aware of. Partly because companies do not treat them well (like not giving raises at a rate their potential salary is appreciating as the market and their experience changes). And partly because new generations are just much more disillusioned.

I had a person recently refuse to come to 2h interview. Apparently it was too much effort. Good riddance and thank you for saving my time.

Good news is that good developers can still easily find a good job wherever they want.

Bad news is that most people are not good developers and they don't even know about it because really good developers are so few and concentrated in relatively few places. In effect, most developers will never have a chance to work with one.

hasmolo• 4 years ago

i don’t think you’re wrong, i just think you may have lost sight of some external factors. in 1995, the market was naturally filled with folks interested in computers more organically. now, software writing is the modern “factory floor” worker bee position. interestingly, a huge part of the field can’t accept that we aren’t especially unique or smart, just able to tell a computer how to process inputs. we take this need to feel as if we are a part of the intellectual class, based on a rose colored glasses view of a time 20 to 30 years ago when the only people that worked on software were all staff+ enigneers. then we create this perverse concept of a “real” engineer, and that engineer is just way more willing to aquiesce to _any_ thing you do, and therefore is a “team player”.

telling someone to interview for two hours, having them decide that of all the offers of interviews they had yours was least interesting with the highest barrier to entry, and you deciding they were at fault isn’t going to help you deal with the modern realities of software, and how far we’ve come for our idealized version of where we came from

2143• 4 years ago

Bad news is that most people are not good developers and they don't even know about it

How do I know if I'm good? Like, before applying, so that I don't have to waste anybody's time.

jseban5• 4 years ago

Bad news is that most people are not good developers and they don't even know about it because really good developers are so few and concentrated in relatively few places. In effect, most developers will never have a chance to work with one.

Yeah and having an outstanding skill or performance is not important in an average company/organisation, and will most likely give you only trouble. Larger organisations are risk averse, optimised for stability and longevity. Not short term performance. It's not a sports team.

ricksunny• 4 years ago

Not an SWE here - I wonder if the process itself is seen as value-creating by either side, even if a job offer isn't placed? For example, discussing code design may keep the hiring party at the cutting edge / state of the art without having to undertake refresher training cost. The candidate also gets to understand where they stack in terms of hiring companies' expectations, and may opt to retrain as necessary.

(I'm reminded of the stories when FB was looking to make a smartphone pre-Oculus - it sounded like they were interviewing candidates but effectively getting design strategy consults out of them gratis, but that's probably more extreme than this).

lapcat3• 4 years ago

The author certainly doesn’t come across that way.

1) The author got the job.

2) The author has kept that job ever since, for over 25 years.

Perhaps that was the last job interview the author ever had, in 1995? So there would be little reason for the author to come across as disgruntled in 2022 about 1995. Though the author does go on and on about the "Andy" interviewer...

There's a certain irony to this, because Apple itself was flailing and failing in 1995, unable to produce its own new operating system, and had to acquire NeXT and Steve Jobs to come back and save the company from bankruptcy. So Apple's hiring process was not necessarily producing results.

joezydeco2• 4 years ago

I think the "Andy" interviewer was key, and was a set up the whole time to see how the candidate would really perform under stress:

1) Previous interviewers set up Andy as the toughest part of the interview, preloading the stress.

2) Andy comes last, when the candidate is tired

3) Andy hits you with that wall of stress. Doesn't matter what it is. The candidate gave Andy an easy task by admitting he was weak on something right away.

The answer didn't matter as long as you didn't fold.

mikelevins7• 4 years ago

I interviewed at Apple in 1987, and it was an all-day interview, but it wasn't much like the technical interviews I've done in more recent years--the ones characterized by brain teasers and whiteboard coding. There was none of that in my Apple interviews. They made me an offer and I worked there for ten years.

Now, we can't conclude from that whether Apple has adopted whiteboarding and brain teasers generally. In those days Apple did interviews the way they did everything else: each group at the company did things their own way. I don't know whether that's true anymore; I left Apple in 1998. All I know is that I interviewed with them again four or five years ago, and that was a lot of interviews over a couple of days, but still no whiteboarding or brain teasers.

The first time I encountered what is now referred to as the technical interview was at Microsoft in about 1990 or 1991. I bombed it. Turns out I'm worthless at whiteboarding and brain teasers. They gave me an offer, anyway. Two, in fact. I turned down both. Microsoft would have made me a lot of money, but I didn't want to work for those guys.

That pattern repeated several times over the years: bomb technical interview; get offer anyway. Finally I just stopped doing it. I don't like it and I don't think it measures anything relevant to my work. If it did, why would I get offers after bombing those parts of interviews? Why would most of my employers be people I've worked for before? Why would they ask me to work for them again?

So, generally speaking, I just don't do those kinds of interviews anymore. If you believe in them for hiring, knock yourself out. We're not a match.

chrchang523• 4 years ago

It sounds like you're misevaluating your technical interview performance. You can feel like you're "bombing" an interview, while still performing above expectation. Some interviewers ask hard technical questions, don't expect most candidates to complete them within the allotted time, and give "hire" recommendations for some (but of course not all) that don't.

twodave4• 4 years ago

I can’t speak for anybody who made you an offer, of course, but often these kinds of problems are just another way to witness first hand how the candidate goes about solving problems. Failing to solve the problem given a short window of time is indeed not relevant, but your problem solving process is _extremely_ relevant. I’ve spent a lot of time fixing crap because some engineer was engaging in “magical thinking” that the cost of not doing such screening is clear. Brain teasers can be hit or miss, so I don’t particularly like giving those to candidates (though as an interviewee I loved them), but you can get a great idea of someone’s appetite for doing the mental work of problem solving through a thoughtfully-designed code screening.

BeetleB• 4 years ago

In those days Apple did interviews the way they did everything else: each group at the company did things their own way. I don't know whether that's true anymore;

It's still true.

rsanek2• 4 years ago

Does anyone even do brain teasers anymore? I recall them being popular 5-10 years ago but when I did my last round of interviews I didn't get a single one (across full interview loops with 6 Silicon Valley companies)

rockyj2• 4 years ago

I would take a 1 day multiple round interview any day. Nowadays, it is like -

- Recruiter reaches out on LinkedIn. You reply.

- Call with recruiter, repeat every thing in resume. Recruiter says ok, sometimes they just say we were looking for X years in Python to a JS programmer.

- First call with a manager (after 1 week) to check fit.

- Take home programming assignment (spend 4-6 hours on weekend).

- If code review is ok, another call to discuss the solution or improve it (1 hr, after 2 weeks).

- Last call with senior manager (1 hr, another week wait)

- HR offer

All in all, it takes around 6 weeks and multiple calls (not to mention doing this for multiple offers). Worst case - you fail at the last round, or code is rejected due to some crazy reason and yes, even after all this you get a 10% raise :D

yodsanklai2• 4 years ago

My experience is:

- recruiter calls and brief about interview process

- take screening interview (algorithm)

- go on site for 5 more interviews (algorithms, system design, behavior)

- failed, and study leetcode for 2 years

- reiterate

-> 100% raise, $10000 sign-on bonus

Overall, this is the best ROI of my whole life

deepGem• 4 years ago

My first interview out of college in 1999-2000 was something like this. A full day interview about designing the components of a TCP-IP stack interspersed with some personality/behaviour interviews. End of the day, you either knew you had an offer or you didn't. I had an offer. I would kill for such an interview experience now.

The last interview I attended stretched across a month or may be more. Glad I got the job but boy what a nightmare.

If someone told me today that I would finish all rounds of interviews in one day and this became a standard, even figuring out for hedging I would take a week off, schedule 5 interviews and be done.

Even fundraising for a startup doesn't take 2 months these days, whereas an interview will. That should tell you how broken the process is.

duxup• 4 years ago

Kinda depends on who it is and how it goes.

Provided I'm a significant way through the hiring process spending a day in person with people who seem relevant to he job would be fine provided I liked the company / had confidence in the process / liked the job.

A family member recently applied for a job and got invites for 12 hours of meetings over 2.5 weeks. No sense of where they were in the hiring process. No significant questions had been answered about the job. At least half the people in the invite were not directly involved with the job / HR types ....

I think what people get upset about is how seemingly meandering these interviews are now / interviewing with people who don't know jack squat and so on.

zerr• 4 years ago

The content is the key difference - doesn't require months of leetcode grinding.

notakio• 4 years ago

I went through the Apple interview process in 2006, and would say that my experience was definitely not predominantly a "technical interview panel". It was an all-day event, to which they had flown me in to do, and though I was asked technical questions by some of the interviewers, many of them were more interested in how I handled stress, or solved "political issues". A couple of them were more interested in answering any questions I had about what working in the group was like, in a way trying to let me know what I was in for if I got the position.

I got the position, and stayed there for 8 years. I remain relatively close to about 30% of the people that interviewed me to this day, and that concern for letting me know what I was signing up for was genuine. The stress of the job was at times pretty high, and keeping a cool head under circumstances where everything was going wrong was absolutely critical. I saw a number of people who came after me, leave before me for that very reason.

Since then, I've walked out of interviews where I felt like they were wasting my time. But I've also often had the luxury of not really needing the jobs I've applied for, generally, so other people's mileage may vary widely.

It's the employer's job to figure out whether you're a good fit for the position, but it is the potential employee's job to figure out whether you want the position in the first place. Being able to get an accurate read on what you're thinking about going into (and spending a sizable chunk of your daily life doing) can save you a world of hurt.

morley• 4 years ago

though not the cleverest engineer, [I] was one that worked quickly to prototype new ideas and took on some of the gruntwork that not every engineer wanted to work on.

This is basically all I want from anyone I work with.

ozarker• 4 years ago

I’m a young engineer and I’m always happy to take on the grunt work to help the team as long as I get a little time to help on big picture stuff as well. I’m worried that I might be looked down on by more senior engineers who might think I’m just trying to avoid the more brain challenging work

ptsneves• 4 years ago

Very well. Grunt work is very appreciated and it not only allows you to start working without pressure it endears you to the other senior engineers as a can-do person. As they will feel grateful and released from the grunt work they might even start doing direct mentoring. They also will start to get to know you, with all the benefits it brings. That has been my experience in both professional as well as open source development.

benreesman2• 4 years ago

A nothing is “someone else’s problem” is hallmark of the true pros. Intermediate folks might run into a broken build and be stuck until the build team can unfsck it. The OGs just fix it.

Keep up the work.

baxtr• 4 years ago

My first manager told me: Grunt work is also work. Someone needs to do it. He was spot on.

What I observe with many founders I interact with is that they want to focus on the exciting stuff. Building the product etc. Most of them don’t want to be bothered with boring stuff like financial planning, which sometimes breaks their necks.

mpetrovich• 4 years ago

Anyone else remember playing Glider? As a young kid, I gladly lost countless hours trying to navigate a paper airplane through a Rube Goldberg mess of obstacles. What a fun, imaginative game.

Would be cool if there was an emulated version somewhere. Or we could borrow the author’s book and transcribe it to a modern language, ha.

fizfaz• 4 years ago

you can play several versions at archive.org: https://archive.org/details/software?query=glider&and[]=subj...

mproud• 4 years ago

Hell yes! It showed up on at least a few Shareware diskette bundles back in the day.

Apocryphon• 4 years ago

I think I played Glider on an educational CD-ROM perhaps, even one about air and science? Or maybe it was just a shareware disc.

tappdarden• 4 years ago

You are in luck. author open-sourced it.

https://github.com/softdorothy/GliderPRO

also glider 4.0 is there also. Along with some of his other games.

magic_hamster• 4 years ago

This was a great read. Some commenters discussed the nature of the interview, and compared it to today. But personally I get this feeling that this was still in a time when software was developed mostly in bubbles. Knowing how to code was far less obvious back then than it is today, and knowing the right stack meant you could get hired on the spot. Also, I don't know of it's nostalgia, the way it's written or something else, but it feels like a lot of engineering stories from that period have a certain sense of pioneering or discovery, while it's definitely far reduced today.

pierrefermat1• 4 years ago

I think this is just an artifact of the pioneers/total body of engineers: having the numerator stay relatively unchanged but with the denominator exploding.

rockostrich• 4 years ago

There's a recent novel by Tamara Shopsin called "LaserWriter II" [1] that gives off that "sense of pioneering or discovery" feel for all ~200 of its pages. I highly recommend it if you're looking for a quickish read.

[1] https://us.macmillan.com/books/9780374602581/laserwriterii

asah3• 4 years ago

can confirm all this, and more.

It wasn't until the late 2000s when programming became easy enough for the mainstream and you started to see "coding camps," upwork and the like.

In the mid-90s, you had crazy demand for development but needed to be a brain surgeon to get hello world to work, let alone a website to be remotely reliable.

There was no automated testing, let alone CI.

Source control was sometimes used, sometimes not. There were LANs but there was no "web" let alone SaaS apps - there were maybe 1,000 websites and Yahoo! listed them all in a list. It was like Product Hunt, but even smaller.

You almost have to wonder how anyone learned to code? and you'd be right for asking: it mostly happened in top-20 colleges and a handful of companies. I remember showing PhDs about PKZIP and having them not believe it was possible to compress data without losing information - I had to literally show them the (rough) algorithm.

Truly, it was a time of magick.

(I don't miss it: the pay sucked, people treated "programmers" like crap, it was often impossible to reproduce issues, and of course you could only work in an office with dedicated hardware. Compared with today, it felt like the stone age of software development.)

dopeboy• 4 years ago

If the demand was high, why was the pay so low?

thaumasiotes• 4 years ago

I remember showing PhDs about PKZIP and having them not believe it was possible to compress data without losing information - I had to literally show them the (rough) algorithm.

They were right; that is a well-known and trivial-to-prove theorem about lossless compression.

Lossless compression works because you only apply it to very particular types of data. It doesn't and cannot work on general data; that's why we have specialized compression algorithms for every different kind of data.

simonh• 4 years ago

I did a CS degree in the UK in the late 80s. The introductory language was Pascal running on a Prime Mini Computer. ANSI C had just come out, but none of us had computers. You had to book time in a lab. The Aztec C compiler we used was on a floppy disc and horrendously buggy. All the coding we did was minimal exercises.

I didn’t even hear of object oriented programming until the 90s, and actually learned how to write useful programmes in Perl and C on the Sun machines at my first job. I learned Unix from scratch from the man pages. It was a different era.

zwaps• 4 years ago

I wrote stuff in the mid 90s and I am pretty dumb

Today you need 11 frameworks to even write a hello world

coldcode• 4 years ago

Funny I worked there in 95-96 for half a year as a contractor (DTS), and the interviews were fairly simple, the hardest thing was looking at a page of source code and finding all the bugs. Otherwise most people knew the Mac software I had lead or worked on, so it wasn't a big deal. I left because I didn't want to be there when Apple crapped out as seemed likely.

Steve came back a year after I left. Oh well, I might have stayed there for 25 years too.

honkler• 4 years ago

I read it as – Engineer Sneed Art dot com

I'm too far down the rabbithole

sylens2• 4 years ago

I really enjoyed this read. The author printing out his source code so he could have a physical artifact signifying the end of the journey for that game really resonated with me for some reason.

de6u99er• 4 years ago

Thank you so much for sharing.

kblev• 4 years ago

Funny how I'm reading this on an app called Glider

Apple Interview – 1995

Related Stories