throwaway_95014

tl;dr : "Hi, I have a blog and it's taught me nothing about virtual memory".

http://www.linkedin.com/pub/gerard-williams-iii/a/95a/278

Dealing with both timekeeping and interrupts on x86 systems is awful. Anyone that thinks that the x86 interrupt architecture is "just fine" has rocks in their head.

Say I've been at Obvious Company for a while. Maybe a long while. LinkedIn, Github, none of these things have anything on me. I can't talk about what I've done in the last couple of years because it's all still confidential (and I'm not ratting one employer in front of a prospective - I'd like them to think I can be trusted).

How do I convince you that I'm enough of a rockstar (and I am, for reals) to get a foot in the door? I can blow your socks off in an interview by fixing your product and your business model on a whiteboard, but until we talk I'm just another pasty white guy in an ironic shirt.

You aren't going to recognize the schools I went to, or care, because I was out before you were eating solid food. I don't even have the beard and suspenders. How do I sell me to you?

"modern" headset remotes that work with devices from a major vendor have long since abandoned the analog resistor approach in favor of a digital system.

The details of the implementation aren't disclosed, but people have seen a whiff of it, e.g. here:

http://superuser.com/questions/107378/what-is-the-apple-mike...

I don't have a 'real account' to post from, or any desire to associate any comments I might make about working at Apple with anything else I might choose to say.

In general, the company prefers to set the message itself, rather than trust to the vagaries of personal eloquence and interpretation. For myself, I'm not sharing anything here that you wouldn't expect to hear in an interview if you asked the sort of questions that are being raised here.

Congratulations on your offer and acceptance. Honestly, don't put too much stock in anything you read about working at Apple - your experience is going to be unique, and the worst thing that can possibly happen is that you'll decide it's not for you and move on with an excellent first slot on your resumé.

To *_95129 above; I have a slightly hard time accepting that you really had no idea when (or if) your project was going to ship. If there's one thing that every software team knows, it's what train(s) they're shipping in.

To be honest, if you're the sort of person that expects people to tell you things you don't need to know, you're likely to be the sort of person that wants to pass on all those things to other people that don't need to know. That may work elsewhere, but it's not a good attitude fit for Apple.

As for the bigger picture; obviously there isn't a simple answer there. Many pieces of various big pictures are completely out in the open. Others are kept under closer wraps until they're ready for the usual reasons. But it's really not the simple, bleak story that you're telling.

One reason you don't read many ex-Apple employees talking about the process is that it's complicated, and simple soundbite answers are hard to come up with.

The culture of secrecy thing is greatly overplayed by the media precisely because of the visceral reaction that you display. In reality, if someone needs to know something, they can know it. If they need to reach out to someone with a specific skill set, the resource can be disclosed. The need-to-know policy is accepted and respected inside the organization because it works, but the key point is that it does work.

The amount of cross-pollination between engineering teams is actually very high. There are certainly areas where access to specific projects is constrained, but in general the culture is very open. Sharing of code and team resources rather than duplicate development is the norm, as is tight cross-functional integration between teams. At any given time you may not know precisely what your peers are working on, but this is different from not knowing who they are, or being able to talk to them.

I have a hard time seeing Apple-the-engineering-environment as either decadent or miserable. Apart from being a bit tight for office space and having rather too much carbon fibre in the parking garages, the company is incredibly focussed on doing the job and doing it well, which doesn't sound much like decadence.

Likewise, it's hard to see what's miserable about working within Apple. The company is always doing something interesting, and it's very pragmatic about it. Projects don't get killed "on a whim", they get killed because they're a bad idea, or they don't work, or they get shelved for a year, or three, or more until the rest of the technology catches up. If you are obsessed with shipping "your thing" that might be depressing, but if you want to ship something good, knowing that you aren't going to be chained to a turkey for five years just because some suit would lose face otherwise can be very refreshing.

As an engineer, working for Apple is actually pretty amazing. The company has very little of the management BS that is prevalent in other large tech companies. Most engineering decisions (how things should work) are made by engineers; many new features are the direct result of an engineer saying "what if we did this?", or "if we stack this and this and this together we could do that"; most of the engineering management team are ex-engineers and thus well-calibrated; the toolbox and scope for attacking problems in new ways are both enormous; "that would be hard" is not usually an excuse for not doing something; "that would be stupid" is usually an excuse for not doing something. Engineers, even new hires, have a very high level of personal autonomy and corresponding responsibility; your role is largely what you make of it.

On a routine basis, the stuff you work on turns up in real products that people use and love. If you actually enjoy making things, that's all kinds of awesome.

tl;dr: If you're considering working for Apple and the fear of being locked into a box is putting you off - that's not how it is.