Hiring a Developer
This is my message to the applicants for my new job posting.
When posting on some of the global freelancer and contractor sites, you often get a number of low-quality applications. So I wanted a filter to make sure that I wasn’t wasting my time when it comes to the actual interview.
The key points I wanted to get across:
- This is a learning opportunity; we have a process and it works
- We use some specific technical tools; we will look at changing them in the future but for now this is what you will be using
- There will be expectations on you (and this is what they are)
- We will talk regularly; and not just about work
- I want you to be involved in the future of this company
It’s quite heavy going but I think it’s good to set this stuff out early on.
What do you think?
Thanks for your interest in the Ruby on Rails developer position I recently posted on [freelancer site].
Before we begin, I’d like to explain a bit about who I am and what I’m looking for.
Firstly, I’m a Rails developer myself. I started in 2005, using version 0.9 (with Ruby 1.8.2 if I remember rightly). This means I have quite a particular way that I like to work.
Secondly, I’m based in the UK as are most of my clients. I don’t really mind what time you work but it’s important that there are a few hours each day when we both overlap so I can talk to you about any issues.
Thirdly, we need to talk. I use Slack and I would like you to be in there when you’re working for me. If you’re offline, I may leave you messages so when you log on, please check the scrollback and see if there’s anything important. I also think that as we are working together, it’s important to get to know each other — so expect chat about things other than just the job at hand.
I have a number of existing projects (Ruby 2.0+ Rails 4.1+). Some of these are well-written, some of them are awful. I will try and make sure you don’t have to work on the awful ones. Nearly everything is written in Rails, using Delayed::Job/Sidekiq, MySQL and maybe Redis. I am comfortable with this stack and the clients will not be paying to change it. Most of these applications are deployed to Amazon Web Services using Elastic Beanstalk. Testing-wise, I use minitest-spec and Spinach (which is like Cucumber but much much better); for full-stack testing I use poltergeist/phantomJS. User-interface-wise most (but not all) projects use JQuery and Turbolinks. For CSS, I just use Bootstrap — the clients aren’t that bothered about fancy design — as long as it looks nice and works responsively, that’s enough for them.
The single most important thing is that we meet the client’s expectations. In order to do this, I follow a process that is roughly like Scrum.
At the start of a project iteration, we talk to the clients and figure out what they want. We then draw up some UI sketches and write some user stories using Gherkin. The client then approves these. The aim is “if it matters to the client then it needs to be in a .feature file”.
We give the Gherkin stories to you and you create a new branch in Git, then copy the .feature file into place, use spinach to auto-generate the steps files (bundle exec spinach features/new-story.feature –generate) and start writing the code for each step. Implement the steps until they pass. Then open a pull-request, someone will review the code, we refine it until we’re happy with it, and the code gets merged into master, deployed to a staging site and the client approves it. Then it gets merged into a production branch and deployed to the live site.
This is the ideal case — it doesn’t always work that way but we should try to do that as much as possible.
However, the key points will always be: the client can read the specification before we start work and the client gets a chance to approve the work before it goes live.
I have some opinions about how Rails code should be structured (particularly with ActiveJob and ActiveRecord callbacks) — but we can talk about that later. The way I do things has been learnt from many years of long-term projects and I hope that you’ll find that you become a better developer as you work this way. However, I’m not always right so I’m also perfectly happy to listen to any suggestions you may have.
So these are my expectations:
When working you are present for a few hours during UK business hours in the chat room, and expect to talk about all sorts of things
You will be writing code to match the .feature files that have been approved by the client
We will have regular code reviews
You will indent your code correctly in the proper Ruby fashion :-)
Most of the work is pretty dull, but as long as it meets the spec and the code is maintainable, you can do it how you want (but I do have some best practices in mind)
There are some very interesting projects coming soon, with alternative technologies (front-end JS frameworks, NoSQL databases etc) but we need to make sure the core Rails stuff is handled first
So there you have it.
If that sounds good to you then we can talk further.
Baz (aka Rahoul)
Originally published at The Art and Science of Ruby.