I’m Joining PillPack

I am thrilled to announce I’m joining PillPack as a Product Engineer. I’ll be working part-time as my last semester at Babson finishes up, and will move over to a full-time role after a short break following graduation.

What is PillPack and why am I so excited to join the team? “PillPack is a full-service pharmacy that delivers a better, simpler experience.” I’ve lived with Crohn’s Disease for the better part of my life, and understand intimately just how frustrating and demoralizing a poor pharmacy experience can be for those seeking care. From the moment I sat down with TJ & Elliot and a few other members of the team, it became clear that this was a mission I wanted to be a part of.

As a Product Engineer at PillPack, I will spend much of my time alongside the rest of the engineering organization building the web interface that the pharmacists use to maintain the operation, and customers use to manage their own prescriptions. PillPack is very much a product and design-driven solution and to that end, I will also have the opportunity to spend a great deal of time thinking critically about the product and how it can scale to meet the evolving needs of our users.

I would be remiss if I did not extend a special thank you to one of my closest friends: Jacob Mulligan. Jacob reached out to me when I wrote about my decision to take time off from school, as he was also considering a similar move at the time. I suggested he spend some time with the TechStars Boston program as a hackstar. Several months later, he called me to tell me he had joined PillPack — a company apart of the then current TechStars batch. I had just moved to San Francisco to work with Kyle learning web development. Almost a year later to that day, I couldn’t be happier to accept an offer to work alongside Jacob and the rest of the PillPack team.

And lastly, a big thank you to all of those who’ve provided invaluable support, perspective, and challenge throughout this journey so far. You know who you are. 


Giving Back to the Developer Community as a Junior

It’s been just over a year since I first started programming; that is a sobering and exciting realization. One of the most rewarding and meaningful parts of this journey has been discovering how supportive the developer community is — agnostic of geography. Wherever you may find a developer — Boston, SF, Moscow, or Goa — you’re likely to find someone who is willing to answer an email about a vexing database index issue, sit down and talk about the pros and cons of various javascript frameworks, or maybe even host an apprentice for several months and alter the course of an individual’s life forever (I’m looking at you, Kyle Bragger). As a comparatively inexperienced web developer, I’ve been thinking about ways I can give back to a community I have learned and taken so much from. Here are a few I came up with:

Mentor a younger developer - It may seem counterintuitive: one inexperienced developer working with an even more inexperienced developer. But I’ve found it can be quite the opposite. While you may not be able to answer some of the larger philosophical or technical questions that underpin a particular language or framework, you’re able to provide something just as valuable: empathy. You understand what it’s like to undertake the absolutely daunting task of learning a new language, if only because you’re still at the relatively early stages of learning yourself. And you also understand how to break through some of the common walls that crop up when you first start learning, because these challenges are fresh in your memory. While you may not be qualified to teach on a professional level, you’re empowered nonetheless to provide inspiration, encouragement, and some degree of knowledge to someone interested in programming — an ability that may make the difference between a person who tries programming and gives up, and a person who tries it and succeeds.

Contribute to open source projects - This is an obvious, low-hanging fruit. Inexperienced developers are intimidated by the notion of submitting a pull request to a popular open-source project for fear of embarrassment or failure — perhaps rightfully so. But it’s important to remember that you don’t have to refactor a method or fix a conditional statement in order to be helpful. Start small and work on making the documentation a bit clearer. It’s painfully obvious how useful something as seemingly small as this can be for a project. My buddy Alex Wheeler did this in thoughtbot’s trail map project.

Give a talk - Much like the previous point, I think there’s an intimidation bias at play here. You don’t have to give a complex talk on how to extend Ruby’s method_missing to handle edge cases in timezone formatting. Start small and work your way up from there. Find a local meetup with smaller attendance if large groups intimidate you, pitch a topic to the organizer, put together a small slide deck, and be prepared to chat for 10-15 minutes followed by a short Q&A. At a loss for topics? Pick a module of a programming language, learn it front to back, and then present on it. It will give newer developers a look into a useful part of the language, while offering more experienced developers a refresher or perhaps a different take on the topic. If you’re in Boston, thoughtbot’s monthly project night is a great place to start.

Buy a tool or a book - As developers, we depend on the open-source community in one form or the other. Whether it’s using a gem over and over in a project, or hanging out on #irc asking for help about a specific framework, we’ve all taken help gratis. By purchasing a tool or resource from folks or organizations who spend considerable amounts of their own time and energy helping others, you can express your sincere thanks and appreciation for their efforts, while also incentivizing a similar use of their time moving forward. To that end, check out thoughtbot’s book on backbone.js & rails if you’re looking for an awesome primer on the subject.

It’s important to keep in mind that being a member of the development community requires a symbiotic relationship — one that relies on the mutual participation of most of its members for future growth and benefit. So the next time you reach for a sweet gem or free text editor, give a quick thought to how you might be able to give back to the folks who helped get you where you’re going.

disclaimer: I don’t work for thoughtbot, nor was I paid to write about them in this post. I just use a ton of their resources — blog posts, gems, project nights — and wanted to find a small way to express my thanks.

Any thoughts on this? Find me on Twitter (@jcap49)


Productizing Cryptocurrencies

The following is a syllabus I drew up for a 4cu independent research during my last semester at Babson. 

Independent Research Proposal: Productizing Cryptocurrencies

Babson College

Spring 2014

Student: John Capecelatro

Faculty Advisors: Professor Charles Winrich, Professor Steven Gordon

Learning Objectives:

The purpose of this independent research is to explore the burgeoning realm of cryptocurrencies to further understand what opportunities exist for building a technology business in this space. Beginning with Bitcoin in 2009, cryptocurrencies have, like other modern fiat currencies, have provided a medium for transactions. Unlike other currencies, however, cryptocurrencies are based on cryptography and their values are derived from different algorithms that determine how many units of the currency will be produced. This form of currency is considered to be distributed, decentralized, largely anonymous, and digitally secure. Research — in the form of blog posts, theses, interviews (phone and in-person), and programming projects — will provide ample exposure to the history of cryptocurrencies, the factors leading to their recent prevalence, the risks and opportunities of their use, and the swath of market opportunities that exist around their presence. Based on collected research, two projects will be built: a Bitcoin wallet on a Raspberry Pi, as well as a larger prototype of a cryptocurrency-centric product — including mockups and code.

Context (problems to be investigated):

During the fall of my sophomore year, I decided to immerse myself in the technology startup community in Cambridge. In this community, I discovered a large group of supportive, intelligent, and motivated entrepreneurs using technology to address any number of opportunities they had discovered across a number of different markets. After completing an internship during the spring semester of my sophomore year in which I helped launch the Startup Institute, I decided to take a leave of absence for the entirety of my junior year.

After spending the fall in London working at a venture capital firm and learning a bit more about the fundraising side of technology entrepreneurship, I moved to San Francisco where I completed a three month apprenticeship to learn to web development. The time spent learning to build web applications helped illuminate the expansive number of opportunities available to those who possess such a skill set. Whereas I had originally imagined such power would be directed at seemingly important problems, what I saw instead was its use in building disappearing photo apps. Moving forward, I resolved to direct my evolving skill set in web development towards more meaningful problems.

During my time in San Francisco, the advent of bitcoin and other cryptocurrencies had begun to captivate a savvy audience of early adopters. In the intermittent time, companies like Coinbase and Circle have raised millions of dollars to address various areas of the cryptocurrency market. I became fascinated by the perceived value that bitcoin and similar currencies possessed - both as a value store like other modern currencies, but also as an important development in computer science that could have applications outside of the financial realm.

Since returning to Babson in the fall, I have been excited to watch bitcoin become an extremely popular — if sometimes notorious — financial instrument in the small circle of early technology adopters and beyond. This excitement has helped fuel a desire to spend meaningful time researching a still-nascent technological development that holds implications for the way we think of security and currency in the future. As I think about my career path moving forward, I see my continued growth as a web developer being inspired by the evolution of bitcoin and a desire to build products in this space.   Ultimately, the goal of this independent research is to glean enough information to build a minimum viable product that addresses one or more market opportunities identified during the course of study.

Required Materials & Course Assignments:

Found below is a breakdown of the various mediums by which the independent research will be conducted.

Hardware & Software - below is a list of the technical tools to be used during the product building portion of the independent study. As described above, these tools will be used to build a minimum viable product that addresses an opportunity in the cryptocurrency market identified by this independent research.

Raspberry Pi (affordable computer chip used for building software, hosting applications on an independent server, and a number of other uses)

Raspbian (proprietary software developed for the RPi)

Electrum (for Bitcoin wallet and backup)

Ruby on Rails (framework for building scalable web applications)

Reading - below is a selection of pieces that have come out in the past several months and years on cryptocurrencies. It is worth noting that very few books have been written on the subject as it is so new. A large portion of this independent research will involve continued observation of news sources to incorporate the continued publication of news articles and blog posts on the subject.

Original Bitcoin Whitepaper

Blog post: “How the Bitcoin protocol really works”

Book: Bitcoin Primer

Book: The Ascent of Money: A Financial History of the World

Thesis: “Design and security analysis of Bitcoin infrastructure  using application deployed  on Google Apps Engine.”

New York Times articles:

The Bitcoin Mines of Iceland

Bitcoin is Evil

Bitcoin, Nationless Currency, Still Feels Governments’ Pinch

Disruptions: Betting on a Coin With No Realm

The Economist articles:

Bitcoin Under Pressure

Bitcoin paradise

The Bitcoin Bubble

Bits and bob

Other news articles:

Could Bitcoin be used as an ultrasecure notary service?

Bitcoin is Good

A framework for pricing bitcoin

Blog posts:

Bitcoin: What is it good for?

Bitcoin is money, Bitcoin is a bubble

The Bitcoin Central Bank’s Perfect Monetary Policy

Interviews - these three people are those I’ve identified as being prominent in the discussion around cryptocurrencies and have either founded or invested in companies in the space. I chose a combination of investors and founders, as I feel perspectives from sides of the table are useful in crafting a holistic understanding of the opportunities and challenges that exist in the space.

Jeremy Allaire - Circle

Fred Ehrsam - Coinbase

Marc Andreesen - Andreesen Horowitz

Involvement of the Advisor(s) - Both advisors will provide guidance and feedback around the area of research, as well as the project proposal and minimum viable product. Professor Winrich will focus specifically on the construction of the RaspberryPi bitcoin wallet, whereas Professor Gordon will assist with the web development component of the research. A schedule for meetings during the course of this independent research is to be determined shortly.

Graded Deliverables:

1. Raspberry Pi-powered Bitcoin Wallet and related code - This deliverable represents a manageable combination of research and product building that can be accomplished during the first half of the independent research. While bitcoin wallets exist in various forms currently, there is still an ongoing conversation around which combination of tools is most useful for securely storing bitcoins and/or other types of cryptocurrencies. Completing this portion of the research will provide a meaningful introduction into an evolving product in the cryptocurrency market, how it is built (drawing on curriculum completed in a previous course: Electric Technology (Science B), and what market viability such a product has moving forward. Included in this deliverable will be several written pieces on determining which tools to use for a Bitcoin wallet, how to construct one on a Raspberry Pi, and any other pertinent topics.

2. Product proposal - This deliverable will be a five page paper in addition to exhibits (i.e. mockups of web interfaces and user flows) outlining a market opportunity identified during the course of the independent research, how the product seeks to address the opportunity, and ultimately a go to market strategy for building and launching the product.

3. Minimum viable product (MVP) - This deliverable will be the culmination of the independent research. Given the course of the independent research, this MVP will represent a first attempt at building a product to solve an identifiable problem in the cryptocurrency market. It will consist of a hosted web application (using Heroku for web application hosting) built with Ruby/Rails and common front-end languages. Application source code as well as a functioning website will comprise this deliverable.  

Conclusively, it is worth noting that the ultimate objectives for the course of this independent study are to have a completely functional Bitcoin wallet mounted on a Raspberry Pi, as well as a prototype for another cryptocurrency-oriented product. Given the time constraints of this independent research, if a prototype is not completely functional by the end of the semester, all finished design mockups and code — in addition to a document outlining the progress of the prototype, known issues, and an action plan for the remainder of the build — will be turned in for grading consideration.


Raspberry Pi meet Ruby

To get started with setting up your brand spanking new Raspberry Pi (Ruby or not)i, you’re going to need a few things:

Rasperry Pi Model B $40

RPi Case $8.99

SD Card (16GB) $12.99

WiFi adapter $30

USB Hub $12.99

HDMI cable $14.99

Total:    $119.96

You’ll also need a wired keyboard and mouse, an HDMI-ready external monitor, as well as a micro USB charger. The last bit can be a phone charger as long as it has at least 5V at 700a. Anything greater is fine, anything less isn’t. I got away with using a $11 keyboard and a wireless mouse I already owned, with the adapter plugged into the USB power hub.

1. Unpackage your Pi and the rest of the goodies, making sure not to transfer any electrostatic shock to the device — a big no-no that could fry the device and make it worth slightly more than your next coolest desk toy.

2. Format the SD card using another computer with an SD drive (internal or external).

3. Meanwhile, download NOOBs (new out of box software) and sidestep the shame as you walk through the door…

4. Extract/unzip NOOBs locally, copy all files contained within the folder (but not the folder itself), and paste the files onto the SD card. The files should be at the top level directory — if they’re not, the Pi won’t boot properly.

5. Plug in the keyboard, mouse, (USB hub if you’ve got one), SD card,  HDMI cable, and finally the power supply. The monitor should show the Pi booting up to a GUI, in which you can select an OS to install. I first installed Raspbian.

6. Once Raspbian’s good to go, you’re going to want to make sure your keyboard is set to a US locale (assuming you’re, of course, in the US), as the default is the UK — a fact which makes it a bit pesky to setup wifi configs among other things.

  • Select (4) Internationalization Options
  • Select (3) Keyboard Layout
  • Hit <enter>
  • Navigate to English (US) which is on the next page

7. Setup Wifi on the Pi

8. (optional — complete this step if you want to control your pi remotely) Check your wifi setup by ssh’ing into the Pi from another computer

9. Install Ruby

And there you have it — you’re running Ruby (and Rails if you so wish) on your Pi!


RaspberryPi.org Quick Start Guide

RPi Ruby on Rails


Creating Scheduled Workers with IronWorker (Rails 4)

From routine scraping of server logs, to test suites that run at a given time each day, to queued messages that are autoarchived every month - scheduled processes are commonplace. When I sat down to think about building Bonsai, I knew that the core of the product was to involve the daily sending of text messages. In other words, I knew I needed to build something that would allow me to: 1. define an action, and 2. repeat that action regularly over a given interval. In the context of a Rails development environment, I looked at the whenever gem, cron, and iron.io’s IronWorker. Ultimately, I settled on the latter for its extensive documentation, useful analytics and its scalability.

Note: it’s worth mentioning that in hindsight I’d consider using the whenever gem were I to build this over again. IronWorker’s a fantastic service, but in that it’s a robust service, it’s probably better suited for web applications doing much heavier lifting than mine currently is.

1. Set up a free (trial) account at iron.io and get your credentials all squared away in your application.

2. Snag the IronWorker gem and include it in your Gemfile.

3. Create your first worker. This involves the creation of two files. The first defines the actual methods to be executed on some schedule:  

While the second is a sort of recipe that defines what dependencies are needed in order to execute the worker. Philosophically, you should approach constructing workers as if the worker itself is located outside the Rails stack, meaning that all of the Rails magic (even the fun stuff we love to take for granted e.g. ActiveRecord, ActiveModel) isn’t accessible in the worker unless explicitly defined:

4. Navigate to the directory where your workers and manifest files are stored (usually ./workers) and upload them to iron.io using the IronWorker CLI.

5. Implement the relevant code that executes the worker in the Rails application itself.

6. Bask in scheduled glory.

Any questions? Feel free to shoot me a note in the comments. If you’re interested in pieces like this and more, have a follow on Twitter (@jcap49)


Hunter S. Thompson & Visionary [Product-Building]

I find that by putting things in writing I can understand them and see them a little more objectively … For words are merely tools and if you use the right ones you can actually put even your life in order, if you don’t lie to yourself and use the wrong words. - Hunter S. Thompson

When I sit down to write, I’m usually cognizant at some point or another about the purpose of what I’m writing. Maybe it’s to teach - explaining a particular use of a gem in a Rails project - or to explore - an off the cuff poem about a past lover - or to inform - announcing the launch of a new product. And usually, I find that the purpose tends to inform my diction, voice, time spent writing, and the amount of revisions I make. I’ve been working on a new project recently, and came across a purpose I find to be equal parts useful and challenging. And that purpose is to conceptualize.

Programming isn’t the hard part. Designing and building a meaningful product is. I’m not here to write about how writing can offer a definition of meaningful though - go ask your buddies on Twitter; I’ll hasten a guess that you’ll find a number of exciting (read: conflicting) definitions. What I’m here to write about briefly is how I’ve found writing to be invaluable in crafting the structure, feel, and vision of what you’re building. So much so that I will not start another project before first jotting down a few sentences, and then after noodling on those for a bit, putting together a post with a lengthier dissection of what’s being built.

I think primarily about two things when writing about new projects:

Why: Most importantly, why are you sitting here writing about this project? What is compelling enough about it that you see it fit to spend time - a valuable commodity - to build? What problem are you solving? The what - or the implementation - is likely to change, but I find the why to be much more static, and by proxy, poignant. I also find that this exercise helps to tease out any hypotheses I have about my project.

What: What does the project do? How is it solving the problem you outlined above? What is the medium through which you hope to provide value, whether tangible or intangible?

Like Thompson, I’ve found it’s much easier to remove this preexisting perspective bias around a project when things are written down. Putting down words on paper or on screen serves both a practical and a philosophical purpose.  Practically, it is an outlet for exploring different articulations of a vision, thinking through user stories, describing certain feature sets, and otherwise providing a basic outline of what is being built. Philosophically, it lends legitimacy to the project, transcending this boundary of “sweet idea” to “work in progress” - a boundary I’ve found many folks to have a difficult time crossing. And just like all good writing went through some sort of revision process, so does a project. These words are dynamic, changing as ideas evolve. Revisions of posts about projects have turned into revisions of the projects themselves. Sometimes small things change - different words used to illustrate a value proposition. Other times, large things - like entire visions - do.

With anything you’re building, I challenge you to spend some meaningful time writing about it (there’s that word again, but this time, your own definition is the only one that matters).


Chopsticks & Product Design

I sat down to eat a bowl of curry the other day, and instead of a fork, knife, or spoon, I was handed a pair of chopsticks. This wasn’t the first time I had used chopsticks – for the past few years, I had pretended I was competent at using them while eating whatever mediocre sushi I could find at my school’s dining hall. But this was the first time I had given serious thought to their design, and what that communicated about the intention and personality of the region in which they originated. I found myself consumed by this vein of thought.

At their core, chopsticks serve a distinctly practical purpose: to help the user eat. Rams’ famous design principles - specifically those around the aesthetics and usefulness of a product - find comfortable solace in this utensil. Compared to its continental favorites - the fork, knife, and spoon - chopsticks are simple in formation. Two tapered, long pieces of wood or plastic that rest comfortably between the fingers of the individual, offer an austere tool that is simple, ergonomic, and comfortably elegant. The use of continental utensils implies a diet filled with an overwhelming variety. Chopsticks are comparatively narrower in scope and necessitate a simpler diet.

This distinction is what I find to be most fascinating. By offering less dietary freedom, chopsticks are actually communicating a societal intention around simpler gastronomic tastes. To extend this assertion, I am curious as to whether a simpler gastronomy might also imply a desire to live simply in other areas of life, or reflect certain aggregate personality traits (e.g. peacefulness, calmness). Having not personally traveled to Asia, I can’t say for certain whether this assertion is subjectively true.

The current state of technology (i.e. hardware/software/web/mobile) product design is trending towards insular thinking. The Samwer brothers’ replications notwithstanding, common threads can be traced from app to app, site to site, indicating design inspiration gleaned from within a given boundary. Certainly, there’s value in understanding how to craft a user experience that is familiar and easily maneuverable for the end user, which supports reusing certain style patterns (e.g. green and red hues for success and error notices, respectively) and functional elements (e.g. sidebar, pullout navigation - found in the Gmail mobile app, and Medium’s web app, among numerous examples). But there is also value to be had from inspiration outside today’s hottest mobile app - inspiration found in everyday objects. The key is how to abstract this pre-existing human behavior and effectively transposing it to a more technology-facing application.

What I find to be most applicable from this brief analysis of chopsticks centers on two concepts: 1. the sheer simplicity and elegance about the utensil (something that could applied in context of a UI design, registration flow, confirmation email etc.), and 2. its intrinsic constraining nature (some products try to solve every problem the user has instead of focusing on a few pain points and solving them effectively). Ultimately, I think products outside our perspective bias offer a real opportunity for developing unique, yet functional designs on web and mobile properties


Enabling Superman: Extending the Devise Gem

When scaffolding Rails apps that require any sort of admin/user profile setup, I turn to Plataformatec’s Devise gem. It’s a breeze to install, simple to understand, has a ton of awesome capabilities baked in, and is flexible enough that you can customize its components should the need arise. And customization is what I want to touch on here, specifically extending the default controller that handles user registration.

I can think of a number of fun instances where you might be keen on doing this, but I’ll pick one that I most recently encountered. I’m working on a side project where the user flow goes like this:

1. User lands on the home page.

2. User submits a form of parameters for a text message object (related specifically to the functionality of the web app in question).

3. User is redirected to another form to submit more parameters (this time related to user registration, e.g. email, password, and password confirmation).

4. Upon successful submission of both forms (via two separate requests), the text message object is created, the user is registered and is, finally, associated with that text message.

So I want to allow the user to first create this object, then sign up for the service. This is a bit backward from how Devise is configured. By default, Devise presupposes the user has been created and registered in order to allow for the creation and association of a related object. But in this case, I wanted to create the text message object first, then allow the user to create an account, all the while ensuring that the saved text message would ultimately be associated with that user. On top of that, I wanted to do a bunch of neat things during the creation of the user.

This involves assigning an arbitrary user_id to the text message object, passing that user_id (the foreign key that associates User objects to TextMessage objects in a has_many relationship) as a session variable that can then be accessed and manipulated during the creation of a user. That session variable would be used to query the database for that text message object and assign the newly-created user’s id as the text message’s user_id, thus properly associating the two objects.

Here’s how it happens under the hood:

1. Create a new controller that inherits from Devise::RegistrationsController

2. Assign a route to whichever action in that new controller you’re looking to extend (note the block you have to pass in here) 

3. Be sure that route is specifically mentioned in the form submission for the user object 

4. Write whatever cool magic you want to exist in this extended controller.

5. Remember to instantiate a new instance of a user object in whichever controller is mapped to the page where the request will originate from (especially if it’s a different controller - I used a separate PagesController for the time being) 

As always, if you have any questions, do feel free to give a shout below. And if you dig this, I’d love to see you on Twitter (@jcap49)


Rails 4 & Heroku: The Asset Pipeline Quandary

So you’re riding Rails 4 and are throwing your recently-built social/mobile/local app on Heroku so you can have something live to demo for tomorrow’s pitch in front of Marc & Ben? But shit - none of your assets seem to be propagating properly. Not to worry though, there are just a few new adjustments for Rails 4 apps that need to be completed in order to get things back in tip top shape. Before I go through these adjustments, I’m going to assume you’ve gone through the basics of deploying your app on Heroku. Once you’ve got that sorted, have a shout at the below if your assets are still missing.

Add the following gem to your Gemfile

gem 'rails_12factor', group: :production

Add the following to /config/production.rb

config.serve_static_assets = true
config.action_dispatch.x_sendfile_header =  ‘X-Accel-Redirect’
config.assets.compile = true

Feel free to push everything to Heroku and refresh. If things still aren’t sorted, keep on reading.

Enable the following experimental feature:

heroku labs:enable user-env-compile -a yourapp

Push to Heroku again and have a shout. Still broken? Try precompiling your assets locally then committing:

heroku run rake assets:precompile

Note: this command will have to be run after any changes to the asset pipeline are made.

Hope this helps - feel free to ping me with questions on Twitter (@jcap49).


Persistence & Opportunity: Finding a Job at a Startup

This post is a published as a part of this week’s Startup Edition.

Much has been written about how to find a job at a startup so I’m going to skip the perfunctory intro around the rewarding and challenging environment that attracts many to working in this community, and instead share a few pieces of advice that have been useful to me in my journey so far.

Find a mentor. This is an oft-talked about topic - I wrote a longer post on how to go about finding one earlier this year - but is certainly one worth repeating. The right mentor can quite simply be the difference between spinning your wheels and making traction in the job hunt. From providing perspective and focus on your search, to making introductions when appropriate, these gracious individuals can be an invaluable resource.

Reflection before action. Many think they want to work a startup then dive straight into job apps and coffee meetings. This is a mistake. Startup land is a diverse place with any number of different products, companies, leaders, advisors, roles, locations, and industry verticals. With that in mind, it’s worth taking a weekend to do some research and reflection around what gets you really excited. Whether it’s product marketing, the London tech scene, or consumer mobile apps, it’s important to have at least a rough outline of what a possible future opportunity would look like. This will obviously make finding such a thing a smoother process.

Action after reflection. Once that reflection has happened, you can start to act on that information. Make a list of the 10 companies (and their leaders) that - after researching thoroughly - you’re interested in. Then write 3 or 4 reasons you’re interested in each of these companies - doing so will help you to deep dive on why these companies are appealing. And finally, give careful thought to what your ideal role would be and what a potential first project would look like if you were to be hired. This kind of thought will be useful for cold emails and coffee meetings.

Cold emails are your best friend. Take that list of 10 companies and start reaching out to folks that work there (or invested in the business) to get a better sense for what it’s actually like to be a part of the team. The ask in the email could be general (e.g. “I’m interested in learning more about the company culture” etc.) or direct (e.g. “I’m keen on chatting about how I can accel as a product engineer at Company XYZ). For the latter approach, leverage that list from above for a small pitch in the email body about why the person on the receiving end should take the conversation further. Keep the emails short (5-10 sentences) and friendly - remember, you’re not convincing them to hire you from that first email, you’re just convincing them it’s worth their time to continue chatting.

Persistence. This is the single most important part of finding a job at a startup (and is also a salient point for a number of other life matters). It can be a frustrating pursuit at times, but persistence is an admirable trait (not to be confused with annoyance which people aren’t so keen on) that many folks at the startup level like to see. If the cold email goes unanswered for a week, send a short follow up note. If a role isn’t available currently (and you have the runway to do so), spend a few weeks working on a project that can help convince the company that when such a role is available you’ll be at the top of the list. Look to folks like Tristan Walker if you need some ideas on this persistence thing.

Best of luck with the job search - if you should have any questions or would like some perspective, I’m happy to discuss further offline. Find me on Twitter - @jcap49.

And do subscribe to Startup Edition if you’re interested in reading more posts like this!


blog comments powered by Disqus