Zen and the Art of Plumbing

I spent a week in Nicaragua helping my dad do plumbing at a small school some missionaries had built.  The school stands in the middle of one of the poorest areas in the western hemisphere.  In a place where most houses consist of ten square feet of metal siding the school provides a glimmer of possibility.

I spent my week digging ditches, learning that water flows downhill, and pushing a wheelbarrow round and round the concrete circuit.  The guys I worked with did this work every day and so their lives were clearly a little different than mine.  To me, this week was a nice change of pace from the hours I spend in front of a laptop.  Something good for the soul. For them it was just another day on the job.

The interesting thing to me wasn’t the differences.  It was the similarities that really stuck out.  As I listened to my dad’s explanations it became clear to me that there was a right and a wrong way to go about our task.  Technically, you just need pipes to get from one place to the other and you have Plumbing, but there’s a big difference between a bathroom where you’re allowed to flush the toilet paper and one where you aren’t.  

The pitch of the pipes, their circumference, the material they’re made out of in relation to what they’re carrying.  All relevant, measurably so, in the endeavor of installing a sink.  It’s in these places that I saw the connections to what I do each day.  

When you’re worried about whether or not your app is dropping frames.  

When you decide to go back and refactor your code so that the next person has an easier time. 

When you write some unit tests instead of fighting fires that pop up in production. 

You are pursuing Quality and though you can’t fully define what Quality is, you know you’re heading in the right direction.

A Tale of 10,000 Interviews

In the weeks after my trip to Japan, I turned my attention from learning Japanese and working on Flick to a more pressing issue.  I needed to find a job.  Bad.  

Aside from the fact that my cash pool was running low, I was honestly ready for something new to work on.  Plus a little structure in my life didn't sound too bad.  My only full-time professional job so far had been Carfax, where I worked for two years doing mostly iOS stuff.  It was seriously a great place to work.  Unfortunately, the iOS team there only consists of four people, so I knew going into Japan that the odds of being able to just go back to my team would be pretty slim.

Luckily, the second week I was in Japan, I was contacted by a Facebook recruiter who was cool with waiting until I got back to the states to talk.  When I got back I decided I might as well apply to a few more big companies just to see what the possibilities were.  I also had a friend from college who's startup weekend project had recently gone on to enroll in Y Combinator and thought he might be able to connect me with a company or two.  Turns out he could do better than a few companies.  He sent my resume out to the founder's list and by the end of the next day I had emails from 15 companies interested in talking to me.   Then a few days later, Google contacted me to let me know they were interested in doing an interview. This seemed like a good start.

The obvious truth of the matter is, I wasn't really sure what kind of company I wanted to work for.   I'm well aware this is beyond a first world problem, but I figured I might as well play the field while I was single, er I mean jobless.  On the one hand, I've always liked the idea of being able to work remotely for a company.  Being able to work wherever you want seemed like an awesome freedom.  Unfortunately, it seems like a pretty hard thing to come by; most companies, understandably, seem to want everyone to be in the same place.  On the other hand, I've also always liked the idea of working for a company like Facebook or Google.  The apps that come out of those companies are some of my favorites and it seems like you'd have to go out of your way not to learn a ton in the process of being there.  I spent my next month studying and interviewing at startups to see if any stood out.  

The thing I quickly learned is that interviews are all extremely similar.  If you're interviewing for a technical position as a software engineer then you can be fairly confident you'll experience some form of the following pattern.

1)  Recruiter call: A technical recruiter will call and ask to talk with you about your background.  This conversation usually goes some thing like:

Recruiter: Tell me about yourself.  What's your background?

You:  I went to school here, studied X, I've worked on a few projects and my favorites were these.  

[More small talk, followed by "Alright, if it's ok with you, I'd like to have an engineer follow up with a small technical phone screen."]

2) The Technical Phone Screen:  Next, an engineer will call to ask you to do one or two programming puzzles via some kind of collaborative word pad deal like collabedit.  They will almost always ask if this is still a good time.  You should probably say yes to that one.  Next they'll ask you to remove duplicates from an array or reverse a singly linked list.

3) The On-Site Interview:  If you didn't get stumped by the first question and you seemed to jive with the programmer on the phone, there's a good chance you'll get moved on to the on-site interview.  Depending on where you live, this can involve free flights/hotels and a couple days out in California, based around one day where you spend a solid 4 or 5 hours coding on whiteboards and telling people how you stay up to date on the cool technology you love so much.

In general, these questions are technically given to gauge your problem solving skills and how well you communicate.  They boil down to two main areas, as far as programming goes.  

Domain Knowledge:  Since my interviews were all specifically iOS interviews, I got asked a lot about ARC, manual reference counting rules and retain cycles, UIKit, GCD, operation queues, Instruments, Threading, and Swizzling.  Some things were, obviously, more important than others to know about, but they were usually looking for at least a cursory knowledge of any topic they asked about.  

Algorithms/Problem Solving:  These questions are, admittedly a little more work, but can become relatively straightforward if you've prepared enough.  They boil down to some slight variation of questions involving basic data structures and algorithms.  I used Dr. Skiena's video lectures and text book along with Cracking the Coding Interview to get a solid grasp on these questions.  In my experience, the hardest questions you'll get are basic graph stuff like depth first and breadth first search.  If you're comfortable with Lists, Queues, Stacks, Trees, and Dictionaries in your language of choice and feel okay about implementing Binary Search, Merge Sort, and Quick Sort then you've probably gone far enough.  Even through the on-site interviews at Facebook and Google I never saw anything as hardcore as Dijkstra's algorithm .  What you really want to make sure of is that you've gone through enough practice problems that when you get to these kinds of problems in person you're totally comfortable with diving straight into thinking of what kinds of data structures you'll need and what the Big-O repercussions of each option is.

Depending on the company, you may also get questions about System Design where you need to architect a system such as a url shortener or a search engine.  I got a few about how to architect an iOS app.  This kind of question was emphasized most at Facebook and they'll give you pointers on this part of the interview before you get to it. 

As far as my journey goes, I decided to pass on the startups I talked to.  Personally, I think you really need to be able to get pumped about the idea if you're going to jump into the startup scene and I just couldn't seem to find one I could get behind with that level of dedication.  As far as the big companies go, they didn't pan out for other reasons, but I think it all worked out for the best for now.

When it was all said and done, I ended up where I am now, which is doing freelance development with my designer friend Aubrey.

If you need an app made, go ahead and contact me.