Not the original commenter, but I’ve heard, and somewhat observed, that Dutch people are generally more fluent in English than other Europeans; and I’ve heard this attributed to Dutch television, where English shows are generally presented in English but with Dutch subtitles, unlike other European nations where such shows would be dubbed into the local language.
Also a bit glossing over the details if we consider how close Dutch and English are compared with say Slavic languages and English or Latin languages and English.
I remember reading a while back that Old English and Old Frisian would have been mutually understandable. Although in fairness I doubt most Dutch today would follow a conversation in Frisian.
In this case boasting about the virtuous deed is adding a great deal of extra value to the world, because it is likely to inspire other companies to step up and do the same.
Whenever I've interviewed people I've always made sure to them feel comfortable, so any anxiety does not get in their way.
Then, we talk and I look for all the qualities they /do/ have.
Sadly, lots of interviewers get a kick out of finding out what the interviewee does not know, so they can feel superior.
Coding challenges should be:
-1. take-home
-2. concise
-3. relevant to the job
-4. take no more than 4 hours
One example of such a decent test that I came across involved having to read a file, parsing it and turning its contents into some basic HTML. During the interview we talked about things like "what if the file were really big", e.g. let the candidate reflect on the limitations of their implementation.
This was enough to suss out where somebody is, professionally.
And nobody had to have a bad day.
So what? It's a logic test. And you're still proving that you have enough experience to code well in general language e.g. java, python, javascript, ruby, etc.
It would be way more time intensive for the interviewee to be asked to code up some fullstack project for every interview.
Having to memorize some basic algorithm questions that are maybe 20 lines of code each is way better.
> It would be way more time intensive for the interviewee to be asked to code up some fullstack project for every interview.
Assuming the role is a fullstack developer, memorizing basic algorithms doesn’t show one is fit for the purpose.
Providing a simple skeleton of a fullstack project—in the chosen tech stack of either the candidate or the company—and then verifying a candidate can add a simple feature, or something similarly fullstack, would accomplish that far faster than algorithm answers.
Edit: I realize this risks sounding like stupid take-home interview homework. I personally oppose that crap. However, I recognize why some companies take that route, as I don’t think I’d feel confident that a candidate could work in my company’s stack by asking silly algorithm questions. I’d probably feel more confident watching the candidate do a remote screen share, git clone a starter app, and do some simple to moderately complex fullstack tasks. Of course, the tasks should fit the role, I think—e.g., I wouldn’t ask a candidate who’s being hired to tune DB queries a bunch of fullstack questions. And if I was hiring a backend dev to build out APIs, I wouldn’t bother with a bunch of frontend tasks and questions. The hiring processes I’ve seen and managed always had better results when more time was invested in prepping specific, job-focused interview processes, rather than offloading that time onto candidates because recruiting teams can’t actually do more than ask shallow questions or follow checklists.
Haha yes, at that point, nailing the interview will just come down to how well you are able to gauge what the person at the other side of the table wants to hear. "Hmm, is this a tabs or a spaces guy?"
I'm not a developer, I can do some light code and make changes to existing code, but I am just not a developer. It isn't my particular skillset.
However, I am in consulting, and was on the bench. My manager forced me to do an interview for coding. The questions were absurd. Literally reading vocabulary terms and looking for exact definitions to things.
I continually asked what their problem was, what they were trying to solve, what steps they faced, etc. They just kept asking questions like above. And every time I'd get it "wrong" they'd say "we were looking for... <googled definition here>.
Honestly what is the point? I feel really bad for kids today. I get all my jobs through word of mouth and networking now. Why? Because it's much easier and those ways almost always have better outcomes.
Clojure just seems "too weird" to too many people, albeit for all the wrong reasons. Its syntax looks like a 6ft hurdle to newcomers, especially if they have lots of experience in C-synthax-languages.
But anyone who just /tries/ to jump it finds out the hurdle really isn't that high at all.
This dynamic will probably never change. Clojure will remain an acquired taste, which is fine, I guess. Those 'in the know' will happily continue to develop effectively with it.
