Breaking into programming: customer development and the art of landing your Minimum Viable Job (MVJ)

I fell in love with Silicon Valley at my first startup.

We were Blueseed, and we were trying to solve the high-tech immigration problem by launching a ship off the SF coast. There were four of us, and we hit the media like crazy — CBS, CNN, BBC, you name it. Then we ran around the Bay Area trying to raise money.

After some success, the well slowed to a trickle, and finally dried up.

I was in need of a new gig.

I love numbers and have an economics/consulting background, but realized that the really interesting stuff is in data science. That would require professional experience as a developer — and I hadn’t really coded since high school, eight years ago.

The challenge was to get my foot in the door. After four months, I landed a role as a software engineer at Boingo Wireless. I started last Monday, and I’m loving it.

The Minimum Viable Job (MVJ)

At Blueseed, we were all first-time entrepreneurs, so we read all the startup books. I’d loved Four Steps to the Epiphany, Lean Startup, etc and when I started my career transition, a lightbulb turned on in my head.

This is customer development — and I’m the product.

My ideal career path — land a role as a developer, gaining experience, and transition to data science — parallels the startup product development cycle. I would break into the industry by finding what I termed a Minimum Viable Job (MVJ).

Since I already had econ/analytics experience — “features” — the ideal MVJ role would be an optimization engineer, developing an analytics platform, or something with a heavy predictive analytics component.

I needed to shoot for these jobs, sell myself, probably fail, understand what “features” I was missing, and then implement them.

Creating a visually appealing portfolio project

I started by talking to my hacker buddies.

“People don’t really care about your resume,” my friend Kyle told me. “They’ll ask you what you’ve built.”

So I started learning Python by building fundmap.vc — a data-based visualization of the Bay Area startup scene moving to San Francisco.

After two weeks, I was satisfied. But I wasn’t the intended audience. Someone like Kyle would be interviewing me, and I needed to impress them.

Thinking harder, I stumbled on a killer feature — the map distortion based on funding dollars — and spent the next couple of weeks implementing it. Kyle complimented it.

Working from the interview backwards

I meandered listlessly for a bit before getting an interview at drchrono, a YC medical records company.

“What do you think they’re looking for?” I asked my other hacker friend Nick. I pushed my laptop, displaying a job description, in front of him. “I have an interview this Friday.”

“Hmm,” Nick said, perusing the description. “Have you used Django before?”

“Heard of it,” I replied, guardedly.

“Do you know what MVC is?”

“Umm…no idea.”

“Okay, so you should probably spend the week building a project in Django. That way you can tell them about it if they ask.”

Taking inspiration from The Social Network, I decided to create Facemash, a picture comparison site famously built by Mark Zuckerberg pre-Facebook. (Except I used art rather than girls)

Zuck built it in five hours one night. It took me ten or twelve, but I was proud of myself.

Using one interview to gain experience for the next

During the drchrono interview, I told them about Facemash. Then I showed them fundmap.vc . Toby, the head of engineering, was impressed. He invited me back for a 3-day hackathon — I would get to build a feature onto their system.

I was ecstatic — I’d never worked with a production codebase before. Actually getting the job would be a longshot, but it would be a great learning experience.

Three sleepless nights later, I presented a not-very-well implemented Lucene search feature. No offer — but I was still happy.

Putting it all together

Two months, several interviews, and many iterations of this same principle later, I find myself tackling a really interesting code challenge in an interview for Uber. Given a JSON of timestamps representing app opens, I need to write an algorithm to predict the number of app opens at a later date.

I put it together on a Monday and Tuesday, staying up all Tuesday night to finish it. I want to go to sleep but can’t — I have a 10am phone screen for Boingo Wireless.

“What sort of projects have you worked on?” the voice on the other end asks me.

“Well, uh….over the last couple days I’ve been working on a demand prediction algorithm for Uber,” I say. Realizing that in my current sleep-deprived haze, I can’t speak cohesively about much else, I explain my process step-by-step.

The next week, I hear back from both. Uber’s not interested. But Boingo invites me back for an in-person. Turns out, their demand prediction system needs polishing, and they do their stuff in Django/Python.

I started last Monday.

Lessons learned: how to self-teach with bootcamp focus

If I had to pick one takeaway, I’d pick this.

For relative newcomers to programming, the amount to learn can seem overwhelming.

Languages: C++, Java, Python, Ruby…. Fields: web, client, network, systems…Domains: front-end, back-end, graphics, encryption….

The key is to understand your goal — the Minimum Viable Job — and organize your learning by selecting a cohesive set of concepts around that.

This is much of the principle in play behind bootcamps. Dev Bootcamp and its cousins teach you to be a front-end developer in Ruby. My interests lay elsewhere — in becoming a data scientist, where the language of choice is Python. (Zipfian Academy is one option here).

Still, when you’re a self-taught dev, you can achieve similar focus by applying customer development principles. Get out of the building (home, coffeeshop) — and you will understand where to go.

(posted from Moore’s Hand blog)