URL

http://www.youneedabudget.com

Headquarters

United States

Twitter

ynab

Company's Other Jobs

Click to view

WARNING! This job is awaiting verification or has expired and may no longer be applicable
Category

Software Development

Posted

2014-05-23 07:40

Description

About Us

We’re a profitable, bootstrapped, growing company. We create beautiful personal finance software to help people implement our Method. We call it “You Need a Budget”, but everyone in the know just calls us “YNAB” (pronounced why-nab). For years now, lots of people have been buying YNAB and then telling their friends how awesome it is. (Google us and you’ll see.) We’ve got a desktop app, an iPhone app, an Android app, and our iPad app is in private Beta. We’re making people’s lives better and having fun doing it. Check out our culture manifesto (in the form of a Google Doc), where you can figure out pretty quickly if you fit in.

Now we want a web app and API

Our desktop software is great, but our customers would love to access YNAB on the web too, so we’re hard at work on it. We’re building our back-end API using a combination of Rails, Postgres, and PL/pgSQL, and we’re hosting it on Heroku. This API knows how to sync data with occasionally connected clients, and its first client is our web app. We’re building the web app as a Single Page Application using Ember.js and CoffeeScript. We wrote a client-side library in Typescript, that sits between the front and back-ends. It talks to our API, performs the business logic, and exposes data to front-ends like our web app, and eventually even our mobile apps.

We’ve got some cool stuff working behind the scenes, and we’re super proud of what we’ve built, but we’ll be a heck of a lot prouder when we ship it!

And that’s where you come in!

You have significant experience with Postgres and PL/pgSQL. In fact, you probably know enough that you could be our DBA. (We get some of that “DBA” stuff by using Heroku, but you can fill in the gaps.)

But you’re not just a Postgres expert. You’re also an excellent overall developer. You’ve built back-ends and web APIs before, ideally with Ruby on Rails. You know how to architect code and systems that other developers enjoy using. Even though you have become “the Postgres guy” around the office, you haven’t stopped learning and enjoying developing with other languages.

You would be helping us with virtually all of the above technologies, but your first focus would be on the Postgres database, the Rails app, and the client-side Typescript library that talks to the API. That means your days would be a mixture of Postgres SQL, Ruby/Rails, Typescript, and some JavaScript.

It’s fine if you don’t know Typescript, but you need to be fluent in at least one other statically typed language (like C#), and have a solid understanding of OO design principles.

We’d want you to work with us on a full-time basis (40 hrs/week). If you’re international, your status would be as an independent contractor. If you’re stateside, you can be W2, or independent contractor as well. It’d be your call.

You would be:

  • Writing and optimizing queries in Postgres to do fairly significant calculations for customers’ budgets.
  • Architecting and configuring our database layer for performance and security.
  • Helping determine what logic should go in the database vs the Rails layer.
  • Ensuring that we have a bulletproof database backup/restore plan in place.
  • Writing code in our client-side library to expose data in an easy-to-understand way.
  • Working with a small development team (~4 other devs, and our designer) on a regular basis. Our teams are small (the CTO is writing this job post), but we get cool stuff done.
  • Working from home most of the time, and working with us in person (or at someone else’s home) occasionally.

You’re the one we’re looking for if you:

  • Are a confident, humble programmer who would thrive on a small, remotely based team.
  • Are extremely familiar with Postgres SQL and and PL/pgSQL specifically
  • Are an excellent general developer—you just happen to know a lot about Postgres.
  • Can write performance SQL queries
  • Can optimize a database (indices, design, query optimization, etc), based on the usage patterns it’s seeing
  • Are extremely knowledgeable, and therefore paranoid about database, API and web security in general.
  • Can secure a database, and write queries in such a way that it makes it harder for other developers to do something dumb.
  • Have great architecture and software design skills. Our internal and external APIs need to be clean and intuitive. * Our client-side library will be the backbone of our applications for years to come, so we want it to smell great.
  • Have written solid, secure, and understandable web APIs before
    • Bonus points if they are public facing and well documented
  • Believe in, and write unit tests for your code
    • Bonus points if you write your tests first
  • Enjoy server admin/Devops. We are sitting on a PAAS instead of IAAS, but the more we know, the fewer 3am phone calls we’re likely to get.
  • Have excellent debugging skills. You know how to find bugs before they have good repro steps, step through code, optimize slow calls, and discover memory leaks.
  • Have excellent spoken and written English. (We’re an international team, so accents are fine!)
  • Use descriptive variable names
  • Enjoy optimizing/profiling code
  • Have an intuitive understanding of asynchronous code and promises
  • Geek out about automation, continuous integration, and continuous deployment
  • Are proficient in both dynamic and statically typed languages.
  • You’re self motivated, and thrive with directions like:
    • This table would be accurately described with a composite primary key, but we are concerned about the index size. Should we be?
    • We have 1000 beta users now. How is the database doing? Are we likely to see growing pains at 10k users? 100k? If so, where, and what can we do about it?
    • This series of API calls to the server looks too chatty. Can we refactor it to make it more straight-forward and less chatty?
    • The client-side library needs to get a long list of transactions, but we obviously can’t download/display all of them at once. How should the client and server-side API work in order to show only the relevant ones?

You get Bonus Points if:

  • You live anywhere remotely close to California, Utah, Baltimore, or Austin. (That makes it easier for you to get together with some of us if we want to work in person)
  • You do front-end stuff too. HTML, CSS, etc.
  • You’ve written some open source stuff, or made significant contributions to an open source project.

Major-Triple-Gold-Star Bonus points if:

You already use and love YNAB.

More about how we work:

You can read more about how we work in this Google Doc. If you’d like to work the way we work, well, that’s a good sign!

Application Info

Please sign in with Google or GitHub to view this job's application information. This is necessary to prevent companies from receiving excessive amounts of spam.

Country

Anywhere

Powered by Tramcar