Taylor here, YNAB’s CTO. We’re looking for another developer to join our team! Is it you? Read on to find out…
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.
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!
- Your cover letter should be your email. It’s more important than your resume.
- If you have one, send your resume in PDF form. However, it’s okay if you don’t have once since we realize that you might not be on an active job hunt and might not have one sitting around.
- Include “Postgres Rocks” in the subject line of your email.
- Applications should go to: YNAB-YNAB0251@applications.recruiterbox.com
- The deadline for applications is June 10th, at 11:59pm. (We hire our ideal candidate as soon as we find him/her – don’t put off shooting us an email.)
- Answer the following questions.
- What are your two strongest programming languages (besides SQL)? Is there another language that you’re curious to learn next?
- What is a shortcoming of Postgres that you have had to work around?
- What are your preferred server/database monitoring tools?
- Briefly describe the techniques/tools you use to debug SQL code (e.g. functions, etc.)
- If you were interviewing a prospective candidate for this position, what would be a good interview question to ask to find out if a candidate really knew their stuff?
- Given a table “Transactions” with the following 4 columns:
- ID : integer, primary key, id of the transaction
- Account_ID : Integer, foreign key, id of the account to which this transaction belongs
- Payee : varchar(200), name of the payee/store where the purchase was made
- Amount : decimal, amount of the transaction
Write a PL/pgSQL function called “GetPayeeStats” that takes two parameters: an account ID and a payee name. It returns two computed values (using your preferred method of multiple return values):
- the average amount spent for that payee in that account
- and the total amount spent for that payee in that account.
For example, if my Transactions table looked like this:
ID | Account_ID | Payee | Amount ------------------------------------- 1 | 5 | Starbucks | -5.00 2 | 8 | Starbucks | -20.00 3 | 5 | Starbucks | -10.00
If I called the function with an account ID of 5, and a payee of “Starbucks”, it would return the average of -7.50 and the total of -15.00.
We look forward to hearing from you!
P.S. If you’re not interested in or available for this position, but know someone who is, we would really appreciate it if you passed this along!