Clojurians Log v2

I like the "Why don't you like X?" or "Why is X bad?" questions because it gives me a chance to be passionate. I can discuss the places where I've "used X in anger", where I've had moments of frustration or annoyance that stuck with me, and the ways I wish it was better. Being able to say, "I love Clojure, but the error messages/multimethods/whatever are bad in this specific-to-me way" shows the interviewer that you both know the tool and you care deeply about it. Complaints from the outside look very different than complaints from the inside.

point_up::skin-tone-2 That's exactly the sort of thing I'm looking for with my pair of interview Qs: "What's your favorite language/tech stack?" and "What are some of the things you don't like about it?"

https://download.clojure.org/stateofclojure/2023/Data_Q7_230630.pdf

That sounds like a poor question to be asked, or at best poorly phrased. No programming language is bad. I would want some context before asking that as it's way too broad to be meaningful I'd probably end the interview if someone asked me that without providing context, as it would be a communication and cultural red flag regarding working with that person. Languages have strengths and constraints, as with any technology. There are constraints with Clojure and running on the Java virtual machine (although native compilation with Graal can resolve some JVM constraints and introduce other constraints) I could probably spend several hours discussing the constraints and if they are actually important to a piece of work to be delivered. Arguably the biggest constraint of any language is the person(s) writing the code and how well they are informed about what the code should do.

@jr0cket good point. What about constraints? Is there good explanation what I should be worry about, when I’m writing in Clojure? I also once get question “Is Clojure slow?”

So far I’ve found: • Interpreting error messages • Libraries not so often well documented. • Finding example programs to study or answer doubts • Know if the way I’m doing x thing is the best way to do it • runtime performance (???) • Knowing the shape of data when the code is new or have not seen it in a long time. • dynamic typing (I can’t fined good explanation for that)

@p-himik Interesting, but too much complaints, to little sens.

On job interviews I often get a question “Why Clojure is bad?” or “What are problems of Clojure?”If you apply to a JavaScript position then they probably ask this question because they wonder why you don't work with Clojure and apply to their position. i.e. you could paraphrase the question as "why do you think our language works better for you at current time than Clojure?". So this question may actually not be about the technology at all. I think the negative formulation of the question implies that it's not about understanding whether Clojure could or couldn't work but mainly about dismissing it. It could've been asked "Do you think Clojure is good/bad?" and "What are pros/cons of Clojure?". This way there is room for discussion whereas "why is bad" means "find something bad and only bad and don't consider our own technology choices because next question will be about why are they good... and you better find a good answer about them being good or else". I attended an interview that almost went like this. And then I also said that C# and Java is basically the same language. The "most senior guy" freaked out really badly 😄

I think it's a good interview question, I'd say it aims to show (at least) one of: • you can critically use a given technology choice, being aware of specific tradeoffs • you are an experienced Clojure developer and as such have seen which aspects may need attention in a team context

@vemv so, how would you answer?

In the end it's a question for each of us to answer ^^ often there isn't a right one.

Would you say this on your interview?

No 😄 but I don't want to make my answer a canned one, by sharing it. Often the specifics of the questions/answers don't matter as much - they're simply a medium to get a conversation started and learn more about you. A nice combination of enthusiasm, curiosity and humility can get one pretty far. Of course a strong existing Clojure background may help, although it's just as important to show how you uniquely think/work.

@jurko.bossetroll all the things you have found seem very subjective and depending on the aims of the company may be completely irrelevant. As mentioned in my first post, any possible constraints in a language depend on what is to be achieved. The speed of code execution is almost always irrelevant,at least until a project is significantly successful. I worry about the very limited experience of the people asking you these questions. I wouldn't work for any of them if they are this inexperienced

> Of course a strong existing Clojure background may help, although it's just as important to show how you uniquely think/work.’ This is why I’ve started this thread. I would to know an answer, not for hate speeches, but to be aware.

@jr0cket not many offers to choose, especially for juns.

I understand this question is tricky, and it’s always answer “it depends”, but seems, this answer not good enough :)

You can just be utterly honest and let them know what your own thoughts are. If you haven't been affected by any of the issues that Clojure has, just say so. Maybe add "If there are any issues, I hope I get enough experience in your company to stumble upon them". :)

@jurko.bossetroll When I'm interviewing someone, I usually ask "what is/are your favorite language(s)/stack and why" -- and when they've answered that, I usually ask "what are some things you don't like about that language/stack?" It's meant to be an open-ended question and it's meant to be subjective. I want to know what you don't like about it -- I don't want you to just parrot back some list you read online. As Eugene says, if you haven't personally run into problems with that tech, just say so (but that will tell me you don't really know that tech well -- which is why I ask it). If you sound like you are just parroting back a list you read online, I'm going to dig deeper and ask for personal, specific experience of each problem you list. So, TL;DR: always be honest in an interview.

(some of this sort of questioning is also to examine a candidate's communication skills in whatever human language is the primary for the company)

@seancorfield good point! Thank you.

It's "bad" because you get spoiled, making all other languages seem awkward. And the hard truth that came to bite me a little is that you can never get completely away from the non-Clojure part of the software world. And the more I grew as a developer, the more things I needed to know which required such outside knowledge. Had I learned Java or JavaScript first like others did, this would be less of an issue because I'd be familiar with those other languages already. But since I went the other way, it resulted in a much more circuitous path than I was expecting. There, that's my answer...

Nice one. I’m starting to learn Java, just to know how could it be better than Clojure (can’t believe it’s possible). And some job for juns.

"When would you use C++ instead of Clojure?" "When would you use X instead of CLojure?" I think we can rephrase the question to understand when one toolkit or style of approach could be beneficial. When would you use APL instead of Clojure? 😼

> "When would you use X instead of CLojure?" This is a really good question when a company uses multiple technologies for different things and wants to see if candidates understand why a team might pick X over Clojure or vice versa!