Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

People suck at technical interviews (2014)

seldo.com

Post reply on HN
Print view View original

71–80 of 315 posts

Re: People suck at technical interviews (2014)

#71

Post by trumbitta2 »

MrLeftHand wrote: post #15

With one of many job applications I did, I received a small coding exercise before getting to the actual interview. It was about writing a small application in perl (one of my favorite scripting languages) to solve a problem. It was a number converter from arabic to roman and vice versa. Anyway I started by looking up a perl module that solved the whole thing in 3-4 lines of code. What was the answer? Sorry that's no…

I agree with all you are saying so much that some months ago I had to write about it: https://www.linkedin.com/pulse/william-versus-technical-inte...

The TL;DR of my (short, truth be told) blog post is the moral of your story.

Re: People suck at technical interviews (2014)

#72

Post by k__ »

gavanwoolery wrote: post #67
zeemonkee3 wrote: post #52

Earlier quoted context omitted.

Hiring right now is a shitshow of old wives' tales, cargo-culted practices from big name tech companies, shady recruiters, mismatched incentives, interviewers who have no experience or training in interviewing, gimmicky apps trying to somehow gamify technical interviewing and endless whining back and forth on HN and Medium. I'm sure a lot of developers who are currently employed are put off applying elsewhere because…

Nailed it. :) Recruiting is now based on some unproven theories that companies utilize as if they were the 10 commandments. Written by some nontechnical MBAs. We should unite together and form an organization that blacklists companies with incompetent hiring practices. :)

oh do our own hiring company lol ;)

Re: People suck at technical interviews (2014)

#73

Post by [deleted] »

ozim wrote: post #44
PuffinBlue wrote: post #26

There needs to be a bit of a shift in understanding what 'category' of worker a programmer 'is', both by companies and more importantly by (some) individuals themselves. Programming is both technical and artistic. It's a creative endeavour that relies on technical skill to complete. The best analogy to another profession would be to those in the 'technical arts', those like photography, joinery, painting, sculpture,…

There are also different types of programmers. Some will do well with portfolio like web developers. But how you would approach creating portfolio as embedded dev? When you work on proprietary stuff and github repo does not really show that you do well with hardware, because customer might not have time/knowledge to run this stuff to check if it is actually working.

[deleted]

Re: People suck at technical interviews (2014)

#74

Post by peteri »

MrLeftHand wrote: post #54
greggman wrote: post #53

Earlier quoted context omitted.

Me to supposed mechanic: "Can you repair my car?" Mechanic: gets out the yellow pages and calls a real mechanic. Me: ok I'll hire that guy you just called They're not hiring someone to search. They're hiring someone to code. You proved you could search but not that you could code

Me to supposed mechanic: "Can you fix my car?" Mechanic: "Yes, of course!" - he gets up and collects loads of bits and pieces, metal bars and stuff, then starts to hammer away to create a car part. Me: "What the hell are you doing?" Mechanic: "I'm building the part for your car." Me: "Don't you have a spare or something?" Mechanic: "Well I don't, but there are spares I could order." Me: "Then do it man, order one." M…

I'm sure I personally have failed programming tests by doing too much (or not enough) "enterprise" programming in particular stuff that requires things like parsing a CSV file. Do you use a third party library, roll your own, just use string.split(",")? All three are good responses, personally unless the sample data has embedded quotes I've just added comments saying that I'd use a particular library[1] for this normally but I've used string.split as a quick and dirty hack.

At work we've stopped doing take away tests in part for just this reason. We do have a small pair programming test (fix some SOLID code smells in a small 10 line program) and we also don't expect folks to fix all of the problems within that code.

As a pair programming exercise you can almost walk someone through the first problem with the code (there are two big problems[2] plus four minor issues that you could find) and also you can guide the scale of the response they have to the issues (For example I might prompt them and say if you use mocking frameworks in your current job lets use that and you can talk me through how to use it)

We've had pretty good success with this and does seem to avoid some of talks a good talk but can't do developers.

[1] Getting the library onto the interviewers machine might be a really big issue their firewall might block access / maybe I can't send binaries to you due to your AV

[2] Since it's only 10 lines of code the issues are the sort of thing in the "real" world you might ignore but repeated across a code base would be a problem.

Re: People suck at technical interviews (2014)

#75

Post by cm3 »

gavanwoolery wrote: post #34
mruniverse wrote: post #30

Earlier quoted context omitted.

Would you hire a writer with bad grammar?

If they had a killer hook, yes. An editor can always review and fix the grammar. :) A coding analogy: A compiler or debugger can catch bugs. If they can't form a competent sentence, they probably would fail to write a convincing hook. But some margin of error is acceptable.

While true for writing books, I wouldn't consider code that doesn't pass a linter or compiler a useful part of one's portfolio. There is no editor equivalent who will fix your syntactic and semantic errors for you, and getting that right is an important part of your experience with a language/tool.

Re: People suck at technical interviews (2014)

#76

Post by hanginghyena »

Hiring Manager Perspective: Everyone lies, sorry.

As a candidate, I hate technical interviews. For the reasons above. As the poor schmuck asked to make the hiring decision, however, I've learned that I can't live without them.

My technical isn't complicated. A very basic SQL assignment (delivered to an audience which claims to know SQL) that is followed by a few broader database design / data process QA questions. Entire assignment is 100% job relevant (in fact, my SVP asked for a copy of the report it generates when he saw the problem on my whiteboard). I don't care about the details of syntax.

I do care, however, about candidates who produce SQL code which looks like the bastard love child of LISP and Java. About candidates who claim to know a skill but literally cannot write even basic syntax on the whiteboard. Who put "certificates" from Oracle on their bloody resume and break down under super gentle questioning and confess their tutor hasn't taught them JOINS (wtf ?) yet, never mind 5 years of claimed SQL experience at a big company on their resume.

The coding question is most definitely not an exercise in sadism. We validated it with several new hires who were confirmed to be "good at SQL". Average completion time: 2 minutes, generally with trolling about why do we waste our time with easy stuff.

That being said, my rejection rate from a basic coding interview is at least 50%, grading liberally and generally supported by several members of my team shaking their head about a candidate.

I've tried screening resumes, I've tried doing non-coding phone screens. IT DOESN'T WORK. Actually, all it does is eliminate the socially challenged and non-communicative (who actually tend to pass the whiteboard test) in favor of the liars.

And don't get me started about Python. Lest I bring up the Google-Motorola "I LUV Python heart heart heart" guy who didn't understand the difference between a list & dict.

Re: People suck at technical interviews (2014)

#77

Post by MrLeftHand »

trumbitta2 wrote: post #71
MrLeftHand wrote: post #15

With one of many job applications I did, I received a small coding exercise before getting to the actual interview. It was about writing a small application in perl (one of my favorite scripting languages) to solve a problem. It was a number converter from arabic to roman and vice versa. Anyway I started by looking up a perl module that solved the whole thing in 3-4 lines of code. What was the answer? Sorry that's no…

I agree with all you are saying so much that some months ago I had to write about it: https://www.linkedin.com/pulse/william-versus-technical-inte... The TL;DR of my (short, truth be told) blog post is the moral of your story.

Thank god, it's not just me then.

I had an interview where the guy was staring at me like I was interrogated. I had to solve a problem of concatenating to arrays of integers and putting them in ascending order.

I was literally frozen and couldn't think and stood there like an idiot for 5 minutes whilst the guys was just staring at me, not making a sound.

I don't have to tell you I felt destroyed after that. I felt I was a good for nothing idiot and should go shovel dirt then develop software. I still shiver a bit when I think back.

The other things that I hate are the always reoccurring questions. Like what's an array; what's a map; what are the differences; etc...

Come on I've been developing for quite a while now. I've been a sysadmin before that. I'm working in IT for more then 10 years now. Do you really feel the need asking all these things?

Re: People suck at technical interviews (2014)

#78

Post by bbcbasic »

MrLeftHand wrote: post #48
hackinthebochs wrote: post #45

Earlier quoted context omitted.

You're in an interview, you know they're looking for signals to your programming ability. You should offer them the maximally-informative signal without having to be prodded. Sure, knowing to search for an existing solution first is an asset, but that should be more-or-less a given. If you didn't want to assume it was a given you could have just mentioned that in the real world you would simply google for an API or a…

To be honest this was like 4 years ago. I thought it was a good thing to show that I can get things done in way it costs less effort and time. I was wrong, I moved on, so did they. If I would have a similar test today I wouldn't go down the same route, because I know what they would expect. Maybe it was my sysadmin past talking back then. Trying to find a good existing solution for the problem.

Interviewing is about putting on the dance. Juggle some balls on a unicycle etc. It's a rite of passage to what may be a cool job but you have to jump through the hoops like a dolphin.

Re: People suck at technical interviews (2014)

#80

Post by MrLeftHand »

Ma8ee wrote: post #66
Scarblac wrote: post #23

Earlier quoted context omitted.

I disagree. You need to be able to find existing working solutions and use them, sure. But you also need to be able to do this kind of thing yourself if you can't find an existing solution, because that also happens all the time. It's that ability that they were testing. That's perfectly valid. They should however have told you that before the test.

> They should however have told you that before the test. He should have been able to figure that out before the test. It was a test of his problem solving abilities, not his Google-fu.

Goggle-fu - I like that. It should go on my resume.

Still as I wrote on one of the other replies. Yes, you use an API, but you still provide evidence of coding, because you have to write the application, which calls the API.

It was a small piece of code, which took a number from the command line and spat out in the other format. You still have to know everything else to get it to work. Reading input, writing output, etc...

Post reply on HN