Think of Civitas as a "static site generator" that uses the GH pages for the project as the public hosting for all the content -- a centralized, Clojure-specific blog if you like.
If you post a JS position, you will get 1,000 or more applicants, so it is a huge amount of work behind the scenes to filter this down to try to find the vaguely worthwhile candidates to interview.
If you post, for example, a Clojure position, you will get 10s or maybe even a 100 candidates tops. And they tend to be uniformly more qualified because niche tech tends to self-select folks who want to explore outside the mainstream.
Of course, a lot of businesses want to use mainstream tech because "the hiring pool is much larger", but the flip side is "the hiring process is a lot more work", because of the volume. So, we get a crappy hiring process because they can't scale up a good hiring process :(
A lot of companies seem to want to hire folks who "think like me". IMO, that's a mistake: you need diversity of thought to provide new insights into problems. If you all think the same way, and one of you gets stuck, then it's likely you'll all get stuck. This seems to be a common problem in startups, IME, and perhaps an indicator of why 9 out of 10 startups fail.
I'm surprised this seemed to be voted down. I've been a hiring manager for over 30 years, and I never do "technical tests" -- no take-home, no live coding, none of it.
I have a map of topics and questions, and I get the candidate chatting about their past projects, their approach, and what they liked/disliked about past projects and various technology they've used.
It takes a maximum of one hour and usually close to about thirty minutes to make a yes/no decision on a candidate (sometimes it only takes ten minutes to make a no decision, and then it's a matter of trying to politely end the interview).
I've interviewed hundreds of candidates this way over the years, and everyone I've hired has been capable of doing the job. Not once have I ever had to let someone go for lack of technical ability.
Part of the problem is that we don't train people how to conduct interviews, and another part is "this is how I was interviewed, so this is how I'm going to interview other candidates" -- pure inertia.
As an industry, we really need to do better.
As for the OP, _if_ I had been administering a vague take-home project that had a 1-week delivery deadline, and a candidate peppered me with Qs and then presented a full proposal for the project for approval, prior to working on it... I would have rejected them. But I'm pretty certain I would have decided to reject them in my regular 30-60 "chat" interview, and I would not have moved on to the take-home project and wasted their time like that. So, again, I fault the interviewer(s) for not being able to filter candidates efficiently.
I guess it depends what the tech stack was before?
Where I work, we were previously a ColdFusion shop when I joined, and after a false start with Scala, I introduced Clojure and it stuck: we cross-trained the CF devs and slowly rewrote the platform from the bottom up in Clojure.
We had struggled with automated deployments, and the size of servers, when we were a CF shop but after the switch to Clojure we had a fully-automated deployment pipeline, with rolling cluster updates, and much smaller servers than we needed before, running more processes than before.
There have been several comments from the core team folks that a vthread variant of core.async is being considered. It would be a different library and may be somewhat API-compatible -- but that's all up in the air right now.
Babashka is a self-contained executable that can run with no dependencies.
I was not commenting on the appropriateness of introducing a scripting language for devops work. I was responding to your incorrect assumption that writing scripts in Clojure would require a JVM.
If a company uses Clojure or ClojureScript already, Babashka is a fairly natural way to support devops for that company.
I sympathize to a degree. I've worked in startups, and I've worked in Large Corps, but size alone isn't necessarily correlated with "fun" and startups aren't always good environments, nor do fun startups always turn into a corporate enterprise. I _generally_ prefer the smaller companies but you can find fun and interesting work in larger companies too.
I loved working at Macromedia while it was between 1,000 and 2,000 employees (a lot of expansion by acquisition) but did not enjoy working at Adobe when they acquired us -- Adobe had a very corporate mindset, Macromedia almost felt like a whole bunch of startups. I had a blast working for Verizon (no idea how big they were back in the mid-90s but the IT department alone covered an entire floor of a warehouse-sized building), but then I went to work for a much smaller actuarial firm and, while the _project_ was fun, the corporate culture was not.
You have to figure out what is important to you ("fun", "interesting" are reasonable goals for work) and what sort of compensation you're willing to take in order to have fun. Are you willing to put up with more corporate BS for a ton of money? Would you rather have more fun and less rules but less money and far more risk (startups can be fun and interesting but also long hours and most of them fail -- I've been at three that imploded but I can't take that risk now I have a family and a home to keep up).
Is the tech stack important to you? Important enough that you'll really limit your choice of jobs? Important enough that you'd rather be out of work for months than work with tech you dislike?
I've been in IT for... over 40 years now. I've done everything from assembler and COBOL to Scala and Clojure, in companies as small as four people up to many thousands of people. Most of what contributed to my enjoyment at various jobs was the team interactions, closely followed by the problems being solved -- not the size of the company (nor the tech stack: the assembler job was at a large insurance company but the project was fascinating, and the team were awesome; and Macromedia was mostly C++ and Java and some ColdFusion -- but great people and interesting projects). For the last decade, I've mostly done Clojure and I love that and joke that I wouldn't work in another stack... but if push came to shove, I probably would if the team and the problem space seemed fun and interesting.
As the current maintainer of clojure-doc.org, I'd be happy to hear your feedback on what needs additional explanation/clarification.
This year's funding by Clojurists Together allowed me to spend a lot of time completely rewriting large sections of the site to bring it up-to-date with modern Clojure tooling and libraries -- but I know there's still room for improvement.
Seven years ago you would have been using Clojure 1.8 or earlier I expect?
A LOT has happened with the language and the tooling since then!
Clojure 1.9 gave us Spec "for describing, validating, and testing the structure of data and functions." and a whole bunch of new core functions (mostly new predicates).
Clojure 1.10 overhauled error reporting and gave us tap> (for debugging) and datafy/nav for lazy "navigation" through object graphs, which kicked off a series of new visual tools for exploring data structures: REBL (now Morse), Reveal, Portal, etc.
There's new Clojure CLI tooling now (tools.deps and the deps.edn file) and a library supporting programmatic builds (tools.build and the build.clj file). The 2023 State of Clojure survey shows the new CLI tooling surpassed Leiningen in popularity!
VS Code now has an amazingly capable Clojure extension called Calva, and you can script VS Code and Calva directly in ClojureScript via the Joyride extension.
The latter is made possible by sci -- Small Clojure Interpreter -- from @borkdude. He also created Babashka which provides a near-zero startup time solution for writing shell scripts in Clojure/Script, and clj-kondo which is a powerful, high-performance linter, which in turn powers clojure-lsp bringing static analysis for Clojure to several editors.
Datomic has grown up a lot in the last seven years and is now completely free to use (but not open source). We also have an open source bitemporal database in XTDB from the JUXT folks.
Clojure 1.12 is currently in alpha, and provides built-in support for adding new dependencies to your running REPL (without restarts).
Clojure is the most stable and robust language I've ever used, and I've been using it in production for 15 years now.