YNAB BLOG

We’re hiring a Postgres Expert/Back-end Engineer

Taylor here, YNAB’s CTO. We’re looking for another developer to join our team! Is it you? Read on to find out…

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.

16 Responses to “We’re hiring a Postgres Expert/Back-end Engineer”

Greetings. I have been using YNAB for a while and I think you have a great product. Besides being an xcode developer, i am also a translator (english-spanish). I think it would be a great idea if you could expand the YNAB love to the spanish speaking comunity, both inside and outside the US. I would be glad to contribute with you guys in case you are interested.

Thanks Enrique. We are definitely laying the foundation to be able to localize in the future. Localizing YNAB into Spanish would imply a lot of other things we’re not sure about yet (namely offering support in that language), but we like the idea of having YNAB in more languages.

You are absolutely right! What sold the product for me was the awesome support, the webinars, the emails, etc. I am writing you from Ecuador and I know for a fact many people here and in latin american in general would LOVE this budgeting concept and the way YNAB handles it. Anyhow, whenever you decide to take the leap towards spanish localization/support, let me know if i can assist you. Cheers!

I applaud you for a great job posting. :-) If I were in need of a new job, I would apply with you guys in an instant. (It’s pretty rare for a posting to line up with my experience so closely). Keep up the good work.

Can’t help you but super excited to hear a web version of YNAB is under development. The thing is, at my workplace, I cannot get to certain things that are file oriented, like Google Docs, or Dropbox. So I am hoping the the web YNAB will not have to relate to a local Dropbox file on my PC, or this won’t work for me. There are a lot of us with locked down workplaces like this, so if possible please keep that in mind for the project design. Thank you.

Not looking for a position now, but have to ask: will the api be opened up to allow development of tie-in apps? With an open api, I can think of a variety of different functions that would be cool to set up and play with…

I agree on the solid job description. Well done. If you are ever looking for a database/web developer in the future, perhaps a little less experienced than this position requires, please do send out another email so I can apply.

I don’t think I’m a good fit for this one, primarily because of my lack of experience with Postgres, but I do consider myself at a very high level in SQL with experience mostly in MSSQL and Oracle, which is quite transferable considering the standards of SQL.

Surprised you went with ember over angular given the market adoption rate of the two (and which will be easier to staff). Non-the-less, Glad to hear that SPA’s and API’s are in the future @ YNAB! Now if you were thinking in the terms of Domain Driven Design & reactive non-blocking programming – then you would really be on the edge (and not have to worry about hiring *SQL dev’s with traditional DB’s that can be incredibility difficult to scale at web-scale). Anyways – I am pumped about YNAB’s future! I see very good signs in your overall product plan reading through your job description. Great work!

I’m very much interested in the job after reading such a nice job description and have some good experience in postgresql development and DBA stuff, keen to learn new technologies and was looking for good remote option since while. Will definitely apply.