Technical interview performance is kind of arbitrary • Hacker News Board

Re: Technical interview performance is kind of arbitrary

#241

Post by kafkaesq » Fri, Feb 19, 2016, 9:43 PM UTC

kelvin0 wrote: post #130

marknutter wrote: post #129

Earlier quoted context omitted.

Yeah, that sounds about right.

Maybe you should tell us which companies haze the potential candidates so we can steer clear of them? At least some hints?

Overly complex algorithm questions (that the interviewer expects an immediate, near-optimal solution to -- even though they were open in the literature for several years before these solutions were found); or reasonably enough questions that just aren't articulated properly (this happens amazingly often); gratuitous brain teasers, or "Carnac the Magnificent"[1] question so any sort; or just the sheer duration of some of these one-way, "prove to me you aren't a liar or an idiot, while I play with my cellphone" sessions (6-8 hours over multiple visits); and then, quite often, dealing with the candidate in a desultory fashion afterwards -- all qualify as borderline hazing, in my book.

[1] https://raganwald.com/2015/05/08/carnac-the-magnificent.html

Re: Technical interview performance is kind of arbitrary

#242

Post by accraze » Sat, Feb 20, 2016, 1:01 AM UTC

WorldMaker wrote: post #83

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 honestly feel like take home tests are "busy work" and just as volatile as any other sort of technical interview for showing actual skills versus a real world environment. 2-4 hours is a lot of time to ask of somebody, regardless of their circumstances. Would you pay a contractor's salary rate for that work? Are these take home tests results worth $100/hour? $40? Every take home test I've encountered I've wished so…

During my last job hunt, I had an 8 hour take-home assignment that could be finished over the course of a week. They paid me $400 to do it and all I did was send a PR with some refactoring on an overgrown controller. I wound up not taking the job, but I remember being really impressed with this process and wish more companies would value a potential new employee's time like that.

Re: Technical interview performance is kind of arbitrary

#243

Post by elliotec » Sat, Feb 20, 2016, 2:16 AM UTC

tiglionabbit wrote: post #165

elliotec wrote: post #159

Earlier quoted context omitted.

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 cre…

Understanding how mergesort is implemented can be useful. I've had interviewers ask me to sort a data set that is too large for a single hard disk to contain. Mergesort is like map/reduce; it can be distributed.

But have you ever had to reimplement merge sort from scratch in any real-world scenario? Of course it's good to understand, but actually doing extra work again seems pointless to me.

Re: Technical interview performance is kind of arbitrary

#244

Post by Dr_tldr » Sat, Feb 20, 2016, 6:38 AM UTC

wott wrote: post #183

jccc wrote: 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? That's what most bosses/salesmen excel at doing everyday.

That doesn't seem to correspond to the attitudes of salesmen vs engineers. I'm not sure what salesmen you're thinking of, but few of the people in sales I've talked to can have an in-depth discussion about how React.createClass vs Class ___ extends React.component will effect "this" context, and how super(props) pattern works in the latter. Furthermore, lots of engineers who work with any given language/framework can't explain it either, and many of them have basically been copy-pasting until stuff worked their whole career.

I've found that most people who have poor communication skills are not good engineers either* and the two might actually be related.

*Except for substack

Re: Technical interview performance is kind of arbitrary

#245

Post by Can_Not » Sat, Feb 20, 2016, 6:48 PM UTC

blackflame7000 wrote: post #156

deangiberson wrote: post #131

Earlier quoted context omitted.

"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.

To be fair, they might be on to something. I've programmed my whole life in OO and recently started looking into FP. I can see the veterans thinking that OO is a fad after seeing things like BeanFactoryFactoryFactory (I personally do not program in Java and have never encountered the use case for a "Factory", and as such do not know what the use case is). After that, what value do you get to adding the functions to structs? I personally see the value, but I also see the value in not doing that. I would recommend teaching them OO while yourself should study FP and criticisms of OO. After them, it may be easier to evaluate which is better for your use case. It sounds like the vets have already cornered you out of OO, but you also definitely don't want to force the wrong tool onto a project just because it's the tool you understand best.

Re: Technical interview performance is kind of arbitrary

#246

Post by angelbob » Mon, Feb 22, 2016, 2:43 AM UTC

jccc wrote: post #193

angelbob wrote: post #166

Earlier quoted context omitted.

> 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 th…

I've hired, at several places, more than a few people who were fooling me with their sales skills. More often I work at a place where we do multiple interviews -- some "technical" in the sense that it's talking about tech, and some "technical" in the specific sense of asking a programming question with a verifiable answer (i.e. run the program, see if it works.)

Frequently people do well on the technical-not-actually-coding portions and very badly on the please-write-code portions. That is, if we didn't ask the specific coding questions, we'd be hiring people they disqualify.

At those places we less frequently hire people that just can't code -- though I've been around for that too, usually when we look at a resume and say, "oh, we don't need a coding test for him, he's been writing important code for years in a way where he couldn't hide lack of ability."

It would appear that a resume is a poor way to verify that.