On hiring and take-home project: When I was hiring I hired about 2 out of 10 candidates. Of the remaining 8 I would have skipped on 4 if I had used a take-home project. So for me its main value is to save me time by filtering out people that have no chance of success in an interview. The challenge these days would be to create a take-home project that won't get copy/paste solutions from StackOverflow. As for the actual tech interview I don't do more than 2 interviewers and we have a set selection of problems we pick from in order to achieve some normalization between our interviewing teams. Tech interview is usually an hour, no need to do 4 - 6 hour interviews. Content also adapts to the candidate's training and experience. A fresh grad might be able to nail stuff he just studied in college and still suck at solving the simplest problem. An experienced programmer with different education may not have been using theoretical CS for the last 10 years but easily master it with minimal exposure.
I'm talking about not being able to code an easy project, no catches.
I've had someone who reportedly had a masters and in the top 10 of his class who thought all code run only in ide's and didn't know what the jvm is.
Granted he was a massive outlier.
But you didn't really need a take home project to filter out this person : )
yeah, he could have passed that somehow, so maybe it's like a placebo π
"no chance of success", I wish I was this clairvoyant when I look at blinded data about applicants βΊοΈ
Do any or many companies with a clojure stack ask candidates to solve data structure and algorithm questions in clojure like most big companies do? Or do they lean towards more conceptual / system design questions and take home assignments ?
Just my personal experience but most of the questions I've gotten during interviews are simple data transformations, like, which of these numbers are the the sum of their digits or something. As far as take home assignments I've been tasked with building an entire web based game of cards and a variety of logic puzzles. https://github.com/doby162/reagent-memory and https://github.com/doby162/simple-gps are both ones I've done for clojure companies that got me into further interviews. I will say that the standards on take home tests are usually the lowest bar in the process, don't invest too much time in them because as long as your solution works, they'll pass you, and writing a good solution in no way lowers your odds of being dismissed for insufficient years working with scrum or for not having enough experience dealing with irate customers.
I also got a during-interview assignment to build an entire user interface with nuxt.js (a library I had never heard of) Lol, after 10 of my 30 minutes were spent on setting up an environment and figuring out what nuxt.js was, I should have just quit, but there you go. So far I've been just as likely to be tested in javascript as in clojure for clojure jobs
@bardiapourvakil I was wondering about this yesterday because I saw a mock interview at a big tech company and they asked to implement a "length encoder" and I went to the repl and tried a version, however during the exercise they were discussing why one should use a list to store the values, or hash-maps and whatnot.. however my solution was the following when compared to Java.
and I thought maybe the discussion would go more towards the collection api, lazy evaluation, maybe ask to change this to use transducers.
I assume you don't get dinged for unbalanced ()'s on the whiteboard REPL π
We skipped the code test on both our hires, no regrets.
(I appreciate it's a sample size of 2)
@iagwanderson did they expect a decode too? Btw. isn't the java version adding the length and value out of order?