Live data from Hacker News

Technical interview performance is kind of arbitrary

blog.interviewing.io

191–200 of 246 posts

Re: Technical interview performance is kind of arbitrary

#191
post #124

Earlier quoted context omitted.

> but you're not going to get the same caliber of work from someone who first saw python two weeks ago compared to someone whose been using the language for 5 years on real projects. Careful. You probably need to define your terms more clearly. A CS student who knows Java (4+ years of experience) is going to turn out very different programs from a 20 year veteran of Erlang who is just learning Java. Even with bad Jav…

"Even with bad Java idioms, the veteran is very likely to be turning out much better code because he is thinking about the underlying architectural issues (failure modes, recovery, concurrency) with far more experience." Careful with that assumption. While there may be instances where this is true, I've met many veterans that couldn't think outside the small specialty they had become locked into. Idioms are powerful…

> I've met many veterans that couldn't think outside the small specialty they had become locked into.

It's the difference between 10 years of experience, and 1 year of experience repeated 10 times

Re: Technical interview performance is kind of arbitrary

#192
post #78

I have learned that an (in)ability to program "in the small" correlates very well with an (in)ability to program in the large, and now ask mostly simply questions whose answers are things like one-line Boolean predicates to test for well-defined conditions. It is paradoxically easier for an inept candidate to fake his way through an algorithm design question than it is to fake the coding of a simple test for "determi…

I've moved to doing something extremely simple: just give me pseudo-code for indexOf given a string and a character. If you can't write the 4-5 liner for linearly searching a string for a character, then there's not much point in moving further. It is shocking how many people get tripped up by it.

Is it a sign of insecurity that I just popped open vi to make sure I could solve this? :)

Where I work, we've been trying to fill a vacancy for a senior dev for months. Our one whiteboard question is similarly easy: find the largest integer in an array (The interviews have become easier since I was hired on). And yet... I've been watching an endless parade of people with decades of experience who apparently don't know how to write a for loop :(

Re: Technical interview performance is kind of arbitrary

#193
post #164

Earlier quoted context omitted.

> Sorry, but you are being scammed. You are selecting for sales skills, not technical skills. Read what you've written. You're asking the parent commenter to set aside eight years of personal hiring experience, over which time "every person I've ever hired who has passed that part has ended up in my 'great hire' category" (assuming, that is, that you've read what he/she's written). Can a candidate lacking the technic…

> Can a candidate lacking the technical skills go deep into details the way the parent commenter describes? More often than you'd think, alas. I'm going by about fifteen years of personal hiring experience, for whatever that's worth.

Do you mean that over your 15 years you've hired people more often than we'd think who later turned out to have been fooling you during the interview with their sales skills? That sounds terrible and I'm sorry to hear that.

On the other hand if you mean that you've discovered during your interviews that candidates more often that we'd think had been trying to fool you -- and that's why you didn't hire them -- well then that doesn't sound much different from the above person's eight years of experience.

I don't think anyone here would argue that there isn't a significant number of candidates for technical positions who BS about their technical skills.

Re: Technical interview performance is kind of arbitrary

#194
post #192
post #78

Earlier quoted context omitted.

I've moved to doing something extremely simple: just give me pseudo-code for indexOf given a string and a character. If you can't write the 4-5 liner for linearly searching a string for a character, then there's not much point in moving further. It is shocking how many people get tripped up by it.

Is it a sign of insecurity that I just popped open vi to make sure I could solve this? :) Where I work, we've been trying to fill a vacancy for a senior dev for months. Our one whiteboard question is similarly easy: find the largest integer in an array (The interviews have become easier since I was hired on). And yet... I've been watching an endless parade of people with decades of experience who apparently don't kno…

And yet they can somehow get through a telephone screening interview.

Re: Technical interview performance is kind of arbitrary

#195
post #128

Earlier quoted context omitted.

That's far less true than you might assume. I have seen a company pay someone 100$/hour to learn a new language as part of a 6 month contract. They were producing better code than the company's staff within 3 weeks and finished the project ahead of time. Granted, he was an EE not a software developer. But, deep knowledge of a platform is often more dangerous than helpful. The surface layer tends to be the least buggy…

I hear "Let's use reflection!" as "It's time to find something else to work on!" Outside of writing developer tools or unit test frameworks, I can't think of a worse code smell. It's a klaxons blaring, we're doomed kinda thing. Everytime I've seen it used, it turned into a quagmire of subtle regressions, strange effects at a distance and extremely brittle code. I think the best pattern there are: 1. Thou shalt never…

[deleted]

Re: Technical interview performance is kind of arbitrary

#196
post #128

Earlier quoted context omitted.

That's far less true than you might assume. I have seen a company pay someone 100$/hour to learn a new language as part of a 6 month contract. They were producing better code than the company's staff within 3 weeks and finished the project ahead of time. Granted, he was an EE not a software developer. But, deep knowledge of a platform is often more dangerous than helpful. The surface layer tends to be the least buggy…

I hear "Let's use reflection!" as "It's time to find something else to work on!" Outside of writing developer tools or unit test frameworks, I can't think of a worse code smell. It's a klaxons blaring, we're doomed kinda thing. Everytime I've seen it used, it turned into a quagmire of subtle regressions, strange effects at a distance and extremely brittle code. I think the best pattern there are: 1. Thou shalt never…

Unfortunately you practically have to use reflection for certain things if you work in Go, although the language authors have tried to discourage it by making the APIs absolutely awful.

Re: Technical interview performance is kind of arbitrary

#197
post #124

Earlier quoted context omitted.

> but you're not going to get the same caliber of work from someone who first saw python two weeks ago compared to someone whose been using the language for 5 years on real projects. Careful. You probably need to define your terms more clearly. A CS student who knows Java (4+ years of experience) is going to turn out very different programs from a 20 year veteran of Erlang who is just learning Java. Even with bad Jav…

Why didn't you just write this: > A CS student is going to turn out very different programs from a 20 year veteran.

Because its so obvious no one cares.

Re: Technical interview performance is kind of arbitrary

#198

Earlier quoted context omitted.

>1. If the candidate can't be bothered to complete a 2-4 hour (depending on claimed seniority) code test in the language of their choice, we can't be bothered to talk to them. A good reason not to work at your company. Why would I want to invest 4(!) unpaid hours into something where I am not even considered seriously yet? I recently had a coding challenge, which was not only vague, but also took up two hours of my t…

You strike me as the type who would also balk at fizzbuzz and other 'typical' interview questions. What do you propose? Say you have to interview a candidate for your own startup? How would you go about it?

I actually like fizzbuzz and stuff like that. My most recent and best coding challenge experience was one from Cloudera. It was 2 questions and I had 70 minutes time in total. The difficulty was not something crazy. To me it felt like something you would get as a homework in Uni, but slightly more complex. I was able to finish it in 40 or so minutes and even had fun doing it, because I did not get frustrated by lack of details in the problem description.

But when a company sends me 2 hours on some weird platform that tells me 3 out of 10 test cases work, but doesn't tell me why or what even the input is, I just get frustrated. One of the worst coding challenges was asking me to implement the cd (change directory) functionality. But the details were so bad that I had no idea if I have to invest time or not into edge cases etc. I basically had to guess the test cases, but eventually failed the test since I ran out of time.

Re: Technical interview performance is kind of arbitrary

#199

Earlier quoted context omitted.

Why didn't you just write this: > A CS student is going to turn out very different programs from a 20 year veteran.

Because its so obvious no one cares.

Exactly my point. Adding additional information can't possibly make it less obvious.

Re: Technical interview performance is kind of arbitrary

#200
post #161

With programmers, the single easiest way to identify good candidates (in my experience) is sheer interest in what they do / desire to learn. This is a learn everyday field and if you're interested in what you're doing, you're going to do a lot better at it. It's hard to apply yourself mentally to something that you don't have a good level of interest in. Given that it's a learn everyday field, people with that level…

> The single most effective way that I've found to interview for "interest" is to just get them talking about something they've done before and ask them to go deep into the details. You get everything you need from watching somebody talk, with a smile on their face, about how they solved some problem in a creative way that makes them show some pride. Sorry, but you are being scammed. You are selecting for sales skill…

It's not the exclusive criteria, just a part of the process that I've generally found to be associated with people who excel. We are still going to have them interview with some type of subject matter expert related to the position but all jobs are not created equal.

Positions for things like security, as another commenter mentioned, are very much experience driven. Java is another simply because it has a very high learning curve to become really adept with it. It's doable, but I'd extend the expected ramp up time to longer than 2 weeks.

There's nuance to everything. I didn't mean it to come across as if that was the only factor in hiring.

Post reply on HN