I wanted to start a discussion on different types of interviews and why you prefer that certain style (and have you had success with it) ? For example, do you like to give an in-person coding challenge and see how the candidate does one the spot, or would you rather give the candidate a take home project and walk through their code and see how they articulate their decision making. Or anything else ...?

@thurmondmb Click the (i) button top-right to show channel information: Pinned Items are in there.

@darrell thanks for ranting. You said what I was thinking. I was given a javascript tree problem for a Clojure job that include a combination of a DFS and BFS. Up until that point, I haven't used a BFS in industry and it had been over 4 years since CS undergrad. I also never seem to do well when put on the spot to solve a problem with people watching me code. I can ask the right questions but I usually need to think about it for a little bit then program the solution.

I’m the same way. Putting a candidate on the spot rarely shows what they’re capable of and in probably 99% of the jobs, it’s unnecessary. In fact, I personally don’t want employees or co-workers making snap decisions on the spot. The best code always comes from a thorough understanding of the problem before a single line of code is written.

When I interview, the number one thing I look for is enthusiasm. I don't do whiteboards, nor silly really abstract questions about data structures. I invite the candidate to show me some code they've wrote, something they are proud of, and to talk me through it.

The retort is often, “But we want to see how that person thinks.” Except, when outside of interviews do we ever care about how someone thinks? I’ll qualify that by saying that we do care about how people think but we have to be around them for longer than an hour to fully understand that.

I don't really care what language they pick (although I do have a strong leaning towards FP-style languages :-))

@dharrigan Exactly! I want to know that the candidate wants this job because they want to do a good job, they love writing code, and they’re someone I can spend 8 hours a day with.

That excludes a lot of candidates who have very valid reasons for not being able to "show" their code.

If they have no code to bring, I offer a small coding challenge

which I pre-prepare based exclusively on their CV

I am amazed at the number of times someone puts down "MongoDB and Javascript" on their CV and when I ask them to write me a simple connect to a running mongo and pull back all the entries - they simply cannot do

What I've tended to do these days is: if a candidate lists their OSS contributions on their resume I will go look at it and use it as a "negative test", i.e., if it's poor code, it's a black mark. But I don't otherwise pay attention to it.

Which leads me to think what else have they, um, *embellished" on their CV...

Is that "small coding challenge" something you expect them to do at home or in the interview?

During the interview. This is if they have no code to show (which has only happened a few times). And I've already done most of the prep - I've loaded up the db instance, I've setup a project for them, I've created a skeleton file.

All they have to do is plug in a routine or two.

And yet, I'm amazed at the number of people who can't

Oh, I also allow them to use google

I tell them that - I cannot work as a programmer without using google/stackoverflow/seancorfield, therefore why should I set artificial limitations on you?

What about people who vapor lock when being watched during situations like this? I know people who are brilliant that basically shut down when being watched like that. Hell, I’ve done that before.

They are free to use whatever resource they want to solve the problem.

and yet I'm amazed...

I'm very much against live coding challenges in interviews. I would probably walk out at that point.

I've not had a person zone out on me yet - perhaps it's the way I run the interview? <shrug>

There is no perfect interview process, if you know one, please let me know 😉

lol

I've walked out of whiteboarding interviews 🙂

They still offered me the job -- I turned them down.

Hopefully that company took the hint and reconsidered their interviewing practices.

I remember my first real interview after uni

It consisted of the project manager showing me about 10 pages of printed off code

and asking me to critique it

My first job 🙂

Maybe that’s what I so dislike about modern technical interviewing practices; they completely discount how much creativity is involved in coding. The way you solve a problem may be different than the way I solved it. Which one is correct? They may both be! Is one better than the other? Possibly, but that can only be determined when seen as part of a whole system. I fail to see how an interview can determine that when it’s all about watching someone write some code to see how many algorithms they use.

@darrell wouldn't whether they were able to solve it or not still tell you something though?

I agree with being able to solve the problem, but I never have to code with someone looking over my shoulder every day unless I am discussing my code with someone

My current job (C#, TypeScript, React) I was referred by someone and just discussed past projects, how I solved the past problems, and architecture I did on a Clojure system. It was a good experience, minus the fact that I'm still working with dotNet and two outsourced JS projects

How common is it for someone to be able to talk big game or are very charismatic and then not being able to code simple things vs someone who knows how to do these hackerrank problems but then cannot code at work?

I dont think asking BFS/DFS sorta questions are fair assessment since they can be rather difficult without practice but I think easy coding problems are a good tool to use.

Reversing an array is not so uncommon in real work. Filtering things out. etc

(reverse my-seq) 😂

but yes, reduce/map/filter are common

Anyone here uncomfortable about take home tests? I’m very aware that if I ever had to get a real job again I’d either corpse on a whiteboard coding test or struggle to find time out of work hours in between three kids. But we’d always be reluctant to hire anyone without seeing them approach a new problem in code.

I don't mind take homes, I always liked coding up a solution and then walking the interviewer through my code and what improvements I could make

@mario.cordova.862 the second one is probably rare, and if it occurs, it would probably be a matter of them not being able to code in an organized way (instead of not at all), and it is probably easier to pick up on the job than general problem solving

If I were getting interviewed my ideal situation would be to have a conversation about my experience, small easy programming task and then a take home project. The take home would be to do something trivial but in a language that I do not know. And I can add any feature I would like. Sentiment analysis for example

How trivial is trivial?

Good question

Perhaps something like consuming some API and displaying some data on a front end

Here is a pretty good one that is trivial, though not as trivial as fizzBuzz: https://www.codewars.com/kata/52742f58faf5485cae000b9a

that would be too simple to be the whole interview, but maybe a decent first question

Thats a good one. More fun puzzle solving then algorithmic computer science-esque

@isak Yes, but not all problems are solvable in a half-hour interview, especially when someone is sitting over your shoulder watching you solve it. I mean, I’m a pretty fast typist but my speed and accuracy at just typing out a general sentence like this one dramatically decreases when someone is watching me. I’ve seen that happen with so many people that I think it’s more common than not. So, aside from pair programming (where my typing also dramatically decreases), I feel that watching someone code during an interview doesn’t tell you much.

@darrell I get that, though if people adjust the difficulty of the problem accordingly, it could still be a useful signal, no? Unless you think neckBreathing_perf is uncorrelated with onJob_perf (no neckbreathing) across candidates?