A guide to hiring a Haml developer
Haml is a template language. Instead of writing opening and closing HTML tags, you write the structure of a page with short lines and indentation, and Haml turns it into normal HTML. It is used most often in Ruby on Rails apps, where it sits in the view layer. The sections below explain the work, the signs of a strong candidate and the habits that make remote work go well. They are written for founders and team leads who own a Rails app with Haml views, or who are weighing it for a new project.
What Haml looks like in practice
A Haml file reads like an outline. A line starts a tag, an indented line sits inside it, and a short mark adds a class or an id. Ruby code can run on a line that starts with a dash or an equals sign. Because there are no closing tags, files are shorter and mistakes with unclosed elements are rare. The cost is that indentation has meaning, so a stray space can change the page.
The jobs people hire for
One common job is building views for new features: pages, forms and layouts that match the design. Another is cleaning up. Over time templates grow long, repeat themselves and hold logic that belongs elsewhere. A third is conversion. A team may decide to move from ERB to Haml or the other way, and needs someone to do it safely. Email templates are a fourth common task, since they follow their own rules.
Where a Haml developer fits among other roles
A Ruby on Rails developer builds the whole app, from data to controllers, and views are one part of that work. An HTML developer focuses on clean pages and may not know Rails. A Haml developer sits between the two: someone who knows how Rails sends data to a page and who writes the markup with care. Larger teams often pair this person with a back-end developer and a designer.
When a Haml developer makes sense
- Your Rails views have grown long and nobody wants to open them.
- Designs take too long to turn into working pages.
- Pages carry a lot of logic that should live in helpers or models.
- You want to convert templates between ERB and Haml.
- Your app sends emails that look broken in some mail programs.
If your problem is mostly in the data or the back end, start with a Rails developer instead. A developer who sends you to the right role is worth trusting.
Judge the output, not only the source
A Haml file can look tidy and still produce poor HTML. Ask the candidate to show the page in the browser and open the markup it creates. Look for proper headings, labelled form fields and sensible structure. Ask how they check accessibility and how pages behave on a phone. The final HTML is what visitors and search engines see.
Reading a Haml developer’s background
Request examples of views they cleaned up or built from a design. Good answers explain what the problem was and what changed, for instance how a long page was split into partials. Treat with care a background that lists only languages. Haml is a small tool, so the value lies in the habits around it, such as naming, reuse and keeping rules out of templates.
Questions to ask in interviews
- When does a block belong in a partial, and when should it stay in the page?
- How do you keep conditions out of a view without hiding them somewhere worse?
- How would you convert a large set of ERB files to Haml with little risk?
- How do you check that a form is accessible and its errors are clear?
- What do you agree with a designer before you build a new layout?
Listen for plain, practical answers. Doubt anyone who talks only about syntax and never about readers.
Try a paid mini project
Give each finalist one small piece of real work from your own project. Useful examples are a long view split into clean partials, a form built from a design, or a short email template. Pay for the time spent. Then compare how readable the files are, how the person handles the odd cases and how well they explain their choices.
Agree the house style
Because indentation matters, small differences between developers show up quickly. Agree on a few simple rules early: two spaces for indentation, how to name partials and where helpers live. Write them in a short page in your repository. A linter can check the rules for you, so reviews can focus on the real work.
Working with your team
Walk your developer through the designs, the style guide and any pages that cause complaints. A brief weekly meeting and one shared list of tasks keep the whole team on the same page. Share the pages that were hard to change in the past, since they usually show where the biggest gains are.
Common mistakes
- Mixing ERB and Haml with no rule about which to use.
- Putting database queries or business rules inside a view.
- Converting every file at once with no tests.
- Ignoring the HTML that comes out of the template.
Looking at a wider role? Take a look at our Ruby on Rails developers for the full app, or our CSS developers for styling.