A guide to hiring a Lisp developer
Lisp is a family of programming languages known for macros, a live way of working and a very flexible design. Common Lisp is the one most business systems use, Clojure brings the ideas to the Java platform, and Scheme and Racket are common in teaching and research. A Lisp developer writes and maintains code in one of these. This guide covers the work itself, how to size up a candidate and how to run the job with someone far away. It is written for founders and team leads whose product depends on Lisp code and who struggle to hire for it.
What makes Lisp different
In Lisp, the code itself is built from lists, the same kind of data the program works with. That lets a developer write macros, which are small programs that write code. Used well, macros remove repeated work and let a team describe a problem in its own words. Lisp programs are also often built in a live session, where the developer tests pieces and changes the running system without stopping it. These habits feel strange at first and are very strong in experienced hands.
The jobs people hire for
The first job is care for an existing system. A company has a working product in Common Lisp and the original authors are gone. The second job is new work, in Common Lisp or in Clojure, for services, data tools or planning software. The third job is symbolic and rule-based programs, such as parsers, planners and engines that apply rules. The fourth job is tools, including Emacs Lisp, which extends the Emacs editor.
How a Lisp developer differs from other roles
A software engineer builds products in the languages your team already uses. An Erlang developer works in another language with a functional style, built for systems that must keep running. A Lisp developer is the person you call when the language itself is the hard part, either because a system depends on it or because its features suit your problem. On bigger projects they often work next to a general engineer.
When a Lisp developer makes sense
- Your product runs on Lisp code and the people who wrote it have left.
- You need new features in a Common Lisp system, with tests around them.
- You are building a rule engine, a parser or another program that handles symbols.
- You use Clojure for data or web services and need more hands.
- Your team relies on Emacs Lisp tools that nobody maintains.
If you are starting a plain web product with no Lisp in sight, a general engineer is a simpler choice. Pick Lisp when there is a reason to.
Decide whether to keep or rewrite
Many owners ask whether to move away from Lisp. A rewrite widens the hiring pool but can lose rules that only the old code knows. A better first step is often to add tests, document how the system runs and make it build on a new machine. After that you can judge the choice with facts. A good developer will tell you this, even when it means less work for them.
Reading a Lisp developer’s background
Ask which Lisp the person has used at work, not only in study, and what the systems did. Strong answers describe a real problem, how the code was laid out and what went wrong on the way. Treat a list of small exercises with caution. Lisp is easy to enjoy in a small program, while a large system calls for discipline about structure, testing and naming.
Interview questions to try
- When would you write a macro, and when would you avoid one?
- How do you get to know a large code base you have never seen?
- How do you change a running system without causing harm?
- How do you add tests to old code that has none?
- How would you explain a hard part of the code to a new team member?
Good answers come with reasons and real cases. Be wary of anyone who treats cleverness as the goal and readability as optional.
Try a paid mini project
Set each finalist one small job from your own code, such as tracing one feature and writing it up, adding tests around a function, or fixing a known bug. Pay them for it. Then compare how easy the changes are to read, how they deal with surprises and how clearly they talk through their choices.
Agree how the knowledge is kept
The biggest risk with Lisp code is that one person holds all the knowledge. Settle early on notes that say how the system starts, where its data lives and how it is released. Keep the code and the build on company accounts and take access back when the work ends. A second reader of the code lowers your risk a great deal.
Working with your team
Tell your developer how the system is used, who depends on it and which parts worry the team. A quick weekly call and one shared task list keep everyone pulling the same way. Point out past bugs and odd behavior, since they often decide how much time the first weeks take.
Mistakes to avoid
- Letting one person be the only one who understands the system.
- Changing old code before any tests exist around it.
- Using macros where a plain function would do.
- Choosing a rewrite before you know what the old code really does.
Need something different? Our software engineers cover general product work, and our Erlang developers cover systems that must keep running.