Clojurians Log v2

(back from a doctor's appointment and catching up...)

Yeah, I think it's a fundamental problem that most companies seem to completely overlook: how you solve problems at work is completely different to any interview environment. Even the trial pair programming sessions, since you're suddenly thrown into a new environment with a new teammate, and you're still under "interview" conditions because you're being "tested".

And as @thom704 says, how do you deal with take home tests if you don't normally program at home because you have a full home/family life? A lot of people don't actually have a "work-equivalent" computer setup at home -- so expecting them to be able to produce any sort of non-trivial "app" at home may well be completely unrealistic.

It just shows how much bias companies have around hiring: there is an underlying belief that "every" developer should have a "development system" at work and/or should be able to switch into "development mode" in any environment with no notice. Both of these are simply not realistic expectations.

(this is all part of why I do not put candidates through any sort of coding test)

There also seems to be some sort of strange hazing mentality, or at least a weird satisfaction many have in disqualifying someone, as if somehow that's proof something is working because so many can't pass it. I'll see conversations where someone is bragging about what single factoid they're checking for because 'omg if you haven't heard of this by uni 101 you can't program for shit bro', as if you can really correlate any one or two data points with overall programming skill that easily. I feel like there's a lot of superficially treating strength as a scalar, that one either has or hasn't, when its really a vector, with a billion different useful directions (including an infinite amount of directions that haven't been explored, that one day someone will pioneer and show to be useful) and its useless measuring some vector going off in a direction completely unrelated to your work (albeit close, superficially), as is often done with a lot of these tests. I'm gonna go hire a bodybuilder by seeing who can bench best with their feet

Excellent analogy @zdot101

There was a good post to Hacker News recently by a guy who was lamenting the state of tech interviews. In his follow-up post he said he heard from so many people about how broken it is. But what was surprising was that many of those people were the hiring managers themselves. Even they acknowledge that the way we conduct interviews is ineffective and broken. So it seems like we as an industry whole dislike it but for some reason there are too few who are willing to do anything about it. Someone on HN suggested it was because FAANG companies do it so everybody wants to be like them. I’ve never interviewed at one of those companies so I don’t know. Seems like a plausible theory, though.

I interviewed with Google years ago and stopped the interview about ten minutes in and switched the topic to hiring practices and interview technique because it was exactly the sort of broken approach that they've been (rightly) widely lampooned for. I gather they've changed their interview process these days (to some degree). My experience with early screening by both Microsoft and Amazon suggests they're way better than Google. I have never gone deep enough with either of those to see whether later rounds are just as bad.

The thing is, even they complain that their hiring practices don't seem to be successful -- they have a high churn rate and quite a high post-hire termination rate for candidates that aced their stupid interview process but then didn't actually work out on the job.

I've never had to let someone go for competence-related reasons after they've gone through my interview process. I've been a hiring manager to some degree for about 25 years at this point. Everyone I've hired has worked out well in the job.

Based on your interview mind map I gather you’re able to get a pretty good feel for whether the candidate is a competent developer AND whether they’re someone you want to work with.

Yes, and mostly I try to get the candidate talking about work they've done, problems they've had, interpersonal stuff, some opinions on technology and practices. If they're a good fit for the team/people/company and they don't raise red flags based on the areas I like to discuss with them, I figure we can always mentor them on some stuff if they have weaknesses in actual coding.

I start in the top-right and work my way down that side, then switch to the top-left and work my way down that side.

By getting candidates to relax and just "chat" about a wide range of stuff from their past work experiences, you can find out a lot about them.

I've used that mind map for about ten years I think...

rseq 🙂

Here is a guide to interviewing from Joel Spolsky of StackOverflow fame. I find his blog fascinating. Do read his article on estimating time. https://www.joelonsoftware.com/2006/10/25/the-guerrilla-guide-to-interviewing-version-30/

That's true. I am lucky that Cursive still run well on my 2011 mac book air.

My non-work machine is a little Dell XPS 12 from about the same era 🙂

"But in general, the way to learn the most about a person is to let them do the talking. Give them open-ended questions and problems."

(I disagree with Spolsky on a lot of things but so far this article seems solid 🙂 )

Aw, and then he goes and spoils it

Easy Programming Question
Pointer/Recursion Question

I forgot what he exactly said about these two points, but an easily solvable question is not too bad. In another article he praised FizzBuzz as such a question.

And the article is from 2006, so pointers must be a thing back then.

And then he devolves into programming exercises on a whiteboard... so sad... he was doing so well until about halfway through 😞

Pointers are still a thing. They're just hidden now.

For me the gist of the article is, hire smart people who get things done.

Yeah, and that's fair to a degree. Part of my problem with Spolsky is that he makes out his company only ever hires "A+" programmers -- but that's what a lot of companies try to tell you "we only hire the best!" and that's such a b.s. attitude.

It's like the whole nonsense about the "10x programmer". You can't have a company full of those -- for all sorts of reasons (not the least of which is that "10x programmers" are stupidly rare!).

10x programmers may also like to work in isolation, I think.

Which does no company any good...

But I do agree that programmers should not be treated as interchangeable. In reality, there might be 2x programmers, 😂

But not 10x

I've worked places that assumed programmers were interchangeable -- it's unpleasant. A good team is diverse in many ways, with complementary skills and approaches.

From my experience of giving interviews in different places, tech divisions of non-tech companies tend to do that.

But my experience is limited.

I worked in England for most of two decades and I've been in America for two decades now. And I've been a hiring manager of some form for close to 30 years now I guess... across a range of industries... I'm very skeptical at this point 🙂

My experience is limited to India.

I believe that there are 10x programmers ... it all depends on with who you compare them 🙂

I love to compare myself to my cat, for example.

That's also true when I compare myself to Rich Hickey.

My dealings with India have been at a distance. When I first moved to the US, the company I was with experimented with hiring through an Indian agency (a very poor experience). Then I moved to Macromedia who had an excellent facility in Bangalore and the teams there were great to work with but they mostly operated outside our office hours and we outside theirs. I wasn't senior enough then to visit the facilities in India (my direct manager went out there quite a bit).

Did you name your cat Rich Hickey? :rolling_on_the_floor_laughing:

(then Adobe bought us and they had a large facility in Noida, set up much the same as Macromedia's Bangalore facility)

My cat is fluffier than Rich's hair.

How should you prepare to get a remote clojure job? I'm an experienced system architect and Java / Go / JS programmer with fp aspirations, but I'd like to come prepared. Any tips?

There is some good points on hiring in the latest cognicast https://blog.cognitect.com/cognicast/149

And to address a very specific point somewhere high up in this discussion about javascript and connecting to mongo.

We work in Clojure and have mongo as our database. I've been working here for 2.5 years, and I have no clue how to connect to mongo from Clojure. Reason is that this was already done before I arrived, I haven't had a need look at/fix that code, and doing the connection-setup is something you're likely to do only once during a projects life-time, so it's not anything I keep in my working memory.

To be fair though the OP said that the candidate would have google available, so I should probably be able to figure it out.

Lol, https://stackoverflow.com/questions/60016867/how-to-use-a-monger-connection-globally-in-the-server/60052316?noredirect=1#comment106211906_60052316 first thing that showed up was me answering how to do this.

I'm the OP. What I do is base my questioning around their CV. If someone, coming in as a senior developer, says they have 5+ years of Mongo and 5+ years of Javascript, and allowed to use google, they struggle to even do a connection to the database and query for results, then it makes me wonder why.

I just did a google for "mongodb javascript connect" and there are lots of examples

I find that more and more, people embellish their CV

I find myself in total agreement with you. There are few problems you're not able to solve by googling for five minutes.

A tool that I've been using with (what seems like great success) is to reply to any job application with an "aptitude test" of some sort. This could be a coding test. When we post job openings on the major Norwegian site (http://finn.no) we get quite a few applications, and an aptitude test filters out some 80% of them, either because they can't be bothered to answer or because the answer basically show they cannot program.

Problem is, that we don't know how many of the "can't be bothered to answer" who are actually candidates that we would like to talk to, but for some reason don't want to do the test.

The aptitude test is something you do before a possible first interview.

Yeah. Hiring is hard

There isn't a perfect hiring process, otherwise we would all be doing it.

Each company imposes different constraints on how to interview/hire people

What I did last time is filter CVs by priority, then actually went ahead and scheduled 45min "get to know" talks with the most promising candidates. If there was a good fit (would they enjoy doing the tasks that need to get done? would I enjoy working with them? would they enjoy working with me?), then I'd send a small aptitude test to be able to compare results. The aptitude tests ended up pushing some candidates up the queue, some down.

This was possible because I only posted the job in Clojurians Slack and ClojureVerse, and the hired applicant found us from there. Posting the job at the local Danish startup board (https://thehub.io) got us 3 times the CVs but much lower "compatibility".

What kind of aptitude test do you use? Is it a work-sample test?

Listening to lvh talk about work samples, I just wonder what a work sample would look like for a UI-focused developer. UI is notoriously complicated and I’m not sure there’s a way to “compare” approaches.

Yes. Basically something that should take the candidate about/less than an hour to solve.

Oh, interesting. Do you think your test is easier or harder than this one? https://www.codewars.com/kata/52742f58faf5485cae000b9a Also, do you give your work sample test before or after speaking with them? I do it after, and get a maybe ~80% response rate (though maybe 20% of those show too many problems to continue the process). I think it helps to give it after talking with them, because a lot of people apply to many jobs without knowing too much about them, so they may not be interested enough yet to look at a sample problem.

Somewhat easier, but a lot more open. We do send the test before speaking to candidates. This is more important when you get a lot of candidates, as you apply the filter earlier on in the pipeline, so to speak.

I see, yeah, makes sense

I would be in the "refuse to answer" category -- my views on technical tests like this are fairly well-known and I won't work for companies that use them.

I would totally be onboard with someone who denied doing a test like this, but I would like to have an explanation, and preferably something that convinced me of their ability to code. You could easily point to your vast corpus of open source work, but many candidates, as you pointed out, can’t.

@seancorfield For the anti-programming test thing, is it more out of a sense of fairness (e.g., people with no suitable dev computer being disadvantaged), or that it actually is against the interests of the company doing the tests? What do you think about the research indicating that IQ/cognitive aptitude tests (illegal/impractical in the US) > work sample tests > other interviews for general interviewing? Your record seems very good, but I've also talked to others who do a similar strategy with very poor results.

I’m curious (and you might have answered that already) why you are opposed to a test that for someone like you would take half an hour to complete, which is probably less than what you’d spend on touching up your resume and writing the cover letter.

Personally, I’d much rather apply by sending in a larger work sample if that meant I could get away without the resume and cover letter. I find those really hard to write well.

I have answered that already in the main channel. Thom Lawrence mentioned a good reason too -- having a family with three kids and almost no time outside work. What about folks who don't have a "work-capable" computer at home? etc etc There are more reasons in the channel.

Asking people to do take home tests of any sort is basically discrimination.

(as you can tell, I am very strongly opposed to such tests on principle)

Mostly "fairness". There are a lot of assumptions baked into how most companies approach interviewing that cause a lot of bias.

And it's particularly acute at the junior end of the scale where it's much harder for candidates to object (as well as participate fairly). Which is why I make such a big, public deal about it.

> I've also talked to others who do a similar strategy with very poor results. As an industry, we almost never bother to train people to do interviewing "properly". We somehow magically expect the average software developer -- who we hired for their ability to program! -- to be able to do a good job of interviewing other developers... and then we're surprised at the poor results?

For the record, I also have three kids (and do climbing and skateboarding (and write presentations on my spare time (and spend too much time on Twitter (and sometimes contribute to open source (and enjoy doing coding tests for interviews (and just noticed there is no paredit in slack)))))

I have zero kids (but I have a dozen cats, do they count?) and I don't do much in the evenings outside work (or at weekends, except for occasional cat shows) but I still object to take home tests even tho' I spend all evening on my work-capable laptop while watching TV. So I certainly could do any number of take home tests -- but I still refuse to do so on principle 🙂

The thing is you can't please everyone. There are some people who would automatically turn down a job if there were no coding test (out of concern for co-worker quality), so one could say you'd be unfairly discriminating against those people with your approach. Best you can do is to have a system that works pretty well for many people. To appreciate what kind of negative impact the work-sample requirement has, we'd need to see the numbers for viable applicants dropped out because of lack of time/access to a computer. I would be surprised if it was a big proportion.

> There are some people who would automatically turn down a job if there were no coding test I haven't encountered that in nearly 30 years of hiring (but you may well be right that such people exist).

(I have had people comment that the non-coding-test style interviews I give have been the toughest interviews they've ever had so... different strokes for different folks)