Apple Developer Documentation Is Missing
v4.chriskrycho.com
v4.chriskrycho.com
The problem with not documenting things is that developers like me are turned off before we start. I don't want to bend the platform so far that it breaks. I want the limits. I'm tired of reading stories about apps being pulled for using private APIs, or breaking in future versions because they're removed. I want to do things in a supported way so I can make everyone happy.
Right now, I can't even see the boundaries of what's possible, because nothing is documented. I don't even want to try to write for Apple platforms, because it's entirely inscrutable and unpredictable.
My most recent experience with Apple's documentation (regarding some iOS 13 API concern), left me with a sense of impending doom and hopelessness. After about 5 minutes I gave up and went back to playing the google/stackoverflow search game.
I have become very addicted to the quality of Microsoft's documentation for things like .Net Core & C#, and have found it virtually impossible to tolerate reading documentation from any other vendor at this point. A completely arbitrary but hopefully obvious side-by-side comparison:
Exhibit A:
https://docs.microsoft.com/en-us/dotnet/api/system.linq.enum...
Exhibit B:
https://developer.apple.com/documentation/coreimage/cicolor/...
CIColor.init(red: 0.0, green: 1.0, blue: 0.0, alpha: 1.0)
[[CIColor alloc] initWithRed:0.0 green:1.0 blue:0.0 alpha:1.0]Great documentation uses those examples to shine light on other features that go nicely with (in this case) CIColor or to highlight the right way to do common tasks.
The comparison given was totally unfair, as pointed out by another user. Let's look at something more similar to LINQ's Distinct function.
Here's the Collection Types page from the Swift book: https://docs.swift.org/swift-book/LanguageGuide/CollectionTy...
Here's the examples from the API page for Swift's Collection type: https://developer.apple.com/documentation/swift/collection
Or for Sequence, also full of examples: https://developer.apple.com/documentation/swift/sequence
It's very comparable and highlights the differences and lack of detail in Apple documentation well.
- Apple: https://developer.apple.com/documentation/coreimage/cicolorc...
- Microsoft: https://docs.microsoft.com/en-us/dotnet/api/coreimage.cicolo...
https://developer.apple.com/library/archive/documentation/Gr...
Apple deployed a new documentation system, and no one stopped to make sure all the "old" stuff got translated through.
I find Microsoft's documentation as unusable as Apple's, with the difference that nowadays I can hunt down the source code for dotnet core while Apple's source is still private.
The stellar user interface that preceded industrial design dazzle was pure software. Apple does many things, and one of them is developing software. It is possibly fair to say they are no longer doing software as well as in the past.
Apple has enough rabid supporters, they can lose the occasional developer to bad docs. Apple doesn't care or need to care. They are arrogant that way. Also, what other platforms? Android? A fair portion of iOS devs are also already Android devs.
Look, this is just going to fall on deaf ears. Apple isn't listening. Their machine is output only.
That's not really true. Apple is active on Twitter and actively reaches out to correct problems.
For example, when I complained that their Xcode beta hangs when you open a large file, an Xcode dev reached out to me and asked for a repro case. https://twitter.com/theshawwn/status/1175197286349119490
(I'm not an Apple fanboy, just a dev.)
(Tangential rant: I dislike how it seems like the most effective path for anything resembling customer service from many companies is to call them out on Twitter alone. I've written emails to some companies over months to no single response—but to look on their Twitter you'll see an answer within hours, or minutes.)
It certainly seems more effective.
Instead it's a public haranguing like putting someone in the stocks, except in exponentially less response time.
That only works when the public knows that the customer service experience is poor. I'm no fan of Twitter, but putting this stuff in the open is incredible effective for this reason.
tl;dr: Recent performance improvements in the Mac version of Firefox are dependent on an undocumented feature of an API that was tweeted out by someone from Apple
One is a developer reaching out (costs: developer time, management involvement: granting permission). The other is a change in project plans, staffing, workflow and timelines (costs: large, management involvement: massive).
I think it's a pretty safe bet to expect, for this reason alone, that the documentation quality of things like SwiftUI will improve over time. It seems pretty obvious they directed all their efforts to releasing SwiftUI within their iOS 13 release window, which likely meant the API only 'stabilized' very late in the process and it would be impossible to spend time and resources documenting it, at least not without postponing the release (not an option).
Generally speaking, in my experience all of the 'established' Apple API's have pretty good documentation. SwiftUI seems rushed, and it would probably been better if they waited until iOS 14 and release it along with documentation. I'm not definding Apple here, but I think the article is overstating how bad their documentation is based on one brand-new API that probably wasn't fully cooked for release to begin with.
They do it anyway, and should be commended, but this isn't Apple per se.
We're talking about one of the biggest platforms in the world here with unlimited money to throw at this problem there is no excuse
In contrast, I've always found Microsoft's documentation to be incredible. It can often be hard to find the right thing (though that has getting better, though that might be just my growing experience on how to find things), but they put real, actual effort into documentation.
Also, Microsoft has a very strong "corporate style guide" for API design. Every MS API within their major silos is built exactly the same way as every other API. Once you've had some experience with them, it's easy to figure out the others. I find Android to be down-right schizophrenic in comparison.
It's one of the many reasons I continue to focus on MS platforms for my work. It's been 20 years since they were the hostile "kill everything that moves" company that people lament.
In contrast, I've always found Microsoft's documentation to be incredible.
I don't know how Apple and Google work, but as a long-time-ago MSFT employee, I can tell you it is because they have entire teams. Chain-of-command, senior-level, leads, managers (don't know if there's such a thing as User Ed VP/Director, though) the whole works, like Microsoft kinda took it seriously or something. Hence my ranking of docs:
1. Microsoft: could be better, but you're going to have an easy time finding worse. No, they're actually pretty damned good. When I worked there, for instance, there was a big push that example code will be secure. The mantra was "sample code becomes production code". APIs have close-to-real-world examples of usage. "Could be better"? Eh, I don't know what I'd improve, frankly.
2. Back before they got really big, I'd say about Apple's docs, "does the job; it's not Microsoft-quality, but they don't have Microsoft resources, now do they?" Umm, that's not true anymore, and I think the quality has gone down since.
3. Google: just use Stack Overflow. The docs are just going to frustrate you with their incompleteness and outdateness.
Even if the documentation department never made a profit themselves, I imagine being able to point to some revenue and it being an important part of the overall business strategy kept it as feeling fairly important to most execs.
In that Microsoft has it, Google doesn't, and Apple... magic?
But if you're going to run a competent support org, you need to have high-quality, easily-accessible documentation. Because you're not going to know anything about {insert random thing support ticket is asking about}.
And if you've already created those docs for internal use, why not simply make them public?
https://docs.microsoft.com/en-us/windows/win32/api/winsock/n...
Compare with the MSDN page which is surprisingly still there (if it isn't when you read this, check the Internet Archive):
https://msdn.microsoft.com/en-us/windows/ms741519(v=vs.100)
Or just plain misleading, like this function which definitely returns a value but has "void" in place of the actual type:
https://docs.microsoft.com/en-us/windows/win32/api/wininet/n...
The page on MSDN is correct as usual:
https://msdn.microsoft.com/en-us/windows/aa385098(v=vs.80)
I've also noticed a relatively huge amount of grammar/spelling errors in their newer docs, no doubt because MS has lost much of its real documentation team.
Fortunately most of my work with Win32 uses stable APIs that have been around since Win95/NT4, and thus are nicely documented in the infamous WIN32.HLP.
Even so the Symbian team did some pretty cool things such as creating open source documentation standards for C++ and the tools to support that.
Source: I was there.
> What's the purpose of the throwaway account for this?
My guess is they want keep their other account pseudonymous, and admitting that they were one of a specific team of 20 people at a specific company goes a long way towards unambiguously identifying them. At a minimum, one of their teammates could probably ID them.
Apple seriously needs to re-focus.
I would say the issue is complicated:
1) BlackBerry was never thought of internally as a 'platform' more of a 'solution' (i.e. you get what you get out of the box) - apps were a little secondary. That perspective was too slow to evolve.
2) The original Java APIs were not very well thought out - part of the problem in 'great docs' was that the underlying platform wasn't very good to begin with.
3) BlackBerry was a tiny company compared to Apple and Google. When BB launched maps, there was no 'mapping team'. There were 0 people dedicated to mapping. G had I think more than 100 at the time, just dedicated to that. BB was growing rapidly, but had found itself jammed between Apple and Google - two of the most magnificent and well capitalised companies in the world.
I'm still amazed that BB had all the features it did given how small the teams were. Most of the handheld - hardware and software - was developed in one little building - you could literally know everyone working on it personally if you worked there.
3) All of that said - the docs were not that bad. Everything was technically documented. The support teams were decent, just small.
All the data was routed through Canada, right?
Due to its 'highly secure nature' it was sought after by individuals within regimes that had known surveillance and BB was way ahead of FB/Google in terms of attention by national powers around the world and having to 'deal with them' - at very least because it was actually used by entities in the first place! One of the drawbacks of Barack Obama using your device is that it's 'front and centre' and 'widely used' by every relevant 'agency' in the world.
It was a hugely difficult issue; hackernews tends to be 'anti state surveillance' in all forms - personally, I'm not as long as there's judicial oversight/applied properly (though sometimes it's not the case even in 'good' regimes) - the fact is basically every country you can think of wanted some type of special deal, the details of which I'm not at liberty to go into sufficed to say it was complicated on every level.
I can say however that Venezuela specifically was never going to get any help from us, and that BB was huge in that country due to it's effective protection from federal sources. Several countries like this were 'big blips' in sales due to the networking effects of this and other things. Penetration of BlackBerry around the world was very irregular, not like other platforms.
Why specifically not Venezuela?
Kind of, but not quite.
Little known history: BlackBerry 'became encrypted' because back in the days when it was really just a 'pager with email' - North American carriers (channel partners) were actually reading BB executives emails during negotiations (!!!). BB discovered this and decided to start with the encryption. Seriously - the first 'illegal' act was by BB customers/channel partners!
From there, it was always pragmatic. BB was never specifically motivated by protecting individuals from governments persey.
Edit to add: I also work on both platforms, and I’d say iOS (along with MacOS) is usually easier to work with because the design tends to be sane and the names are fairly descriptive; whereas Android has a lot of weird and questionable design decisions so it’s harder to guess how things really work. On the upside for Android, it’s often possible to just read the source code (at least for the core OS).
I think the docs are about equally bad overall.
Ah - the "repeat the method names with spaces in it" style of documentation.
This is merely an exaggerated form of a trap that the majority of documentation falls into to some degree - documenting the "what" but neglecting the "why" or "how".
It tells you the bit you can easily work out by intuition, reading the source or using your IDE's features.
And it leaves out the really important parts: "how should I use this method?" and "why would I need to?"
Method based documentation also has problems explaining how API calls are used in concert. Understanding each method in isolation something leaves huge gaps in understanding how they are to be used together.
And no - you can't plug the gaps with lazy video tutorials.
That's usually a symptom of aggressive linters enforcing the rule that every single public method must be documented. Programmers then produce useless "documentation" to shut the linters up. Utter waste of disk space.
I recently returned to the platform and my experience is very much like the parents. The documentation appears to be almost completely missing. The built-in documentation does not appear to include any guides at all. The API documentation is largely the kind where the description is a more verbose form of the method name, and sometimes when Objective-C is selected the documentation is showing the Swift version.
I think that personally it’s not all that well organized either.
My minimum standard for good documentation has and always been Python’s[0]. While no documentation is perfect, I think they mostly get it right by providing good explanations and examples consistently throughout the documentation. I also like how it’s spilt up between modules and the code examples are routinely updated. I have found very little issue with Python’s docs. While it could definitely use more examples and and deeper content around asyncio in some parts (mostly around transports and protocols) on the whole its very good, to me it’s what all organizations should strive for at a minimum. I also want to call put Mozilla’s Developer Network (MDN)[1] as stellar, I reference and use it all the time and have genuinely been happy with it.
To be fair in assessments, I’ve also found links in Microsoft’s documentation that often link to things they have already marked as outdated or not going to be updated, or just don’t work like the GitHub links on this page:
https://docs.microsoft.com/en-us/xamarin/xamarin-forms/user-...
So I think a lot of documentation around the big platforms especially have a lot of work to do. This isn’t to say documentation is easy though. I sincerely hope that all this noise just means it becomes more of a priority. I know from experience that writing good documentation is hard and I don’t want this to come across like I’m faulting anyone in particular or organization in particular. I imagine with large and ever changing platforms it’s quite the challenge. I just wanted to point to some examples I believe get it right most of the time.
See Example 5 in https://www.php.net/manual/en/security.database.sql-injectio...
This is the recommended way to avoid SQL injection, using sprintf...
Do you have a method that makes sprintf with d value invalid?
Reading the page I actually think this is pretty good for being language documentation.
GO docs are quite very neat and helpful though.
I usually search or scroll that page until I get to the feature I'm interested in. I like that it has plenty of examples.
PHP's docs are the minimum standard, IMO.
IMHO that's usually a good sign --- that the API you're using is not ever going to change again. MS values stability and backwards compatibility far more than others (and in the past, that was even better) so "not going to be updated" means "this has become mature and stable, don't worry about unexpected changes."
Microsoft's Documentation: - https://docs.microsoft.com/en-us/dotnet/api/coreimage.ciaffi... - https://docs.microsoft.com/en-us/dotnet/api/coreimage.ciaffi...
Apple's Documentation: - https://developer.apple.com/library/archive/documentation/Gr...
I was trying to get into Kubernetes world via kubeflow, a machine learning platform that works on top of the Kubernetes. Well, I have run into a bunch of the missing examples, outdated articles, and things that just don't work (all of that in official documentation).
I decide to change this a bit and start working on a small tool [1] that can help check documentation (at least reduce deadlinks in the documentation, when someone moves git files or just original source of info dies). Since I start working on it, I meet only one project without issues, all others.. well, they all had issues.
Maybe one day I post it on HN as a standalone link, but now here we go [1]
"It's not finished until it's documented" is a fine sentiment, but I don't think Apple has remotely claimed that SwiftUI is finished.
The author states that they are planning to write an app from scratch with SwiftUI. I think most iOS developers would hesitate to build an entire app on a beta framework.
[0] - https://developer.apple.com/tutorials/swiftui/tutorials
https://developer.apple.com/tutorials/swiftui/creating-and-c...
SwiftUI is not in beta. It may be beta-quality, but they shipped it and encouraged devs to use it. Yes, it has undergone significant breaking changes since WWDC (and that's to be expected), but it's not described as beta anywhere in their docs about it. (See https://developer.apple.com/xcode/swiftui/ and https://developer.apple.com/documentation/swiftui/ for what the docs actually say!) My point is that if they want to say "This is ready for you to adopt" they need to back that up by documenting it. Even at an early stage.
Facebook manages this for React, even for stuff that is in "experimental" mode! It's possible! It just has to be prioritized. (I'm no FB partisan and don't use React; the point is independent of those.)
iOS 13.0+ Beta
macOS 10.15+ Beta
tvOS 13.0+ Beta
watchOS 6.0+ Beta
Mac Catalyst 13.0+ Beta
But even there, there are nontrivial problems. Look at the front page of reactjs.org: all of the examples use component classes. The tutorial introduces component classes without mentioning that they're a huge PITA compared to function components using hooks and that they need/should only be used in a few legacy corner cases.
React 16.8.0, the first stable release featuring hooks, came out in February of '19. May I suggest that it's not finished until the home page and tutorial are updated?
I only bring this up for posterity, but Ember's documentation is terrible, and what is even worse is the Typescript documentation is almost unusable its so outdated. Chris's site is the only place you can go to find anything and it's incredibly difficult to make sense of or is already completely outdated... There are constant gotchas and missing documentation or things that are flat out wrong...
I can understand complaining some about Swift's docs (though I've never had that problem), but comparing them to Ember's seems like an awfully bad take.
P.S. I love Ember, learning it has just been nightmarish at points for almost no reason.
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.
One big difficulty I've had, because I want to fix things (like docs), is because everything post 3.12 is geared towards Octane and those docs are all quite a bit different than everything before it... (and I'm on 3.12) it makes finding the code to change, text, blob pretty difficult (IMHO) since master is mostly Octane.
2. I know you aren't paid and you're a saint for all you've contributed! You've helped me an insane amount, and I want to say "thank you," for it. I wasn't trying to give you too much shit, I just thought it was a little funny... Ember's docs are in disarray for a new language and design patterns, and so are Swifts! ;) I probably should've used a softer word than "awful," my apologies.
2.1 I'll see you in your issue tracker later today :)
Thanks for being friendly! I super appreciate it, and for letting me know about it being cool opening those kinds of issues. A LOT of Github repos are hostile to _any_ questions at all (i.e. "go to stackoverflow or take a hike"); so, I tend to not make issues and only PRs.
As for being welcoming and friendly—of course! We desperately need the help, esp. to hit the gaps that we're blind to because we're used to working around them. And honestly, "awful" isn't far off from how I would describe our docs; doubly so far anything related to Octane with TS (where it's subject to precisely the critique I leveled in this post: they don't exist!). See you on the issue tracker!
I couldn't believe that a part of the Apple operating systems that had been ingrained for years had so little documentation and examples at that time. I ended up finding out more from a lot of third party blogs and via forums.
I haven't checked, but are things like the MIDI framework still badly documented in the Swift docs?
Documentation for the entire audio stack has actually gotten quite a bit worse. Many references have been removed without new replacements being provided. In many cases, there are broken links in what little documentation remains. (For example, TN2274, which describes the USB audio stack is still around, but several of the outgoing links, for example the documentation for developing a USB audio plugin, are now broken, with the sample code deprecated and removed with no replacement.) New frameworks like AVAudioEngine simply don't document important limitations, particularly for OS X.
The Core Audio mailing list used to be a good place to get help and answers in cases where the documentation is weak, but traffic has withered and no from Apple seems to reply to messages any more. There has been a total of only four messages on the mailing list this month.
It's really a shame, because the audio stack is well-designed, but the documentation is so poor except for the basics that newcomers would have difficulty getting anything tricky off the ground.
Audio developers starting today are fortunate though because there’s AudioKit, which is the right choice for the vast majority of apps.
And while the AudioKit devs are among the most experienced Core Audio developers around, even they are frustrated by the lack of documentation. See, e.g., [1], where they say:
"The most important example of this is that we don’t really understand at present how to create AUs which have polymorphic input and output busses. [snip] This is fundamentally because the Apple documentation on how this is supposed to work is essentially non-existent. I undoubtedly leverages the fact that the input and output busses are KVO compliant, but this is about as much as we know. We will have to figure it out via experimentation."
[1] https://github.com/AudioKit/AudioKit/blob/master/docs/AudioU...
It's not exactly fun to code up payment integrations, and so I was kind of hoping to get it over and done with. But with Apples payment APIs, we needed months of production data to figure out how to use them without shooting ourselves in the foot.
Using the API felt like interfacing with some badly configured eventually consistent MongoDB cluster that a bunch of juniors stuffed full of receipts, using the entirely wrong data model.
I am not a huge Golang fan but recently I found myself using Go quite a bit and I really appreciate their docs which include a description of each function and an example. The example code is even editable with a "Run" button so you could test and understand the function much better before moving it to your own code. Here's an example if you are unfamiliar with Golang docs (click the "example" link for the editable code): https://golang.org/pkg/strings/#Compare
It's no better today. People who live isolated in the Mac universe have no idea how good Microsoft Visual Studio tools are, and how complete and thorough the documentation is, and how consistent the API is. You don't have to wade through a 30 years of legacy APIs to get anything done.
It is my belief that the Apple iOS docs are just another barrier to developer entry; similar to their $100 yearly license, expensive hardware combined with their WYSINWYG simulator, and woeful iTunesConnect experience.
These barriers to entry, including the poor documentation, definitely have some interesting affects on the ecosystem. I've seen examples of all of these in the real world.
* Experienced iOS devs have a shared trial by fire experience.
* iOS salaries are slightly higher on average compared to Android.
* Skilled iOS devs tend to be excellent developers in general.
* Average iOS devs can be more arrogant and less likely, or less capable, of helping out in other languages and projects. (Apple framework specialist pigeonhole principle)
* There is almost zero culture or standards regarding application architecture or documenting iOS apps.
* Underlying "older" concepts like memory management have been masked, forgotten, and / or ignored.They've had a new push to make sure that the remaining official documentation is available in either Swift or Objective-C, but I have yet to see any attempt at migrating some of their best documentation: CoreBluetooth Programming Guide, CoreImage Programming Guide, or CoreData Programming Guide [1]. These are hugely helpful documents that take a much higher level approach than just API documentation and get to the heart of the design of a framework, with helpful diagrams, etc.
I understand that Apple has a huge body of work regarding documentation, and that it would be unfair for us to require them to never deprecate any of their documentation, but at this point, we basically have header files, documents automatically generated by header files, with several large swatch of that even being undocumented [2].
I do think that Apple made a huge effort with SwiftUI to provide meaningful, helpful documentation at the time of the announcement [3], and I don't want that to get lost in the discussion. Unfortunately the framework has iterated so quickly that much of it is out of date.
However, when Xamarin [4] independently documents some of Apple's APIs better than Apple does... it is indeed time for a call to action.
This is especially sad because Apple used to have some of the best documentation ever available. I basically learned how to program through using their documentation.
[0] - https://developer.apple.com/library/archive/navigation/
[1] - https://developer.apple.com/library/archive/documentation/Co...
[2] - https://nooverviewavailable.com
[3] - https://developer.apple.com/documentation/swiftui
[4] - https://twitter.com/akashivskyy/status/1187790245804367873
The continued failing of example code is really painful.
I have the problem that even an iPad is a tiring for reading even with the ability to position it in a more comfortable reading position than a monitor. I need to print stuff out and html truly sucks for printing. I can use e-ink and that seems fine which isn't an option either. Bandwidth is still not universal or cheap.
Not only is there not enough information, but the documentation team goes out of their way to reorganize what documentation exists every couple of years, so outside links into the docs constantly go stale.
Edit: Updated wording to article's title change.
It’s a shame, because the classic MacOS docs were amazing, amongst the best technical docs of all time at their peak. (I had a shelf of Inside Mac books, and they were useful for years.)
Not only there are practically no updated resources available (books, courses, etc), but the Apple docs are really lackluster.
At first I thought Catalyst was about empowering Cocoa devs to bring Mac apps into iOS, but now I see it's just the opposite. I imagine the number of macOS devs has been slowly shrinking over the years.
The best I could find from Apple was several years old, and clearly not up to date as the behavior no longer functioned as documented.
Stuff like the strange behaviour of <iframe> on iOS is not documented anywhere but StackOverflow or WebKit's bugzilla.
For those that don't know, you can't set the height and width of an <iframe> on iOS. Something which has been possible in all browsers since the tag exists.
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.
If you can…
> If you go to WWDC
Again, if you can…
Apple used to link sample code with pretty much all the big APIs but they no longer do that. If you want to see how an API is used or see the best practices you’re better off checking stackoverflow.
ld: warning: ignoring file build2/libb.u.a, building for macOS-x86_64 but attempting to link with file built for unknown-unsupported file format
For example ask Apple to do something and let them sort that out using their employee. Or some web site (I use one particular to help me).
Swift is a language like lisp or clojure. You may look at its architecture etc to see whether it is built in issue (lisp is easy but its library is not, say). Or it is really just a hiring issue.
Or may I just ask how to address the original question if it is just language lack of good doc.
The lack of documentation led me to feeling like I was just somehow personally missing something. I’ve been at this for awhile and the apple docs left me feeling like a junior programmer all over again. I wanted to first blame myself, but it’s become clearer to me that Apple just doesn’t care about supporting devs. That’s the theme for years now and it only seems to be getting worse. Bummer.
You know, they could call Tim O'Reilly and commission a bunch of excellent books. They have the money and Tim has the writers.
Geeks can’t stand to face the fact that people who can afford to have a choice, overwhelmingly shy away from Android.
It's more that Apple has gotten people to view anything other than the iPhone as low status, e.g. green bubbles.
What's your point?
That's how it's always been for any objects. Cars, cheese, wine, etc.
Humans are inherently status-seeking creatures and they display their status in a myriad of ways.
Apple just happens to make premium products for a premium segment of customers - and there's nothing wrong with that.
Getting a loan to buy a friggin phone? It does look like a status symbol to me.
They offer “loans” on $100 Android phones.
By definition, a “status symbol” is something that you buy to show that you have more “status” than the majority of people because you can buy something that most people can’t. If the majority of people can get a product, how can it be a status symbol?
Simple. If you have it you're ok. if not you are a marginal
On top of that I got customers for my software and ones that own Mac/iOS are are shall I say very vocal. Here is the literal quote: when are you guys going to have your product for Mac? You should know that Windows sucks and no one will take your product seriously. All my friends have Mac and iPhone.
It does sound like they feel being belong to some higher level
Finding marketshare for mobile in various markets isn’t that hard....
But why base an opinion on anecdotes when their is widely available data?
Surely you’re not basing your opinion on Mac marketshare (which hovers around 10%) based on “your friends”.?
(Yes I know this is not your point, just a little joke)
In any case, as is usual with all employers, these days, they completely ignored the focused, relevant links that I sent them to elements of my extensive portfolio of repos, and, instead, based the entire interview on a 50-line binary tree test in Swift.
I'll make it clear that I'm NOT a fan of these. I am mediocre, at best, at them, as I don't come from a traditional CS background (I started as an EE).
In any case, during the test, I did what I always do when I write code. I stopped to write a header document for the function.
This was clearly not something the tester liked. Also, to add insult to injury, they dinged me for not writing a cascaded nil-coalescing operator. The code they wanted me to write was difficult to understand, and absolutely not one bit faster.
What makes this even funnier, was that this was for an Objective-C job, and the links that I sent them (that they ignored), were to ObjC repos.
After that, I just gave up on them. It kind of shows where a lot of this is coming from.
Dynamically-generated documentation can be great (It's clear that the lions' share of Apple's developer documentation is dynamically-generated), but it requires a VERY disciplined coding approach. I suspect that they may be hiring less-disciplined engineers, these days.
a && a.b && a.b.c
Is that the one you had in mind?
a?.b
a && a.b
It's identical to something similar though
(a !== undefined && a !== null) ? a : bBut also, as another commenter pointed out, there is a distinction between "optional chaining" and "nil coalescing" and I explained (roughly) what optional chaining is.
a ?? b
a != nil ? a! : b
In Swift, this is expressed by "??".
It means "If the previous test returns nil, then execute what is after the ??".
For example, if you have a concrete Int, but the source might be an optional, then you could do something like this:
let a = b ?? 0
You can chain these, like so:
let b: Int? = <something from somewhere>
let c: Int? = <something from somewhere>
let a: Int = b ?? c ?? 0
You can have a lot more going on in the handlers than simple assignments, but this gives you an idea.
int a = b ?: c ?: 0Personally, I like the ternary operator, and I also like the nil-coalescing operator, but I'm quite aware that they can produce difficult-to-maintain code, so I'm careful with them. I have gone and done some silly stuff with both, but then, I realized that I was leaving unmaintainable code.
If you use godbolt.org, you can actually see what code is produced by the source.
int a = b ?: c;I hate it when things like this get names that everyone's supposed to know and it's considered a mark against you if you've never heard it before, but I do think the name Elvis Operator is hilarious. :D
> The name "Elvis operator" refers to the fact that when its common notation, ?:, is viewed sideways, it resembles an emoticon of Elvis Presley.
b = list.next.to_s || "Reached end of list."
a = b || c || 0
edit: One BIG downside to this I forgot to mention at first: If nil and a false value are both possible for a variable, then this construction can betray you and break your heart.
Giving the developer succinct ways to prevent program failure from unexpectedly undefined values is a feature.
When constructing objects "in-line" in c# I actually used to see the ternary operator quite a lot, as in
new SomeClass() {
Val = valSource == null? SomeClass.DefaultVal : valSource
}
nameLabel.text = user?.name ?? "Guest"
if let name = user?.name {
nameLabel.text = name
} else {
nameLabel.text = "Guest"
}In some languages, you simply write:
if (user)
nameLabel.text = user.name;
else
nameLabel.text = "Guest";
nameLabel.text = user.name if user else "Guest"
How the hell is it worse? It lets me write things like
toolbar.visibility = userSettings.showToolbar ?? defaultSettings.showToolbar
someOption = localPreference ?? onlinePreference ?? defaultPreference
let studentScoreFormatted: string = student.formattedScore ?? 'Student has not taken this test yet.';
It is awfully helpful for ensuring you handle error states in displaying API values. Additionally if you want this behavior but when the value is falsey, then you can use `||` instead.
optional1 ?? optional2 ?? optional3 ?? ifeverythingelsefailsvalueif b is not nil, then a = b else a = c
https://stackoverflow.com/questions/2100758/javascript-or-va...
return a or bI would also have serious reservations about taking a job where documentation is considered a negative during a coding interview.
I was a manager for a long time. I loved long résumés and relevant material.
I was hiring expensive people to work on really important stuff, and there was no way that I wanted to rush the vetting.
Also, I never gave a single test, and I think I got it right, every time.
There's bound to be some confirmation bias there
I confirm that everyone that worked on my team worked out well. Some had more challenges than others, but we got the job done. The team worked well together, and we worked with our overseas compatriots in exemplary fashion.
I was very fortunate. It was a small, high-functioning, C++ team of experienced engineers. All family people, with decades of programming experience.
I'm quite aware that this was a luxury. I'm grateful for that.
I might be reading into this wrong, but it almost sounds like you're saying that you only hired people who had families. Doesn't that sound a little bit discriminatory?
I've also generally had very good experiences interviewing with them - tough but entirely reasonable questions focused directly on my expertise and the tech the team is using. One that stands out in contrast to OP's complaint was an interviewer that brought in a stack of printouts of screenshots of apps I'd worked on and used them to spark a discussion of the work I'd done on them.
OP's experience, while annoying, and not surprising, is also not universal at Apple.
Another point in case against overreliance on metrics. Optimizing your process for making it easier to measure can easily turn into looking for your keys under a lamp post on a street even though you've lost them in a park.
I rarely have time to look at code repos unless asked by the manager/recruiter.
You are also likely interviewing with the wrong people. Most large companies are looking for as many of the best devs they can find for generic opportunities. They have many many slots to fill.
If you are looking for something very specific then you need to find a recruiter who does placement as well. Amazon (where I work) has two major hiring processes, direct to team where they are usually looking for a specialty or generalist and take the first qualified candidate, and generalized hiring where you have to pass a standard interview but then you begin interviewing managers and finding a fit. The second may be better for you, but you still have to pass a bog standard interview.
There is of course the third way which is have a friend on the inside do the pre fit and selling.
(Maybe spend a few minutes on the phone just to verify they are really the person who wrote all that code.)
The on site interviews are checking for things like communications, soft skill, design, etc. Things that don't fully come across in a code repo and are hard to verify who did what.
We have tons of people who try and misrepresent themselves. It would be a waste of time for the 6 people on a loop to all read the repo. It would also be bad if we didn't cover the things we cover in the on-sites.
We are also required to keep loops the same for all candidates. So giving an offer to one candidates because they have a GitHub repo and a phone call and the rest don't and therefore have to come in is a no-no. Therefore they all come in.
I would argue that "how fast can someone implement this algorithm?" is a considerably less useful question to answer than "does this person document their code?" in an interview. If time is the constraint then schedule a longer interview.
As a method of finding good candidates it feels like it must suck but so few companies are willing to actually measure their hiring effectiveness (and be open about it).
As someone who has given hundreds (maybe thousands) and received dozens of these types of interviews, it's really not.
Generally speaking I'm looking for at least 2-3 of these abilities, depending on which question I'm asking:
1) Can you reason about data structures and algorithms when looking at a problem you haven't seen before? 2) Can you communicate your ideas effectively? 3) Can you integrate new information from a colleague while problem solving? 4) Can you write code that makes sense? Do you understand basic programming concepts? 5) Can you read your own code and reason about it?
There is at least two hidden attributes that I'm not testing for but do affect performance, so I try to account for them:
1) Are you comfortable with me, a relative stranger? 2) Can you do these things while dealing with a high pressure situation?
You will encounter high pressure situations at work but often interviews feel more high pressure (to some people) than most daily conversations about engineering.
That's it. If I can tell a candidate already knows "the right answer" to the problem, I'm usually disappointed because I'm more interested in watching them think.
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.
There is likely no causal effect between whiteboard/algorithm interviews and poor documentation.
Why?
Because any single interviewer has a set of well rehearsed questions they know like the back of their hands. They know the different possible solutions and understand their pros and cons. This makes the interviewing a routine that lessens the brain drag. I in an interview setting you wan't to know your shit.
Using the candidates online source code repo portfolio would mean that the interviewee would have to try to understand the candidate's code and whether it'd be applicable to the intended role and how well the code would lend itself as a measuring stick for the candidate's skills. This is a lot more work and so obv it won't be done.
Also, it's never obvious how much someone contributed to their portfolio. Just being able to explain it doesn't mean you were the sole contributor, or the contributor at all, and it doesn't give a great indication of how you work or how well you can analyse problems.
You guys are absolutely correct about the reference questions. I can find no fault with that.
However, there's absolutely no question that I'm the sole contributor to all my code. Most of my repos have only one contributor (Yours Troolie). A couple have been forked off.
I do link to a number that have been turned into larger projects; with multiple contributors, but there's no question that's happened.
Also, those are my old PHP repos; not the ObjC or Swift ones.
There's ten years of commit history in the repos. You could run crunchers on them to do things like develop velocity and productivity metrics.
I'm also quite aware that my case is unusual. Most folks don't have such extensive portfolios, and are much more of a "black box."
A bad actor could easily just have someone else write the code or copy it though.
I've seen this claim getting bandied about a lot lately, but I'm increasingly less convinced. You receive 10 n-dimensional vectors of programming and engineering skill, aka "applicants". You take their dot product with a ten-dimensional vector. Even assuming you can do that correctly and reliably, on what basis are you so sure that the ten-dimensional vector you've chosen has any relationship to what you really need? Repeatably and accurately asking a detailed question about recursion and pointers in a job that rarely calls for it just means you are repeatably and accurately collecting irrelevant information.
I've been chewing on this claim for a few months as people have been making it, and it's not like I'm entirely unsympathetic to it, as hiring does obviously suck. But lately the more I think about it, the less convinced I am this is the path forward. It just seems like a great way to institutionalize bad practices.
I think you need to embrace the diversity of the incoming n-dimensional vectors and pursue a strategy of exploration. Fortunately, they're not all uncorrelated and you do have an idea of what you're looking for. I see interviewing as a process where I'm seeking the answer to the question "What are you capable of?", and I want to seek out answers focused on how that relates to what I'm looking for, and that may mean I thought I was interviewing a dev candidate but I'm actually interviewing someone suitable for QA, or vice versa, or I thought I was getting an academic and I've got an old UNIX sysadmin, and these are just the examples I can quickly give. (What really happens is even more detailed, like, they clearly know their APIs but they're pretty sloppy in their naming, or I started looking at their personal projects for skill and was surprised at the documentation, etc.) It's not an easy approach, but why would we even expect there to be an easy way to analyze applicants?
(Or, to put it in more statistical terms, rather than applying a fixed vector dot product, I approach applicants in terms of a multi-armed bandit, where I'm trying to find their strong points. It helps in this case that the "multi-armed bandit" is actually incentivized to help me out in this task.)
So the only thing you really can do is ask objective questions or check technical skills. Thus the choice is not between hard skills or soft skills, but between hard skills and no skills because the soft part deteriorates extremely quickly and becomes essentially useless at scale.
That basically begs the question of what I'm saying though; why should we expect that there is an "easy to teach" process that "works", for some useful definition of "works"?
Our desire for something to exist does not mean it does exist. I think a lot of the rhetoric around "fixing" interviews is making this fundamental mistake, where what is desirable is laid out, and then some process that will putatively lead to this is hypothesized, but there isn't a check done at this phase to be sure the desired characteristics can even exist.
It may be that evaluating human beings and whether they can fit into technical roles is just fundamentally hard. (I mean, when I put it that way, doesn't it sound almost impossible that it's untrue?) While acknowledging fundamental difficulty is not itself a solution, it does tend to lead one to different solutions than when the assumption is made that there must be some easy, repeatable solution.
I can sit here and wish there was some easy way to communicate how to be a full-stack engineer in 2019, but that doesn't mean that such a thing exists, and anyone trying to operate on the presumption there is is headed for the shoals at full speed. People who know such easy things don't exist may still wreck themselves but at least they aren't guaranteed headed towards the shoals.
(Or, to put in another really technical way, the machine-learning-type bias that somewhere in the representable set of interview processes there must in fact be a good solution is not necessarily true, and think there's good reason to believe it's false.)
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.
I come from a CS background and struggle with these too.
The big problem I have is this performance stuff is often barely relevant to the position. You need to know the principle of a BST. Unless you're building a database working in a unique scenario, actually traversing it going to be done by some library.
That it also rejects some good candidates is fine, there's always more candidates for FAANG jobs. (Few competitors pay FAANG salaries.)
I feel like there should be a course for passing these exams run by ex-FAANG employees. Perhaps a bootcamp.
2. Some of these firms occasionally host coaching sessions for referrals. Ask your friends if one is currently running.
3. "You don't need H1Bs, just lower your hiring bar" is a criticism that is a bit less applicable to firms with a high hiring bar, than to firms with a low hiring bar. If you are, in fact, talent-limited, an H1B will actually cost you more than a local worker. (Lawyers, immigration sponsorship, uncertainty in whether the visa will actually arrive, aren't cheap - and FAANG does not have a reputation for exploiting their H1B hires.)
I'd like to practice this, any recommendations?
If you don't want to pay, just get the list of former questions from the internet. [1]
Many of those questions may no longer be asked, but if you can ace them, you should have few problems with similar questions/variants thereof.
This is not a skillset that develops from doing your day job. You have to deliberately practice to get good at this.
[1] https://www.interviewcake.com/google-interview-questions
Writing documentation headers in an interview setting should only happen if they explicitly state that you should write them, or after you ask the interviewer if you should be writing them.
Here's what I like about interviews:
(1) I get to talk about myself and how great I am without people rolling their eyes at me.
(2) I get to solve a fun puzzle with:
(2)(a) A defined answer.
(2)(b) That I never have to maintain.
(2)(c) With a potential financial windfall at the end.
If you happen to do coding exercises at all, they are just basic tasks like implement a linked list data structure, count the number of words on a file and such.
Answer some trivia about the language you are supposed to use, e.g. when should you use a struct in C#.
Luckly only startups over here are somehow into SV hiring culture, which still leaves plenty of others with job offers available.
Looks like you got stung by the confusion between binary tree and B-Tree (and B+Trees).
1. The b in btree isn't binary.
2. Databases use B+Trees.
3. binary trees are almost worthless.
Interval trees reduce to Binary Search Trees when the nodes can't overlap. Most markup DOMs (in browsers, WYSIWYG editors, etc.) are held as an Interval-tree ADT which is actually implemented by a BST.
Also, Red-Black trees specifically are used in many database clients to implement an in-memory write-back cache of a database table, as the combination of performance requirements for flushing batches of writes to the DB, and reading back arbitrary keys that were written to the cache, make these BSTs nearly optimal for this use-case.
But yes, DBMSes themselves don't tend to use BSTs for much. Maybe as a query-plan-AST term-rewriting-phase ADT.
Interval trees are degenerate R-Trees which can be implemented using GiST which is itself a btree.
>Also, Red-Black trees specifically are used in many database clients to implement an in-memory write-back cache of a database table, as the combination of performance requirements for flushing batches of writes to the DB, and reading back arbitrary keys that were written to the cache, make these BSTs nearly optimal for this use-case.
Got a source? I'd like to read up on this use case.
>But yes, DBMSes themselves don't tend to use BSTs for much. Maybe as a query-plan-AST term-rewriting-phase ADT.
Postgres' source does indeed have a red black tree in it:
From what I've seen, interviewing is evolving and focusing gradually more on realistic, practically-oriented coding, and less on Leetcode-style questions, especially as people are learning to game those.
Part of this is understanding what they're asking for and adapting. If someone wants to know how to document code properly then you can have a conversation about that and give an example. But if they're asking about algorithms then you write the code and explain how it works verbally. You don't need to write comments because the reader is right there and you can explain it to them. It's not production code.
Assuming everything the GP said is true, what you're saying is completely contradicted by the fact that they were dinged for not using a null coalescing operator.
>It sounds like you might not be quite getting the concept behind this sort of interview. Although some code is written, this is (usually) a test of how you talk about code. You want to show that, if a co-worker asks for your advice on how to solve a tricky problem, you will be able to help them figure it out.
You could thank them for pointing it out, say you're not sure you want to use it (if you don't think it's better) and then get the conversation back on track. And, hopefully they'll think you handled it smoothly and won't take off points, but you'll never know how important it is to them that you're fluent in Swift. Maybe not at all, it's just an aside?
Which is to say, usually you can't tell in an interview what they're really grading you on. It's nerve-racking, but you just have to try to seem reasonable and hope that works.
The details of the exercise aren't the point...and I'm sure the reason the interviewer likely gave off mixed signals about the extensive documentation is because time is limited and a good interviewer makes sure to keep the candidate on track so that there's enough time.
Common data structures have no place in any type of interview.
“I just can’t hire someone who fails this sort of problem”.
Given that this person was applying for a general backend position building foundational, framework derived features (mostly CRUD and some light analytics) it was confusing to me. There is literally zero application for graph traversal in their work. They will absolutely never encounter this sort of problem in the course of developing our software...which is b2b, targeted at industry experts: we build software that generates reports. Not even complex aggregates...just moving window averages and the like.
At this point in my career, after building more than one team/business I’ve learned that the shape of your technical interview loop informs not just the codebase you generate...but also your engineering culture.
Otherwise, it's unlikely that most people will be able to solve it in 45 minutes, even with hints, and then you don't learn anything other than that they failed at an unreasonably hard problem.
So, one of the problem's solutions being a binary tree isn't itself necessarily a problem. The interview could be done well or badly depending on execution, and we can't judge that from afar. All we really know is that a binary tree was somehow involved.
---
At least, that's the idea. Interviewing is still terrible. It's pretty random to base a hiring decision on a few (extended) questions, and I think interviewers are left on their own too much to come up with good questions. How do we even know what's a good question or not?
Sometimes I wonder if it wouldn't be better to choose twice as many candidates as you need and pick half of them at random, just so everybody is clear that there's a lot of luck involved and they don't take either success or failure some kind of precise indicator of someone's worth.
If that's the metric being measured, then sure, it's a bad idea.
So how about giving reasonable arguments why OP probably had rounds that went poorly and is salty about it and why Apple has a wonderful software developer culture that focuses on quality instead of assumptions? Apple has problems with documentation since years, one example I had to deal with recently: their maps API. The MapKit programming guide is still in Objective-C, old design and outdated.
FWIW, I don't see how "I tried to add documentation in my interview and my interviewer didn't like it" translates to "everyone at Apple hates documentation".
> The MapKit programming guide is still in Objective-C, old design and outdated.
Objective-C guides are not inherently old and outdated.
You're absolutely right and this could have been an argument made by trangon, instead of an assumption about bad intentions by the OP. The interview story is just an anecdote in the end.
> Objective-C guides are not inherently old and outdated.
I agree in parts, they're not outdated in terms of facts present (although I wonder if MapKit didn't have any changes since October 2016). What I meant is outdated in a sense that Apple is pushing Swift but doesn't provide a programming guide in that language for this particular topic. Still supports my point of Apple having problems with documenting their APIs. SwiftUI is another example.
there is a common answer of “study leetcode”. No other advice, just the belief and assertion that all you need to get one of those jobs is to score higher than the other people.
This idea unfortunately perpetuates itself as one person advises another and a person.
The number of leetcode questions solved is used in the inevitable male appendage sizing contests.
Much of the industry was either specialists in their studies, or specialists in that they knew a specific software package. It was interesting to interview people who had very in-depth knowledge of one thing, but completely oblivious to even the basics of other areas.
Here's my defense for the critical thinking questions since I know it's a contentious topic here; I'm evaluating how they asses and troubleshoot something. Often, actual technical problems get caught up in the minutia or domain specific parts. So abstracting it and even removing all of the tech keeps people from getting hung up on that. I hate "trick" questions, but sometimes would ask one to see if they were thinking towards optimization or non-traditional. It's actually deflating if they already know the answer. I never cared if they got a result, I'd often move on if it took too long.
I felt the most criticism towards the technical questions. Many of them were more technical than really ever came up on the job. I think it's good to find the limits of a candidate's knowledge, but not ding them for it. An example would be doing stuff with pointers when the job is 100% in a scripting language. Sure, ask them if they know the basics of pointers, sure maybe once in 5 years they'll troubleshoot a bug that might need obscure knowledge, but I would hope that would get triaged and passed around instead of expecting everyone to deal with the 1% case.
At Google, you almost never know which team you will land in before you interview. At Apple, you probably know who your future manager will be before you interview.
(Source: I have worked at both companies.)
If you spend time doing extraneous things like documentation during a coding challenge you likely won't do well, not because documentation isn't valued but rather because you won't have time to move from the "simplest" answer to the "best" answer, let alone the "teach me something" answer. This may frustrate your interviewers because they're seeing you spend your time in a way that's not advantageous to you. They may even be more frustrated if they actually liked you as a candidate.
Tests are different because they often help you move more quickly and confidently between layers of the question as you can sanity check you revised implementation against your tests.
1) You can't always be 100% sure the code was actually written by the candidate.
2) One quality I'm looking for in particular is somebody who can work well with OTHER PEOPLE'S CODE, and that's even harder to evaluate. If I see a balance of original repos and forks, that might be some evidence, but again, how do I dig out what they contributed? Chasing down PRs would be more helpful, but that definitely is too much work for a job interview.
3) Having a busy github account could be a marker of particular life circumstances (to avoid waving the red flag of "privilege" around too much) — the candidate is not overly busy working a second job, raising young children, or giving 120% in his day job.
4) There are plenty of respectable reasons not to code in your spare time — you may have different hobbies etc. When hiring pathologists, we don't give preference to candidates who cut up bodies in their spare time. We should get out of the habit of doing so for programmers.
5) A busy github account can also be a warning sign of somebody who might be more invested in side projects (or possibly even bootstrapping a startup) than in their day job.
The interviewer probably wanted you to write idiomatic Swift. That seems reasonable.
Most of the open-source code that I've written has been for other people to take over. Most of my repos are still 1-contributor ones, but every single one has been written to be extended. The ones that have been extended are being extended very well, indeed. I have had almost zero questions about the codebase.
Given that a large portion of the discussion in this thread is around what this operator is, it seems somewhat valid for a company to want to see you use this. It might represent a deeper experience in the language being used, or at least some previous study of syntactic options.
The other parts of the interview weren't as bad but they also weren't great. Expecting you to know what happens when you export an int as 'main' instead of a function, for example - you can certainly figure that out from first principles or happen to know, but why should you?
It's sort of a "when a company shows you who they are, believe them" situation - even when I did get offers, seeing this reduced my confidence in the company.
I don't know about that; if Apple had lowered their hiring bar, they'd likely have enough engineers to not be constantly starving one project or another of talent because it's being "borrowed" by the Big New (next-to-announce-at-a-keynote) Thing. That still seems to be a problem; I haven't noticed any decrease in the number of Apple projects that "lay fallow" while their engineers are off doing something else.
On the other hand, Apple have decided a bunch of documentation was out of date, so they've simply made it harder to access by burying it in archive sections or taking it offline altogether, without providing replacements. Getting into driver development now is almost certainly a lot trickier than it was back then.
* can't help you
* don't want to help you
TBH, compared to the person-hours required to write up the DTS incident in the first place and keep the conversation going, test out their responses, etc., the cost of the incident itself is minimal.
Let alone the cost of the times where I decide to go it alone and figure it out by trial & error or reverse engineering…
Part of gaining experience with a platform is the ability to source answers to technical questions effectively, including how to use official documentation effectively.
As I noted in the post, I'm getting by anyway… but it's more work than it needs to be, and more work/worse state of docs than other ecosystems I've learned in similar amounts of time.
I also know exactly what my first 4 months in other ecosystems were like. Including picking up Fortran! That was rough! :)
For SwiftUI, the WWDC presentations are essential, IMO, for the high-level stuff. There is basic reference documentation, but there's no way to put it all together without a high-level understanding. It follows the patterns of some other frameworks so depending on your experience you may be able to get by without the WWDC presentations, but I'd still watch them or at least read the transcripts.
I think Swift Package Manager is meant as a community tool, and the love and care it needs to become excellent is not going to be coming from Apple, not without some kind of strategic change. Either the community will value it and figure out how to move it forward or it's not going to get much better. I could be wrong -- I'm trying to judge it's on-going strategic importance to Apple -- but I think the way it's going to improve is through community involvement.
Anyway, I'm not sure what the point of this kind of rant is. Whining about Apple is an easy way to get useless internet karma points, but it's such a bad look for a developer. At least half the job is being the one who finally deals with things someone else probably should have already dealt with but didn't.
Are these videos, slides and transcripts? I do hope not because none of those things are documentation by any reasonable definition.
I point it out because if you want to learn SwiftUI your best approach is probably to start with the presentations, whether you like that form or not. Many will naturally avoid that kind of content and I'm trying to communicate that in this case you really should use the presentations.
As far as SPM goes: they've got it built into Xcode at this point, and are doing WWDC sessions about it. At what point does it become "official" enough to warrant "This needs to be better" criticism?
As far as "useless internet karma points": I couldn't care less. History has shown that when people make enough stink about this kind of thing, it sometimes—rarely, but sometimes—gets to the ears of people high enough in the management chain that it ends up shaking things loose at the mid-level spots where poor decisions around these things tend to get made.
I don't work at Apple. I can't go fix most of this stuff. In my day job, I spend a lot of time on these kinds of concerns. In this context, though, the only thing I can do is shout a bit and hope it shakes things up a bit.
I did see you mention the WWDC videos, but I think you mischaracterize the role of them. My point is, people who are interested in learning SwiftUI should start with the WWDC videos, not feel "reduced to searching through" them.
Anyway, if you want to work on top of something solid, forget about SwiftUI. It's very raw and changing fast. I wouldn't rewrite on top of it now unless you aren't planning to release for at least a year. And you might end up throwing it all away anyway.
And shout all you want. I'm letting you know it's a bad look.
As for the look: I understand the take. We obviously differ on whether it's ever appropriate to make some noise this way. For my part, when it's come my direction (as it has a couple times in the Ember ecosystem), I've appreciated it.