Technical interview performance is kind of arbitrary • Hacker News Board

Re: Technical interview performance is kind of arbitrary

#151

Post by jchendy » Wed, Feb 17, 2016, 10:35 PM UTC

grillvogel wrote: post #135

dms105 wrote: post #120

Earlier quoted context omitted.

I like the law/programming analogy, but theres probably more of a margin for error when your job is to convince some people, depending on if you're prosecuting or defending. If you make even a small mistake when programming, it could break your entire program.

if you make one "small mistake" while lawyering an innocent person might get sentenced to death. why do so many programmers think their job is inherently more special and difficult than everyone else's?

> why do so many programmers think their job is inherently more special and difficult than everyone else's?

Probably largely because they get paid more than all of their peers when they start their careers.

Re: Technical interview performance is kind of arbitrary

#152

Post by jchendy » Wed, Feb 17, 2016, 10:40 PM UTC

staunch wrote: post #6

Most interviewers don't ask enough technical questions to have any idea what a candidate knows or doesn't know. If their one or two questions happen to be something the candidate knows well, they'll call them a genius. If they happen to not know, they'll label them an idiot. You can learn a lot more from 20+ rapid fire questions than forcing a candidate to eek out an answer to something they're not familiar with. And…

What are some good questions that you can ask 20 of in less than an hour?

Re: Technical interview performance is kind of arbitrary

#153

Post by hackinthebochs » Wed, Feb 17, 2016, 10:40 PM UTC

kelvin0 wrote: post #112

chrisper wrote: post #67

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 agree with the parent that take home projects (as the initial filter) are a non-starter. It's because they're flat out abusive. The employer uses their position to offload the cost of their hiring onto job seekers. The fact that our first interaction is exploitative couldn't be a bigger red flag.

However I am completely fine with fizzbuzz tests, even take home fizzbuzz. But this literally needs to be something that will take no more than 10 minutes, and for most people a couple of minutes tops. And in the question have a disclaimer: if this takes you more than 10 minutes to do, this won't be a good fit, so save yourself the trouble.

I actually don't mind the idea of take home projects, but only after significant investment on the part of the company. They need to have something on the line as well if I'm to devote significant time to it. Paying a good hourly rate for the time to complete it is the most straightforward way.

Re: Technical interview performance is kind of arbitrary

#154

Post by vonmoltke » Wed, Feb 17, 2016, 10:41 PM UTC

maxaf wrote: post #69

CryoLogic wrote: post #63

Earlier quoted context omitted.

I was bummed out recently when I did a take home test for a local start-up, which asked me to build a full web app. I spent 4-6 hours on it making sure it was perfect - just to turn it and and get told I did a great job but they decided they didn't really want to hire any non-senior engineers and where just testing the waters. This is happening a lot in Seattle recently - the job market is here is terrible for anyone…

Poor execution doesn't invalidate the idea. Happened to me too, although on a smaller scale. 4-6 hours is a bit much for a take-home evaluation project. If it can't be reasonably done by a distracted person in 4 hours, it's too hard/too long for a take-home test. Hopefully people will learn to do this right over time. Or, someone might solidify a common platform for doing this, a-la HackerRank or any of the other sim…

Poor execution doesn't invalidate the idea but it does hurt its effectiveness by making candidates gun-shy.

Re: Technical interview performance is kind of arbitrary

#155

Post by muddyrivers » Wed, Feb 17, 2016, 10:43 PM UTC

splintercell wrote: post #136

muddyrivers wrote: post #61

Earlier quoted context omitted.

I apply almost the same approach as OP. You can get a relatively good picture at a candidate's engineering skills and thinking ability via "go[ing] deep into the details", compared to asking algorithm questions. I also ask candidates to code on a realistic problem. It doesn't involve any "fancy" algorithms or "tricks". What I want to see are the coding style, attention to details, and of course, if the candidate is c…

> I also ask candidates to code on a realistic problem. It doesn't involve any "fancy" algorithms or "tricks". What I want to see are the coding style, attention to details, and of course, if the candidate is comfortable at coding. I have been reading a quora answer about why most of the developers fail FizzBuzz test and the author differentiates between Programming and Engineering and he says that programming is aim…

The current common interview practice is more like a programming contest. The candidate has to figure out a problem and finish it within ~30~35 minutes. Very competitive, but with little engineering involved.

I like the "Software engineering fizz buzz" idea. For backend engineers, I usually ask the candidate to implement a commonly used API in a language she/he is most proficient at.

Re: Technical interview performance is kind of arbitrary

#156

Post by blackflame7000 » Wed, Feb 17, 2016, 10:45 PM UTC

deangiberson wrote: post #131

bsder wrote: 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 too have found this assumption to not always be the case. At my company there are certainly some people who qualify as vets yet insist on writing purely procedural C style code and have yet to adopt modern paradigms like OO design simply because they are so far removed from their education.

Re: Technical interview performance is kind of arbitrary

#157

Post by ChemicalWarfare » Wed, Feb 17, 2016, 10:46 PM UTC

maxaf wrote: post #29

Take home tests FTW. The thinking goes as follows: 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. 2. If the candidate does reasonably well by completing the code test somewhat on time (with a fat margin allowed for them, well, having a life) and within parameters of the task, they're invited…

I do agree that "homework" type tests are the way to go. The only caveat is - someone needs to be REALLY interested in working for you to do this as a first step. A 15 - 20 min conversation with a hiring manager or an HR person if you have HR :) to cover things like the specifics of the position, candidate's 5 min summary of their career, approximate compensation, etc as a first step. Then you decide whether you like what you've heard and the only thing standing between the applicant and the offer is the completed assignment.

Re: Technical interview performance is kind of arbitrary

#158

Post by acveilleux » Wed, Feb 17, 2016, 10:48 PM UTC

Retric wrote: post #128

jkyle wrote: post #91

Earlier quoted context omitted.

> I expect a programmer to be able to pick up a new language or database within a couple of weeks (tops) in most cases. They may be able to hack around, write a for loop, track down a bug....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.

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 write code that uses reflection on its own code base.

2. Thou shalt never use reflection unless all other options have been proven worse.

Which leaves mostly unit test frameworks for some reason...

Re: Technical interview performance is kind of arbitrary

#159

Post by elliotec » Wed, Feb 17, 2016, 10:58 PM UTC

maxaf wrote: post #88

t0mbstone wrote: post #80

Earlier quoted context omitted.

"plagiarism based on a Google search" Uh... If the solution is readily available on Google, and they can solve the problem effectively with that solution, then they didn't plagiarize. They operated exactly the way they should work in a real world scenario. The worst kind of employees are the ones who insist on re-inventing the wheel every chance they get, instead of using industry standard libraries.

It was worse than what you describe. It was literally a wholesale copy/paste of a related but not-quite-right solution. The code test involved designing a data model for chess, but the candidate took an implementation from elsewhere that didn't give us the opportunity to evaluate their modeling skills (i.e. "I will create these classes with these fields and connect them like so").

That sounds like an excessive test. What kind of code are you guys writing? Why is it not okay for him to use implementations from elsewhere? Should he really reinvent the wheel to try and impress you?

Reminds me of the time I got asked to write a merge sort algorithm in Ruby. I wrote array.sort! on the board, the interviewer told me I have to rewrite it from scratch, and I was done with the interview. Because we create abstractions and reusable implementations for a reason.

Re: Technical interview performance is kind of arbitrary

#160

Post by muddyrivers » Wed, Feb 17, 2016, 11:03 PM UTC

cmccomas wrote: post #79

muddyrivers wrote: post #61

Earlier quoted context omitted.

I apply almost the same approach as OP. You can get a relatively good picture at a candidate's engineering skills and thinking ability via "go[ing] deep into the details", compared to asking algorithm questions. I also ask candidates to code on a realistic problem. It doesn't involve any "fancy" algorithms or "tricks". What I want to see are the coding style, attention to details, and of course, if the candidate is c…

> I also ask candidates to code on a realistic problem. It doesn't involve any "fancy" algorithms or "tricks". What I want to see are the coding style, attention to details, and of course, if the candidate is comfortable at coding. Do you do that on the spot or is it a "take home" assignment? I've known many solid programmers (myself included) that could code anything you want, but if you put them in a room, sit ther…

On the spot. I fully understand that many good engineers could freeze up, myself included. That is the reason the coding question is about a realistic problem. No dynamic programming, graph theory, suffix tree, etc. Also, before the coding, I would talk to the candidates about technologies listed in their resumes. It is mostly like a talk between two engineers in a meetup or a conference, not a technical test. My intention is to build an environment that the candidates can feel like real work environment as much as possible. It also helps to bring up the candidates spirits. We are talking about something we like!

As long as the candidates get the logic flow on the solution, can write code down in well-formatted manner, pay attention to corner cases, it doesn't matter if the candidates actually complete the coding, if I think given enough time in a real work environment that the candidate has no problem in doing it.

There are some red flags I pay attention to. For example, readable code is very important to me since we work in a team and we spend more time reading code than actually writing it. Once we had a candidate. he got the coding right, but his code was very hard to read. It reminded me of some obscure C code in the past that one statement was trying to do many things so that it became very convoluted. For me, it is not "smart". It is bad engineering.