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.
Hiring someone who wants detailed requirements is not a good idea when you don't have a structure in place that can provide these detailed requirements.
If you rely on people to work independently, you just can't hire someone who wants feedback everyday to see if they are still on the right track.
Depending on the level of detail, "detailed requirements" can be the bare minimum for any level of cohesive, cross-functional collaboration.
You need to have discussions to talk about things like:
* common UX language
* common API expectations
* programming language choice
(because you will not be the only person to work on it)
* in-app / domain language choice
(because your users need to know what a word means.)
* library choice (because you will not be the only person to work on it)
* storage strategy (because there may be legal requirements here)
Ignoring all that and letting all the engineers just run wild is a great way to make a very painful company to work with and cross-collaborate on.
My impression is that Kagi aims to hire people who are already aligned on most of these. Not all of them, of course, but I read the interview as an attempt to be able to go "do this" and have candidates understand what it means.
I don't disagree, but again: Kagi is Vlad's pet project; he's already rich. I think he would rather it fail than it become something that he doesn't feel aligned with.
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 had an interview once to work for IPFS, with a guy who already knew my skill level well (decades of experience), because I was active on their web forum solving everyone's problems, for about a year. Even during the interview he mentioned the technical part of the interview wasn't even necessary, because he had total confidence in me, and didn't even ask technical questions at all. He spent the ENTIRE hour selling me on the job. I hardly had time to speak. Everything went perfectly fine. Then he asked me to do the take-home project at the very end, just because "everybody has to", and I politely told him sorry I don't do those. So that ended the opportunity. So you're exactly right it's absolutely an "inertia" thing.
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.
The platform was written in Clojure from ground up since the team was small and rest of the company was using Clojure mostly in combination of Java.
Now most of the company moved out of Clojure for various reasons but they didn't try to write performant code and instead just chose to rewrite which I want to avoid. Try as much as possible before deciding to rewrite since rewrite is expensive given the codebase has lot of things.
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.
"Devops," or system and infrastructure administration, should have the primary goal of creating reproducible steps to create, maintain, and diagnose servers and other assets. Part of reaching that goal is creating scripts, tools, and documentation that other system admins can quickly figure out and use. Imagine if the "DevOps" person gets run over by a truck.
You don't choose a language you fell in love with or want to learn and wedge it into the problem because you want to. Even if you can use Clojure that doesn't make it a good idea. It has too many dependencies, isn't available out of the box on typical servers, and imposes a severe limit on the people who could take over system/infra admin.
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.
