Rake Routes

by Stephen Ball

Things Most Interviewees Fail to Discover

It’s a great time to be a Rails developer. Companies left and right are turning to Rails or using it already for efficient web development. If you know Rails and the web stack well then you have the luxury of choice: let’s make sure you make a good pick!

Your future team’s code quality

Your potential coworkers should be writing code that you appreciate. Just as they evaluate your coding skills, you need to evaluate theirs.

If the team doesn’t have any publicly available code: ask for some! While you’re at it ask them for their thoughts on the latest developments in Rails. Do they have opinions on the Am I doing it wrong Rails gist? How about service objects in Rails? TDD? What gems/plugins are they using (e.g. for background processing, profiling)? Are there any test frameworks that you love to work with?

If you are happy after seeing their code and talking with them about programming trends then you have much better odds of being happy with what you find in the company repo.

Team culture

Surround yourself with coworkers you like. You may think that you don’t need to like your coworkers: but this is a disservice to everyone. There are enough Rails jobs out there that you should be able to find a team that you enjoy. Work is a huge investment of your time so make it a good one.

Is the team a fun, lighthearted atmosphere of silly jokes and Internet memes or a proper and professional environment? It doesn’t matter which, as long it fits you.

Project management

What does the team do to manage tasks? How does work get assigned? How does code get deployed? You should be comfortable with all of these answers.

Work in the pipeline

What would you be working on should you join the team? What new projects or features are on the roadmap? If the company has no clear answers: be concerned. No clear direction means thrashing for the development team. If they can’t go into specific details that’s fine, but you should be able to get a general picture.

Typical days

What is a typical day for a developer at the company like? Is it waking up at 3am because the application is throwing 500 errors (again!)? Is it working long hours because the company already thinks that the dev team is going too slow? Is it come in (or log in), get work done, hang out with coworkers, and go home at a reasonable hour?


It goes without saying that you should be happy with the benefits and compensation from the company. But don’t overlook perks!

Does the company send employees (and not just developers) to conferences?

For companies with a lot of remote workers: does it regularly get them all together? Does it get them together in awesome vacation spots?

Does the company provide you with a computer or do you need to bring your own? If the company provides the machine does it belong to you or the company?


Ask questions!

Up next Rails isn’t for beginners There’s been some talk online about how Rails is losing its focus on beginners or that it’s getting too complex for its own good. I have a different Gem Spotlight: interactive_editor Today we’ll take a quick look at one of my favorite gems: interactive_editor. Have you ever been in a REPL session (rails console, irb, pry, etc.)
Latest posts Where did the recent Elixir posts go? A subtle Go bug that types cannot help with swapcase with the tr command nice go test output See where vim settings came from Containers in the real world and backpressure in distributed systems Elixir Phoenix and “role postgres does not exist” From awk to a Dockerized Ruby Script Finding leap years with the cal command The Problem of State Clojure Functions in Four Ways See Some Clojure A simple language spec isn’t a feature when you’re building applications The Fastest Possible Tests Shrink your data into bitfields (and out again) Every “if” statement is an object waiting to be extracted Choose Generic Tools Hyperlinks you might find interesting — #4 Running bundle install on rails master Use tldr for command line examples Friday Lunch Links — #3 Friday Lunch Links — #2 Logical Solver: Turn facts into conclusions Programming with jq Command line tools - jq Friday Lunch Links — #1 Why diversity matters Music for coding - October 2019 Code puzzles are a poor way to gauge technical candidates Add vim to a pipeline with vipe Connecting Objects with Observable