Haven't had an exclusively lisp job, so maybe I shouldn't comment, but... I did use CL and Clojure on the job for a few smaller things at my last two places. It

Haven't had an exclusively lisp job, so maybe I shouldn't comment, but... I did use CL and Clojure on the job for a few smaller things at my last two places. It's easier to find Clojure companies (and them to find you) than Common Lisp ones. You might want to peruse https://github.com/azzamsa/awesome-lisp-companies https://github.com/azzamsa/awesome-lisp-companies from time to time and see if any have openings. There's other resources linked too and of course there's the reddit and discord community (such as there is) hubs. You can also see if there are any meetups in your area, that's how I almost ended up at a Clojure startup some years back. I should have taken strategy notes after talking to a guy at my last job who got management buy-in to rewrite a lot of Java code (for android) to Kotlin and have all new code for android be in Kotlin (before that was considered the sensible default). I think that's in general a better approach for a lot of would-be paid lispers: don't wait for or look for the lisp job, make the lisp job. Whether that's doing work where the customer doesn't care what language the thing is made in, or introducing it (some have even snuck it in -- the original clojure.jar got a lot of early success that way) to an existing work place. What I somewhat remember from my conversation was that if you can make a good technical case and have at least one other person supporting you (ideally your entire dev team as was his case), it's a lot easier to sell. No one raised bogus concerns about increasing the hiring difficulty or effort learning the new system. (I say bogus because engineers are learning all the time, and huge swathes of the industry have already had to do things like migrate from ObjC to Swift, or the various versions of JavaScript and later TypeScript + all the framework churn, switching IDEs; learning and change are quite common and a non-issue.) From other Lisp company reports, getting a new hire up to speed to be productive with the team using Common Lisp is a matter of a week or two, a small portion of the overall onboarding time a lot of new jobs have. Mastery takes longer, of course, but that's different. If I had stayed longer at my last job I would have continued to flesh out a better demo for interactive selenium webdriver tests for our main Java application after injecting ABCL into it, it seemed like the easiest vector to get more interest from my team and other teams. It kind of sucks when you're debugging a broken test and finally hit an exception but now you have to start over again (especially if you stepped too far in the debugger), especially with heavy webdriver tests that can take a long time. The Lisp debugging experience is so much better... And when writing the test from scratch, it's very interactive, you type code and execute it and verify the browser did what you intended. When you're done you run it again from scratch to verify.