Skip to content
This repository has been archived by the owner on Jun 8, 2022. It is now read-only.

dbinetti/votizen-careers

Repository files navigation

Careers at Votizen

This packet is designed to provide:

  1. An Overview of Votizen
  1. What We Are Looking For in team members
  1. What We Offer in a career
  1. The Process we use to find good matches to join our team
Overview

Our Mission

Our mission is to create a world where political influence is based on the size of your network and not the size of your checkbook.

Our Team

David Binetti, our CEO, has ten years industry experience and was the creator of one of the first examples of government e-transparency: USA.gov. Jason Putorti, our designer, was the lead designer for Mint.com and is one of the most talented designers in tech. Matt Snider, our engineer, is a front-end guru and has written a book on Javascript (literally). Jeremy Dunck is a Python expert and the Secretary of the Django foundation. David Gouldin is contributing to the Requests library, the successor to httplib2. Emily Leathers was the third engineer at Rapleaf. Erik Rose built large-scale Django sites at Mozilla and is a published author and conference speaker. You get the idea: we want to continue the tradition of only hiring the very best in a given person's field of expertise.

Our Technology

We are data-driven company. We start with a database of the nearly 200 million registered voters in the United States with billions of rows of voter history. We then graph this data against the social networks of our members, empowering them to campaign for the candidates and causes in which they believe. On the front end, we employ a LAMP stack: specifically Ubuntu, Apache, MySQL/PostgreSQL, and Python (within the Django framework.) We also use cool stuff like Redis, Celery, Rabbit, Memcached, Puppet, Selenium, Nagios, Vagrant, HA Proxy, and Elastic Search on the back-end. And everything operates in the cloud; specifically, on Amazon Web Services using EC2, S3, Route 53 and other cloud goodness.

How We Code

Our development philosophy is based on one principle: speed. We practice Continuous Deployment; commits are pushed to production within about ten minutes. We don't have a staging server or QA department. This means that we need to have high discipline on test coverage to ensure that our build stays green. The emphasis is on fixing things quickly more than writing bug-free code from the outset. We have weekly sprints with daily standups and PivotalTracker keeps us on target, but otherwise we try to keep process to a minimum. It's all about developing features and shipping them to our users as quickly as possible.

Everybody Codes

We are building a technology company and expect people to be familiar with the tools we use to build our products. This means that everybody codes. Our designers have CS degrees. Our CEO built the first iteration of the product. Even our admin knows how to edit the Django admin. Now this doesn't mean that everyone's code makes it into production, but it does mean that we all can speak a common language and have an appreciation for what it means to develop a web application.

What We Are Looking For

Engineer

We want very smart people who are accustomed to moving fast under conditions of uncertainty.

Responsibilities

  • Analyze, architect, and develop applications on LAMP stack: Ubuntu, Apache, MySQL/PostgreSQL, Python (within Django framework).
  • Research, implement and integrate new mechanisms and technologies to solve technical problems (don't reinvent the wheel).
  • Be prepared to move fast and be flexible, holding your own alongside some very talented engineers.

Experience

  • Experience with developing LAMP-based applications is required.
  • Solid knowledge of engineering principles, religion in unit-testing code, and an understanding of regular expressions.
  • Experience with the APIs from social networks like Facebook and Twitter.
  • Experience with database design and optimizations is preferred.
  • Experience with Python, Django and PostgreSQL is preferred.
  • Experience with HTML, JavaScript, and CSS is desired.

Apply

Apply to be an Engineer.


Product Manager

Serve as the primary interface between product and engineering.

Responsibilities

  • Use tools like PivotalTracker to keep the team on target.
  • Understand how to effectively translate marketing requirements into technical deliverables.
  • Keep process to a minimum; we are not looking for someone to write full-blown MRDs or PRDs. But we do need to deliver on time.

Experience

  • Unbelievable attention to detail is an absolute must.
  • A strong track record of delivering large, complicated products/projects with multiple moving parts will be preferred. This role is closer to project management than most traditional PM roles.
  • A strong technical background is required.
  • A CS or other engineering degree is preferred.
  • Borderline OCD is a plus. We're not kidding.

Apply

Apply to be a Product Manager.

What We Offer

Change the world potential

First and foremost, we're working on something that truly has the potential to change the world in profound ways. We're ensuring our democracy will be around for our grandkids, and that's a lot more important than building a revolutionary way to sell grilled cheese or running a quick flip on a Groupon clone.

Hard technical challenges

We have huge challenges in machine learning, classification, and scale. Our database already has every voter in the United States plus their voting history -- in some cases going back thirty years. This is a billion rows of data and we've barely even started. We need to figure out how to process this information in way that is meaningful to each and every voter starting in the US (200 million voters) and eventually abroad (Democracy is a growth business.)

Lasting Impact

As our success grows, more and more real people are going to rely on our tools to help form decisions about the future of our country. This means that millions of voters will use the tools our engineers create, and will use them every day. It will be a badge of honor that Votizen engineers work on something so important and fundamental to the lives of everyday citizens.

Agile process

We ascribe to agile development processes. We are big believers in test-driven development. We thoroughly document our code. We engage in continuous deployment. We don't have a QA department; when something escapes our test coverage and breaks we fix it immediately. For us, it's all about reducing the iteration cycles. Our processes favor quick identification of problems and fast recovery. Speed is the best prevention.

Great investors

Our lead investor and board member is Sean Parker, who has been at the forefront of several disruptive companies: Napster, Plaxo, Facebook, Causes, Spotify, and Airtime. We have some of the most prescient investors in the business, including Keith Rabois, Mark Goines, Ron Conway, Aydin Senkut, Chris Dixon, and David Cowan. These investors see a huge opportunity in a space ripe for disruption, and our investors are an incredible asset to the company.

Incredible Office

We have an incredible office located at 292 Townsend, immediately across from the Caltrain station at 4th and King. It is a space with a full commercial kitchen, twenty-foot ceilings, and a huge outdoor courtyard that simply needs to be seen to be believed. Every person says it is hands-down the best office in which they have ever worked.

Fantastic culture

We have a great culture that rewards risk-taking and creativity. We create features by taking the perspective of the user: "A member should be able to do FOO in order to accomplish BAR as measured by BAZ." After that, implementation is up to the engineer. We are very flexible in our work hours, as long as the job gets done. And we play hard as well -- the office is very competitive, particularly in Starcraft2.

Benefits, Perks

Our benefits and perks are quite light compared to other large companies. We do have have full health coverage for families, offer commuter checks, and generally try to be as flexible as possible in responding to team members' needs. But you can forget things like 401Ks, massage therapists and espresso machines. Our goal is to make our equity so valuable that all those things become rounding errors in our personal net worth.

Compensation

We place a premium on equity participation and not salary. Our belief is, "Salary to live on; Equity to retire on." In fact, we have a hard cap on our salary of $120,000. Many make less, but no one in the company makes more than that.

Process

Following is the hiring process to which we aspire. It is designed to be transparent, challenging, respectful, and above all -- fast.:

Prescreen

Once a resume has been received, our HR Director will arrange a 5-10 minute call to discuss the following questions:

  1. Have you done any web development?
  2. What is your experience in Python/Django?
  3. Are you familiar with startup environments?
  4. Are you willing to work out of our San Francisco / SoMa office daily?
  5. What is your interest in politics?

After the discussion a decision will be made based on one of two outcomes:

  1. Send resume for Qualifications Review
  2. No Match

Qualifications Review

We review a candidate's resume/code repositories to assess experience and qualifications. After the review, there should be one of two outcomes:

  1. Schedule Company Vision Presentation
  2. No Match

Company Vision Presentation

The Company Vision Presentation is a 10-15 minute phone conversation interview where David Binetti, our CEO, has the opportunity to present the company vision, answer any candidate questions, and generally assess whether there is a first-order match. This step is more for the benefit of the candidate learn about us, and to determine if it is worth investing time in the Remote Coding Problem exercise:

  1. If match and willing, conduct Remote Coding Problem
  2. No Match

Remote Coding Problem

The coding problem is included in this repository as RemoteCodingProblem.rst, and is a task that shows they know or can learn Django, Python, and Apache. The completed project should be checked into a public Github account, which we can pull down and run locally. The problem should take 3-6 hours, depending on the candidate's understanding of our technology stack and the amount of extras they add:

  1. If above bar, schedule On Site Pair Programming
  2. No Match

On Site Pair Programming

The on site pair programming is an in-person interview, where the candidate will be tasked to code a multi-layered problem on a computer while being paired with one of our engineers. The candidate should be asked to bring a laptop with them (and they can use the language of their choice), or we will provide one. After the on-site, a decision should be immediately made according to one of two outcomes:

  1. If good fit, schedule On Site Team
  2. No Match

On Site Team

The on site team is the final step meant to give all team members an opportunity to assess culture fit. Generally, this will be a full-day of interviews. Prior to the team meeting, the focus should be on matching the skills to the role. The team meeting is primarily (though not exclusively) for matching the personality to the culture of the company. After the on site team interview, all team members should come together to make a determination as follows:

  1. If good fit, Reference Check
  2. Hold
  3. No Match

Reference Check

Reference check should be the final assessment of skills. It is designed really as a veto in case any material information has been misstated or other major issues surface:

  1. If passes, Extend Offer
  2. No Match

Extend Offer

Once the decision to extend an offer has been made, the hiring manager must put together and present an offer package within one business day. No exceptions

Hold

Periodically we might find good candidates that would be a good match aside from timing (on one side or another.) These should be placed in a Hold status. Ideally, when candidates are placed on hold there should be a defined trigger to bring them out of that state. Examples include: vesting fully, finishing school, campaign ending, etc. It should not be a catch-all category: the supposition should be that all candidates are either hired or declined.

No Match

Most candidates will not be a match. While each case may be handled individually, all candidates who have on-site visits should be informed of no-match via phone. Others may be informed via email. All candidates will be treated respectfully.

Special Note for Recruiters

At Votizen we love recruiters! If you haven't already done so, please see our instructions on how to work with us at http://www.votizen.com/recruiters.

Questions/Contact Information

If you have any additional information or questions please contact Marty Schneider at marty@votizen.com or 415.690.8683.

About

The repo we used to manage the hiring process at Votizen

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published