always go one level deeper
i interview a lot of people for iOS software engineering jobs (at Facebook). one of the major stumbling blocks candidates have is that, while they can write objective-c code, they don’t understand how it works. how is a message sent? how does memory management work? an engineer who can tell you how an objective-c block works knows his stuff.
understanding things in abstract helps us be productive, and without this cognitive tool, we wouldn’t be able to build systems as complex as they are today. however, ignoring the implementation details of these abstractions can also lead to trouble. sometimes, this is just inefficiency, while at others it slows down your ability to respond to issues. in my interviews, this shows up as a lack of intuition about problems at scale and how to debug them. in any serious engineering environment, building new code is second to understanding problematic systems and designing solutions. the toughest problems are usually those that are hidden by platform abstractions (because you don’t control them).
for any reasonably sized software engineering project, it’s always worth understanding what’s going on underneath your code. that means learning about the platforms, frameworks, and other tools you are using in detail. knowing what goes on behind the scenes helps you develop a strategy up front.
leasing a car is a good proxy. dealers want you to focus on monthly payment. it’s not the whole story, but it’s a convenient abstraction. it hides critical information: how far from optimal is this deal? could you get a better price? better loan terms? would it be a better deal to buy the car outright? until you break things down, these are unknown. developing a strategy for making decisions before going to the dealer helps you get a better deal. luckily, for car leases, there are lots of tools to help you analyze options, and it is easy to adjust your strategy as you go along.
software engineering isn’t as flexible. adjusting strategy means re-architecting systems and rewriting code, and there aren’t always drop-in tools for your project.
engineers are familiar with taking requirements and adapting them to abstractions, knowing that choosing the right abstractions up front saves time later. in designing abstractions, engineers typically focus on requirements and assume the platform is workable for what they want to accomplish. as engineers start writing code, things start working, and they see this as validation of their design. but, platform pitfalls usually happen at scale and they eventually become roadblocks. senior engineers are so valuable because they understand how to avoid them, and factor that into their designs up front. earning this knowledge isn’t easy; most get it over the course of a decade working in a particular space.
the easiest way to get this knowledge more quickly is to challenge your assumptions about how things work and look under the covers every step of the way, even while building something simple. build a weekend project and learn about every API you touch.
i wrote this post because i noticed people failing in interviews when challenged on details of iOS, such as memory management, language features, and view management. some would say these are quiz questions, and some candidates believe they are only questions about idiomatic patterns. but, there’s no doubt that the most valuable engineers are those that understand what’s going on underneath the covers.
