Clojurians Log v2

> Write FizzBuzz with tests This is the best answer in the thread. You can beef with the exercise picked (not my favourite either), but as the only answer to actually suggest you actually get them to write some code, I'm surprised so many people were more keen to shoot it down than offer technical alternatives. Any developer hiring process that involves you looking at some of their code is better than any developer hiring process which doesn't involve you seeing any of their code, end of story. No matter what else you test, no matter what else you're interested in (I think testing teamwork, collaboration and communication are vital), if they can't write good (as defined by context, hiring level and ability to grow) code, they will be a bad hire. The best way to test that is to look at their code.

Code is important, but coding in front of a whiteboard during an interview is a very noisy signal. I personally have a strong preference for "take home" exercises; i.e. i'd ask them to send me their FizzBuzz solution before they even come in. I know some people really dislike that too, though, and not everyone has the luxury of spending a lot fo time coding for an interview. I try to pick something vaguely relevant to the job but that I can do in half an hour, and I tell them not to spend more than 2h on it. Definitely not perfect, but I think it beats spending an hour in front of a whiteboard trying to count parentheses without parinfer.

^ 100% agree

I have done interviews where they asked me to bring in a development environment I was comfortable with so we could pair on something. Like you, I much prefer to give people the time to go away and think without me peering over their shoulder (as you say, something short, and as part of an interview process that more broadly is respectful of the candidate's time). Both are much better than trying to get someone to write code on a whiteboard... and yet that's still better than an interview process where you don't get to see any of their code

Why not ask candidates the same questions about the business that are on your mind?

That's what I would do, I would try to break off a piece, proportional to what I and the candidate could handle, of what ever I was working on. Give them an abbreviated version of why I was asking, and let them tackle it anyway they wanted. If I, as the interviewer, didn't think it was worth diving into the code, then i think a codeless interview would be fine. If they said something I didn't think could be coded in a correct way, i would ask them to clarify with code. I suppose it would be a good idea, to ask the interviewee to estimate some tasks, then do some soft checking to see if they could meet those estimations.

I would do the second half of the 25 minutes. In the first 25, I would ask them what stuff in there life, hopefully tech related, i could help with. Then reverse roles.

Just in case - there are some pinned items.

"What's wrong with Java?"

point_up::skin-tone-2 Yeah, that's one of my go-to interview questions. I also tend to ask "What's your favorite <tech/language/framework/whatever> and why?"

Thanks for the ideas 👍

With something the scale of Java, I think it's also worth asking what are you not learning and why? ... It's a good idea to dig into the process of turning a forest into a smaller collection of trees - how did you eliminate the other trees?

Something else that occurred to me: depending on which version of Java the company is using, and how "modern" their style of Java is, it's probably worth asking about the candidate's experiences with recent Java releases and which new features they think are the most exciting?

I agree Sean, I'm trying to do all of that, but they aren't being very responsive.

I would never hire a person just because they were able to churn out fizzbuzz, but a candidate who was not able to do so would have to work hard to convince me to hire them. Also, a neat follow up when a candidate has written an impl of fizzbuzz is “now write a test for this”. 99% of the time the candidate will have written a fizzbuzz that does a println at the innermost level, and then we get a nice segway into talking about imperative shell, functional core. Unless, of course, you’re interviewing an old CL hand which just wraps their impl in with-out-str to capture the output and test against that.

In this sense, I’d equate being able to churn out fizzbuzz with being able to write a cover letter. I would never hire on the cover letter alone, but if the cover letter sucks, it’s really hard to get by the initial screening.

Remember that unless you are trying to get desperate candidates, you need to respect the applicants time too, and show why you would be offering the best job for them. Fizzbuzz does very poorly for that.

I wouldn't bother checking if the candidate is lying about the technical skills in interviews (so has no proper experience but just read the fizzbuzz articles, or didn't even read those). Instead I would focus on what the candidate is claiming about their skills and personality, and if that does not match reality in the probational, they are out

I suppose that's different if you hiring for a consultancy, and the customer will see their actual skill level before you do, and the reputation damage is then done. Context matters, and the OP was pretty brief about the background.

thanks again everyone, I think it's harder here and now in slack to judge someones immediate familiarity with certain topics, and by extension, think about what questions should be asked. However, i believe that in conversation during an interview, where feedback is much stronger due to facial reactions, and how the immediately react, one can move through topics about java (or anything) and get a good sense what they know. But it helps me to hear peoples reactions to the idea. Better then the fear of not having any feedback!

"You're going to be doing the majority of your engineering work on the JVM - can you tell me a bit about its strengths and weaknesses?" I'd expect a good candidate to talk about portability of code, GC, memory overhead, language support, and so on. I'd expect a better candidate to start by asking / exploring what we're comparing with, and perhaps talk more about use-cases than technical features. When I interview, my goal is not to see what the candidate knows or doesn't know; my goal is to see how they think, and whether they know what they don't know.

depends on what level I need the dev to be... but for the most part I operate with the idea that a good dev makes a computer productive and a better dev makes another dev productive. also, if interviewees tech knowledge informs my decision, sometimes a dev's knowledge of some detail is a red flag. to clarify, I don't like it when people know how deeply nested hibernate transaction statuses propagate... that tells me that they have dealt with that problem which tells me they have probably gone wrong in their organization of code. similarly, there are git features that is better not to know. if interviewee knows java and has some code to show, he is a dev i can guide to productivity barring any communication difficulties

Write FizzBuzz with tests

> What question exactly do you ask in 30 minutes to determine if someone should move on to the next round? Surely wanting to work with Java is the disqualifying criterion! trollface

> Write FizzBuzz with tests I hope you're just joking... The problem with questions like that is a) being able to write FizzBuzz with tests is no measure of being able to develop real-world software in any language and b) there are plenty of articles written about how to write FizzBuzz with tests in almost every language so "anyone" can learn that for the interview, regardless. And yet, there are people who still actually use this as a technical test in an interview 😞

By looking at how they're writing fizz-buzz, you can easily check if they're prepared in advance. And ask a question which is not covered by those articles. Say, how to capture the whole output into a string and parse it; How to implement it as a lazy seq; How to implement in a loop form, or as reduce.

The OP question was about Java tho', not Clojure.

I feel like any opening question is fine, I just hope the interviewer has some personal motivation for the questions there asking. Otherwise it's like trying to discuss which restaurant or cooking technique ideal when the person isn't hungry and/or broke. Sometimes a hamburger quickly cooked on your grill taste better then a Beef Wellington in a 5 star restaurant. Context is everything.

Luckily, I have quite a bit of fundamentals to tackle if the topic is pure java, so i'm going to speed run a class online. 🏃 think_beret