Meta: iOS Knowledge Graphs and Common Core
At school, we encourage kids to compete on grades. These grades are simple scales ranging from bad to good. If you get an ‘A’ you did better than those who got a ‘B’.
These grades are a useful abstraction. Up to a point, we’ll all be sitting the same exam at the end of the year. So knowing how well we’re likely to do on that exam is useful. It’s useful for us, for our teachers, and for our parents.
This brings us to iOS interviews (‘technical fireside chats’, ‘relaxing lunchtime knowledge sharing’). These are exams for adults. And as such, they are testing for something very different versus school exams. They are looking at compatibility.
There are certain ‘common core’ competencies we look for in iOS candidates. But beyond this core, we’re looking for people who fix a hole in our team. And this is where iOS knowledge graphs come in.
This is a Github activity chart. I’ve always liked the way it represents activity as a shape. Is code review more important than authoring PR’s? Is running more important than walking?
Shapes are good because unlike A’s and B’s in primary school Maths they don’t translate well to a hierarchy. Hierarchies aren’t always necessary, sometimes they are counterproductive.
Knowledge hierarchies are counterproductive in the iOS community.
I would love to sit down for an afternoon with the kid fresh out of college who only knows SwiftUI.
I would pay money for the lunchtime session from the ARKit wiz.
I want to have a teammate who’s all about CreateML gesture-driven UI. And bangs on about it at every opportunity.
On some level, we all know that the team of misfits outperforms the automaton clones. That’s an important guide in my approach to hiring*. On a hiring call, I’m looking at a candidate’s knowledge shape and comparing it to our team’s existing shape. If I see this candidate gives us coverage where we were lacking, that’s a win for our team.
This brings me to the ‘common core’. I need to know that the SwiftUI wiz is also competent at UIKit. I need to know that the ARKit pro is also not going to crash our app with a memory leak. I need to know that the CreateML champion isn’t going to get tied in knots by higher-order functions.
Once I know that a candidate has the common core under control, I can let them dazzle with their unique iOS passion.
On the flip side, as a candidate, I know that once I’ve got common core under control I’m free. I can focus on the bits of iOS that I love.
The only problem is there is no common core. Companies today can’t say, we’ll be interviewing you on ‘common core for junior iOS’. We need to define this better as a community.
What is the common core for a junior iOS engineer role?
What about mid or senior?
* There are also other structures in play, I’ll save those for another day.
