In September 2011, I interviewed at Instagram. While I didn’t ultimately get/take the job¹, the experience had a pretty profound effect on me as a developer.

What I learned during the interview process (which was really enjoyable, and became the basis for my ideal technical interview process) was just how much two engineers with relatively little experience could accomplish.

My notes on the interview:

• a popular iPhone app
• the back-end to serve millions and millions of users
• an infrastructure that could be experimented with: attempt to run Mongo and see what happens
• Implemented their data storage layer in Mongo, studied it, abandoned it
• Enhanced their iPhone app with Open GL
• Build, documented, and deployed an API and several clients
• Created a demo using their API in Node
• Have their entire infrastructure monitored; can identify any change in behavior of their system instantly
• Have ready access to their data to support third-party hacking
• Completely manage all of their servers

These are two guys with very little experience.

If you had looked at these developers’ résumés as of 2010, you would not find anything to indicate that they could both design, build, launch, and maintain a hugely popular application used by millions of people around the world.. And while I’m sure the code that powered Instagram back in 2011 wasn’t the greatest, these two guys had basically done everything from designing the UI to launching an API, to managing servers on AWS.

They did this without a QA team, a system “architect”, a product manager, a project manager, or a technical operations team.

Before the interview, I didn’t think such a thing would be possible. I would’ve assumed that such an undertaking would require years and years of experience, with an army of specialists each laser-focused on one part of a greater whole.

Nope.

To me, this is what I mean when I use the term full stack. It’s not just about working at any level of the stack, but about not being afraid to. When faced with any problem, these two guys didn’t show fear, and didn’t shy away…they dug in.

I used to hate writing JavaScript. Now, I have no fear and embrace it. It turns out to be pretty darn useful. I used to immediately dismiss any solution that involved writing raw SQL. I was above all that. Now, I use it a lot, because it’s the best way to solve a lot of thorny problems.

My current fear is around technical operations. I’m working on overcoming it. It’s going to make me a better developer.

Examine your habits and patterns. What do you always reach for? What makes you feel uncomfortable. What part of the software you build are you afraid of?