Apple Developer Documentation Is Missing

I hear this argument a lot and I agree 100% that this is the reason, but I'm baffled about why developers feel like it's so hard to review someone's GitHub profile. I find them shockingly easy to evaluate, as in literally it takes about a minute. Here's what the process looks like:

1. Look at the project list, if it's all tutorial projects, you're already done. There's no use looking closer because you won't be able to tell if it's their source code or if it's copied from a tutorial.

2. If it looks like they have some real source code, apps or frameworks they've written from scratch, pick one and look for an important file. There's no trick to identifying an important file, in most cases the projects are small enough that it's obvious. (And if the candidate has large and complex projects, you've probably already identified an exceptional candidate.)

3. Once you've opened the file, I'm always stunned at how easy it is to evaluate. I'd say in about ten seconds of scanning I've usually identified three or so mistakes that roughly gauge that developers ability. In which case I'm done, unless I want to dig for some material to discuss on a phone interview.

4. If I haven't seen three mistakes, then we have an exceptional candidate, this is really rare (maybe 1 in 100), so we've already identified an exceptional candidate in about a minute.

One of the keys takeaways is that process only takes a long time for a truly exceptional candidate, in which case I'm happy to spend the extra time. I'm baffled by the preference for coding tests, because those I find way harder to evaluate. I know in my bones what production ready source code looks like, because I've written and read it all day, everyday for ten some odd years. Evaluating someones coding test is way more mental gymnastics and guesswork for me.

For the people who have experience evaluating GitHub profiles, but instead prefer giving tests, I'd love to hear how your experience deviates from mine. I know there's nothing special about my ability to evaluate source code, e.g., I watch my colleagues do it all day as part of code review.

Yeah, the "I have this memorized" no-questions-asked immediate implementation answer is ... fine ... but also always makes me wish I'd picked a different question.

It tells me they meet the baseline - they can learn well enough to at least be able to do this particular problem super quickly.

But it doesn't tell me any more than that, unlike the candidate who thinks for a pick, considers a few different approaches, writes something up, stops a few times to think about edge cases, satisfies themselves that they're covered, etc.

"Can you figure stuff out on the fly" is the test, not "do you have this memorized?" Fortunately, most people don't have everything memorized, so for now it's still a useful-enough filter.

The problem with alternative, past-experience-based types of questions is that most candidates are terrible at driving them. I would love someone to tell me an hour-long story of debugging something in a library, say - but usually, even with a lot of prompting, it's very hard to get much interesting stuff out of them.

So by putting some algorithmic questions on the panel too, at least they have a chance to show that they can code, even if they can't communicate much meaningful from their past experience.

HR wants the cogs that are flexible because they can cram them somewhere whenever the company wants spin down a team and move the personnel elsewhere. This is great for big companies that just need warm bodies to crank out crap however it's an inefficient process when you look at the lower level. You have a larger team of people that are less familiar with the task that a smaller team of experts could handle better and faster. If you can handle the schedule and direct cost hit of a larger, less specialized team, it reduces the later costs of needing to lay off people and hire new people. You can just move these warm bodies around somewhere else. A small specialized team is going to be a bit more riskier since once the job is done, are you going to have a need for these experts? Would they want to stick around doing something they never wanted to do? If a specific field is your core business, hiring experts is critical when starting up. But once youre a massive corp, you really just need boots on the ground to handle the mundane. College fresh-outs are usually the kinds of people that get drawn into these warm body kinds of jobs. They want blank slates that can crank out code, documentation, or whatever the pointy hairs need. If you really do consider yourself an expert, consider a consulting/contractor gig where you come in, do the specific job they really need, and leave with a bucket of cash.

1. You should file issues against Ember's docs! We have different experiences of it for sure. Even just as experience reports, I know the folks who work on it would love that.

2. The Ember TS stuff is in need of an update—desperately—as are my (several-years-old-now!) blog posts. Unfortunately (unlike Apple) none of those of us who work on it get paid to do so at the moment – at all, including docs. I'd love it if you opened issues against the ember-cli-typescript repo about specific issues/confusions you've had.

Every once in a while I think to myself, "I have a problem with OSX, I think I'll try to automate it with JavaScript for Automation (JXA)..." You know the rest.

The astounding lack of documentation is almost amusing. It becomes an adventure of trying to convert old AppleScript examples into JS, spelunking into GitHub and StackOverflow and general trial and error until I get something to work.

All this said, I'd rather have functionality without documentation, than the extreme of not launching an API without proper docs.

The solution of course - though Apple would never do this as it's not in their DNA - is to let devs add to their docs like PHP does. I'd be happy to add back a few examples to their site once I figured things out if that option was available to me, but right now there's really no central place for this besides random forums or starting my own repo.