Clojurians Log v2

@risinglight what I did twice now (hiring Clojure devs) is three rounds: one “get to know” round where we talk about goals, the role, teams, etc. Just a friendly conversation, no traps and no deeply technical topics.

@seancorfield I would appreciate hearing your thoughts on why take home projects are a bad idea. Also, your mind map is great and I’m totally stealing it 🙂

A second round is a take-home project - very simple, just some data manipulation, no traps. Then a follow up discussion that starts from there and wanders over various technical subjects.

The third round is meeting the rest of the team (on-site or virtually), letting other team members ask their own questions and then convening together to discuss.

I think in total that amounts to 3-4 hours of interviews, talking and 1-3 hours for the take home exercise.

@orestis That sounds pretty close to what I was thinking - a very quick phone screen about the position, a take home project, and then some in-depth discussion about it along with other discussion questions.

Based on @seancorfield dislike of assignments I explicitly said that if you’re busy and can’t do it, let’s have a technical discussion anyway - but it makes my job much harder as I lose the only yardstick I have.

I'm just heading to bed so I'll be quick.

The take home project has no time limit or other constraint. When it’s done, book the next appointment and we’ll talk. There’s also clear instructions about it being non-production code, no tests needed etc.

Essentially a more advanced fizz buzz. It’s not trying to be clever, just a bunch of data and some instructions about the desired calculations. No UI, all easily solvable by staying in Clojure.core.

Taking the spirit of an easy advent of code puzzle.

Take home assignments make several assumptions about candidates' home lives: that they have time for technical work outside "work hours" and that they have a work-capable computer at home.

There's also the issue that such projects are rarely indicative of either the candidate's actual ability nor are they representative of actual work.

So many tech folks insist on a "technical quiz" of some sort because they don't know how to interview people "properly" in my opinion. They don't know how to assess someone else's skills by just talking to them.

I agree with the point about it making assumptions, and that’s something I hadn’t really considered.

I've never done technical quizzes of any sort in 25 years of hiring -- and I've never had to fire anyone for not being technically competent.

Besides, you can always train good people on technical minutiae. You can't train bad people tho', regardless of their ability to jump through some artifical "tech hoops".

I'm in bed, on my phone. Happy to have an extensive discussion about this when I'm at a computer... During the week. G'nite.

I appreciate it, g’night!

I second @seancorfield on that, it is not representative of actual work. Here are some reasons why. Even if you tell the candidate to do the take-home work “as if” it was actual work, it won’t be the same: • The candidate will never propose to change the assignment into something that makes more sense, • will never choose a better solution which involves 2 more weeks of work, will try not to say “I don’t know / I am not sure / I doubt” when it’s actually the best thing to do to reach a better solution while discussing with coworkers, • will never say that problem might be better solved by tool X, “give me 3 days to give it a try and see if it fits”, • will not do team work, will not care about how his solution is used by an imaginary customer, • will never tell you if your business idea is wrong and why.

I had an interview a couple of months ago where, while I was been shown a secret product’s internal, I was struck by how much it could be made simpler, but I had no room to say it - my goal was to be hired.

I only have 1 year of hiring experience and that only within Clojure. My request was that candidates optimize for readability of the code, production concerns (even error handling), performance etc is explicitly out of scope.

All the things I listed are something you should be happy to have in a co-worker, and you won’t get it via a take-home project.

I’ve seen a range of responses, and I’m interested in the outliers: code that is unnecessarily convoluted or code that is very elegant.

But much more than the code itself I’m interested in the discussion after - I have one with everyone.

Then people can walk through the solution, we can talk about what-if scenarios etc

as a counter point, on the last take home project I did back in 2014, I spent a lot of time in the README going over the design trade offs of my implementation, and how it could be done better if I had more time (or cared to), and how it would be a better fit for a production workload

@orestis have you every decided not to hire someone after seing their take-home project? If yes, how do you do it? Unidirectionally by email, or via a bidirectional live discussion?

I think @orestis idea of using the take home project as a springboard for followup conversation could also address a lot of the points above w.r.t different implementations, underlying assumptions, if it’s even a good idea, etc

I have participated in hiring processes at multiple companies for over a decade now, the most when I was part of a small team doing technical interviews (in contrast with the getting to know interviews that the HR did, or final interviews that the upper management did to decide salary and similar. I agree that ideally there is much less interviewing, but the situation was so the company I worked for employed about 2200 people, around 1300 developers in 3 quite large buildings right next to each other and it was famous that almost anyone can get a job. And some hiring practices were clearly bad, there are people who can talk technical talk that fools HR and even some management who hasn't had experience with coding and we had people whose biggest contribution was that "coffee too strong" "water too cold".

So I did about 2-4 interviews every week, and understand these required preparation to read the interviewees cv and look into the techs they've been using and I haven't, etc. After the interview even more time was spent having to write it up which I think was mostly #bullshitjobs but it was good to be able to remember people, because after 6 months they could try again.

Last take home project I did I completed successfully and was brutally honest that my effort was capped because it wasn't paid. There was a lot of back and forth until I made it clear that my real work would have been of higher standard but I wasn't willing to give a lot of time into an unpaid "maybe" thing.

The point I am trying to make is that even though there were fake people and people who weren't fake but were on a completely different planet, most people just desperately wanted to get something better, and I genuinely wanted to recommend them, but obviously if someone needed much more training, it was out of the question. So these technical interviews were basically 1-2 hour sessions where I tried to ask questions in a way that shows any kind of work skill. We tried a 15 minute coding exercise, but with tests already built in, so very easy, I've seen people do it in less than 5 minutes, while being hungover and talking about something else. So easy. Then whiteboard, or just talk, or maybe typing. Whatever came most natural to the person I was interviewing. I do not claim I know how to interview, but I know that almost anyone could be hireable if they had the right circumstances that help them prepare.

Honestly, I think in today's world when there is this fake education that literally makes you dumb if you are not careful and believe it too much, companies who want long term relationship with their employees, should be fine with training them up

@vincent.cantin no, there’s always a discussion. I mean, small sample size and all that, but that’s the principle.

@orestis but both writing code and analyzing code can be work. And as yardstick, code is very bad.

so you should pay whoever you do not hire

One of the main questions I ask is: had this been production code, what would you do differently?

"everything", now you wasted our time too 🙂

Well in reality we would talk about about concrete things in a specific context. FWIW all candidates so far gave good feedback on the process, so I’m keen to stick to the main elements.

The main thing I learned is that I need to take copious notes in a digital format, because even after 3 candidates things blur and you end up with only gut feelings. Also, observing the candidate when someone else is driving the conversation is eye-opening. At least it helped me overcome first impressions (in both directions)

https://aphyr.com/posts/341-hexing-the-technical-interview

I would love to be able to pay people for their trouble. In practice, it’s near impossible, and opens a can of worms (what about time spent interviewing? That’s just as exhausting and “work”). To compensate I try to be respectful, have a meaningful connection and conversation that people would also gladly have over a drink.

yeah, obviously no 1 on 1 interviews, it's dangerous

@orestis I believe the can of worms is opened with you asking people to work for you, not paying them is just leaving it open : )

but I see your point about even more worms if you do, generally speaking everyone has that feeling about paying to people who they don't want to work with

The worst interview process experience I had so far was after completing the 2nd level of a take-home project (i.e. a take home project, then another one after the first one went pretty well). I received an email telling me that one small bug that was easy to fix and pretty obvious was found in the relatively big source code I wrote, and that there was a remark with how the program would behave if a user (he meant a real person) would use my program in the wrong way. I could have defended my case by saying that nowhere it was specified that the artificial, imaginary problem that I solved would be used by anyone, even less a human, but the lack of bidirectionality in the decision process discouraged me to say anything about it. In a real world scenario, things would have been different. Bugs are found and fixed, and you don’t judge people just on that, programming is an iterative process, that’s what we do with the REPL, and that’s what we do on products we develop. Also, in a real world scenario misunderstandings are fixed. You don’t test a 100 faces dice by rolling it once. That’s the same when getting to know people.

Sorry for the long message … I had to vent it out.

what do you mean by "fixed misunderstandings"?

The expectation of the interviewer was not fully written in the assignment, it created a discrepancy with what I delivered.

That’s a terrible experience ! I’ve (rarely, since it’s a small task) found bugs which where misinterpretations of the spec, and I didn’t even bring it up, exactly because of what you wrote. Even though I’ve made it explicit in the instructions that you are welcome to ask for clarifications, in practice in a hiring process nobody does, and in real life we would have a chat about the spec first.

Small misunderstandings happen at every meetings. Once you realize that one occurred, in real life you correct the communication and clarify things up.

I don't get the fixed part 🙂

Maybe I am using the wrong word. How about resolved? .. I mean the process of making a misunderstanding disappear.

oh, I see, I understood the word as in non-moving, so that confused me, thanks for clearing it up : )

@orestis To provide an extended point of view to @seancorfield statement, which I have written a few times in the past here already, but thanks to slack it's gone. My personal hiring experience here in germany, both as being hired and as being part of the interview team is totally different. The first jobs as a freelancer I got by just being introduced to people and talk about their problems and possible solutions, this was during university for me. After university I had two jobs (still hired at the second one). Both interviews were just an hour of talking with HR and a technical lead. Probably 20 minutes of that 60 were technical talk, not even going deep into things. At the second job I then later on have been part of the hiring process as a technical lead myself and we still do it like that. We look at the applications, decide which one to invite, which is usually everyone, because we don't get enough applications) and then have that 1 hour talk with each other, where the technical part is still around 20-30 minutes. But we totally prefer open talking, even if it is not about technical things. Here's the catch. I am pretty certain you can teach almost everyone to become a good enough programmer to be part of your team and contribute useful stuff. Even if the one you are hiring has not much experience. What you cannot teach people is to not be an asshole, to not take responsibility, to work in a team together, all the social stuff, that contributes much more to team performance is way more important. And having face to face discussions that are open and allows everyone to be himself, will enable you to figure out if that one fits into your team. I am part of our team right now for 9 1/2 years, of that 10 people working there (5 developers, 3 QA guys, one lead and one technical writer) 6 have been there longer than me, which means, we have a super low turn around time at that team. Also we had to let go only one guy during that decade and not because of his technical abilities, but because of his unableness to be part of a productive team (And we only let him go after a year of trying to work on this together, but, it just didn't work out). So, after two decades of being part of the software engineering business I don't see the need for technical interviews.

May I ask about the industry?

@sveri I mostly agree on all counts. There’s different circumstances though - going from 9 people to 10 or from 2 to 3... if you’re hiring for more senior people tech skills are also important. Not being an asshole is a necessity though, which is why I try to assess that before even going technical.

Hm, I did network administration stuff, web development, some desktop applications myself. The industries I worked in were totally different, but they all need software they run. For the last decade I have been working for Software AG, which makes b2b software, mostly process management, although we are now switching to do more and more integration and IOT stuff as a whole business.

thanks, that explains a bit of the story 🙂 it is very large and thus can shield internal people from outside, unlike small companies

this is not to disagree with you, I completely agree, I was just curious about the apparent leisure : )

Admittedly, this is something I think about often too, what if it was my business and I would like to add a second or third developer. In my first permanent position I was the second developer myself and it worked out too. When I was hired as a freelancer I was the only developer and that worked out too. That said, I just wanted to give my perspective, I know a lot of businesses will do technical interviews and while I don't like it myself it's obviously okay to have a different point of view on that.

While I agree with that in general, I just wrote it in #jobs-discuss that in all my previous work I was the only or second developer and the other ones were small businesses only.

Yes, I did discount that based on the fact that you were younger. The first job in particular sounds something that most people don't get or if they get, they have a significantly different experience. Maybe not in Germany, I am totally ignorant about the situation there, my aim is not to argue just to provide background to the story. What I would 100% argue with is that you can't teach people not to be assholes. I am coming from a nation which prouds itself as the biggest assholes around and with similar nations around, there is much competition, it's not just empty words : ). So I had to un-learn a lot of cultural things as I moved away from my home country, and I am not saying that I am not still an asshole, but I certainly can teach people how not to be ones, although, admittedly, as with programming, it requires hard work and dedication. ; )

@sveri, you say you don't get enough applications, but when I was hiring people, we had too many. Maybe you limited the applicants before the interview somehow?

@ashnur Not that I am aware of. We have a pretty standardized hiring process, starting with HR giving open positions out in the wild (not sure how and where exactly) and then my teamlead and one of the technical leads will look into every single application and discuss them afterwards. We did so for the three developer positions and we used the same process for two students we hired last year for the dual education system.

Is this a Clojure shop? We had tens of applications and 1/3 of them were high quality.

it's Germany, that's what I suspect : D

Ah, no, we do java on the backend and a few years ago started incorporating angular into our new frontends.

That said, the programming language used is not that important, that's at least my take on languages. Yes someone proficient in Java or clojure might have a head start of a few months compared to someone with minimal experience in that language, but if you plan for years it doesnt matter that much.

It’s just that Clojure still has a selection effect :)

Hi all - Just want to chime in again and ask; has anyone had any tips for someone who wants to study for a position at an American venture-backed Bay Area startup? Apologies for being this specific; but many of the companies I’m interested would fit this description. When I visit r/cscareerquestions, I get bombarded with interviewing at big tech company advice. Any tips from senior engineers or hiring managers on this as it relates to Clojure (and even if not) would be extremely appreciated. Thank you!

@risinglight I have really good experience with take-home projects for hiring junior-to-mid level devs, and I use the following 'trick' to make it less painful and 'unfair' for the interviewees: our home assignment is an interactive exploration, almost a game, for which you greatly benefit from the skills that we require for the job. For example, we are hiring C++/C# developers with reasonable network and multi-threaded programming experience. Our task description is like this: > To get the text of our assignment, connect via TCP/IP to the IP address http://xxx.xxx.xxx.xxx and a port number which is a year of unix timestamp 1337012345, and after connecting send "Greetings\n". Our hand-written home-assignment TCP server handles such a request and spits out the text of the actual assignment in an unusual encoding (in our case, it's Russian text in a very old KOI8-R encoding) — so you kinda can see the english words in the text, but the Russian letters are all messed up. So the candidate has to understand that and decode the resulting text. The assignment itself gives more in-depth instructions on what commands the job-assignment server supports (apart from "Greetings\n"), and what data you have to retrieve from it (really simple line-feed-separated text protocol) to calculate the resulting number. The caveat is that you have to send approximately 2000 requests to the server, and the server responds really slowly (byte-by-byte with a second of delay in-between) - so you have to send the requests in parallel to finish quickly, and sometimes drops connections randomly - so you have to have proper error handling and retry logic, so that you have all 2000 results in the end to do the final calculation (find a median of all returned numbers). Also our assignment states that once you finish, please send the zipped code of your program an the resulting number that you calculated to this email - and we guarantee that we will reply within 2 business days to you with whether the result is correct, and we will give a detailed overview of the errors that you made in the code, and how we think the code could be improved - even if we can't invite you to the personal interview. All of the people that have passed this test were perfect fits for us technically (and, as a result, the follow-up in-person interview was just for getting to know each other and screening for personality fit). Moreover, I've received quite a few replies from people who were saying that they're not looking for our position, but they just couldn't resist from finishing the game and sending us the results, because it was a great fun. Really good screen for "hacker" mentality, I think.

tricking people into free work is not nice

agreed. but the above seems pretty onerous but not free work

take home projects are work, if you are not paid, they are free work.

do you make a distinction between coding exercise in an interview and a coding exercise performed outside of the interview?

i don't see a difference between the two. and if its obviously a demonstration of your skill and provides no benefit to the interviewing organization beyond demonstrating your skills it seems not work to me. regardless if done at home or with interviewers

also tricking into work for the company is super terrible. offering an onerous demonstration of skill sounds terrible but up front at least

I find interviews very hard and unfair to both sides. Most of the best people of my team were the ones that could grasp the business domain quickly and provide solutions that fit environment + resources + expectations. Most (if not all) could not pass a test implementing some search tree algorithm, but they managed to learn and implement so much relevant stuff. I really don't know how to "measure" that with a bunch of made up scenarios and the candidate nervous bc of that specific circumstance.

although, personality fit is way easier if you dig through it. We had only one case in 3 years, and was a mistake that could have been avoided. Some of the recent interviews (6+ months or so until now) has been focusing more on culture fit, principles and previous experiences. (yeah, entry level jobs are not open.. would be different scenario)

@dpsutton coding exercises during the interview process are also bad, but for different reasons than the take home ones

@tiotolstoy It's really hard to give general advice about preparing for an interview with a Bay Area startup -- they are pretty varied. Startup "culture" can be pretty awful -- I've done a couple of startups and I've done the whole VC hunt thing and I would never do it again. Silicon Valley as a whole has some serious culture problems.

I've been thinking a bit about this - why is it that we, as a so-called "profession" now ask for people to do take-home/before interview coding exercises - whereas, if we look at other "professions", you would hardly ask a surgeon (interviewing for a position) to take-home-a-patient and do some operation then present their results for discussion when they come in - or, an engineer to build a bridge (for example), then bring it in for discussion. Yet, we do.

the medical profession has much more stringent licensing and application processes. there are matchings where you don't get to decide where you will work and might have to wait a year before you can reapply to use your super expensive degree. applying to places can be multi month affairs with numerous interviews. undoubtedly there are tests of skill involved as well. using a surgeon as an example of a good and fair hiring process seems like a bad comparison

Is it? Software engineering takes years of study, a super expensive degree and often multi-month interviews

there are lots of people who don't have super expensive degrees

And, with software engineering, you could also be putting people's lifes at risk, esp with medical devices.

@dharrigan I had this same discussion recently with a friend. His wife is a painter and as we often see people talking about software development as a "craft" I got curious about how they interview painters and I asked him. Most of the time is through portfolio, taste and asking the artist to explain/talk about the work done... I was imagining if this could also be applied to software and if made sense of not. (in fact in this case, they have lots of "free work" ..)

Yes, and there are doctors who don't also have super expensive degrees...if you're USA centric, perhaps...

Other industries absolutely do give out take-home/before interview exercises. I know of examples in law and in statistical genetics. Many industries simply aren't able to give something out, and that's why they have internship.

Perhaps they also have people opinonating how broken the interview process is too 🙂

My exposure is very limited, but I've never heard talks about it outside of the programming community.

other people do it, must be fine.

we should just do whatever we like, as long as we can point to other people, it always ends up so well : D

Not sure what your point is.

I think I've come round to just having a nice long chat about what they've done, what they would like to do, and what they wouldn't like to do. In the end, it's more about working together than finding the perfect candidate 🙂

(and let's face it, most companies hire people on a probation period anyway, so if it doesn't work out, then letting go of that person isn't hard)

i've never been hired nor hired anyone on a probationary period. and that sounds brutal to get a job and not know that they actually want you there

"Contract to hire" is common in a lot of (US) companies...

I don't think I've ever worked for a company that didn't have a minimum probation period (usually 3 months) - except the times I worked for myself.

Isn't it in the USA that it's all "to will", i.e., you can walk if you don't like it (I think 1 week notice?) but same also for the company, they can get rid of you with 1 weeks notice. At least in the UK, the "rules" are a bit more strict about what you can and can't do to people.

I also been always hired on probation, 3 months, but it's more like a customary stuff. However in low level retail industry in eastern europe it definitely is used against workers, because that first 3 months in those places allows a lower level payroll to be accounted.

When I started at World Singles Networks, a decade ago, I started as a contractor -- initially part-time through a friend who had bid on a project as a consultant and needed subcontractors, then hired directly on full-time contract, then converted to FTE. I've been FTE for nearly a decade now.

Not every state is "at will" employment, but it is fairly widespread these days: you can quit with no notice and you can be dismissed with no notice in such states.

i believe 49 of 50 are now. Montana being the holdout?

Hmm, apparently I'm wrong: yeah, I was just looking that up @dpsutton -- but various states have additional employment laws and/or exceptions that "tone down" at-will employment: https://www.rocketlawyer.com/article/what-states-are-at-will-employment-states-ps.rl

To change the subject a little (a lot?). I'm seeing the attraction of interviewing people "blind" (at least initially!) - i.e., being presented a CV with no name, no indication of ethnicity, or gender.

Is that taking hold I wonder?

this is law here in Brazil. You are hired under a different contract called "Experience Contract" for 1 up to 90 days, and them another contract is done if you are ""hired-hired"". Paycheck are the same, but you can be dismissed with no notice.

which is incredible weird is that in some sectors, you can be dismissed and "re-hired" after one week (the rule is 6 months to general sectors) under the same "experience contract" for more 90 days to come.

i went to a talk from a law professor who did a study that found the more enumerated rights in a country's constitution the less they were enforced and fewer rights they had in practice. Just reminds me that sometimes when things look good on paper they aren't necessarily great in practice. As your example shows

A somewhat related question - would you change something about your regular hiring process if you were to hire the very first employee? If that changes something, let's assume that it's your own company.

Would that person not be your partner in this case?

It won't take hold. From what I remember, when studies were conducted on blind CV evaluation, the opposite results of what the researches expected occurred. In fact, these initiatives, both https://www.abc.net.au/news/2017-06-30/bilnd-recruitment-trial-to-improve-gender-equality-failing-study/8664888 and https://www.reuters.com/article/us-amazon-com-jobs-automation-insight/amazon-scraps-secret-ai-recruiting-tool-that-showed-bias-against-women-idUSKCN1MK08G, have already been paused.

Not at all, it would be just a regular employee.

law of unintended consequences?

I would think of my first employee as a potential partner, because I would expect him to be able to support me in case I would not be available, and probably tasks would not be as defined.

I can see that. But still, I'm interested in the hiring process itself. Or rather, whether there would be any changes.

That's very interesting! I'll going to have to find some references so I can read up more on that. Thank you! 🙂