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

How Effective are Technical Interviews?

jeanhsu.com

Post reply on HN
Print view View original

81–90 of 114 posts

Re: How Effective are Technical Interviews?

#81

Post by evilduck »

shortlived wrote: post #26
tastybites wrote: post #21

We hire people based on enthusiasm, general intelligence (you can usually tell after a few minutes) and a low level of demonstrated proficiency - we'll ask them to explain a code sample they wrote, or ask for a verbal description of how to solve a problem. We choose the person we like best, and if they don't work out after 2 weeks we fire them. Hot seat quizzing produces way too many false negatives. We are not googl…

Are there laws that allow/prevent the 2 week trial period for a business?

Most US states are at-will employment, allowing anyone to be fired at any time, for no reason at all.

http://en.wikipedia.org/wiki/At-will_employment

Fun fact, many anti-discrimination laws in the US don't apply to companies with less than 15 employees.

Re: How Effective are Technical Interviews?

#82

Post by joe_the_user »

lsb wrote: post #19
tocomment wrote: post #4

I like interviews where you explain existing code you've written. I do well with those. I also do well if they give me a homework problem before the interview. True story. Interview at Google. They had me make this AJAX web application as homework before the interview. Three people told me they LOVED my solution and thought it was beautiful. I figured I was a shoe-in for the job at that point. But at the interview th…

It sounds like the AJAX web app was designed to test your sense of taste and your ability to get things done, and the Javascript question was to test whether you've ever done anything numerical in JS. ('4'+4)-4 is 40, whereas (4+4)-4 is 4. There are a lot of people who glue a few things together in Javascript and PHP and call it a day, and their filter against those is imperfect. Interviews as a whole are less inform…

The rudest thing about what GP describes is that the interviewers had demanded quite a bit of his time via the AJAX app but weren't willing to investment an equivalent amount of time in determining his skills - especially when they had the AJAX app they could have asked questions about.

Re: How Effective are Technical Interviews?

#83

Post by mattmanser »

bconway wrote: post #78
kenjackson wrote: post #70

Earlier quoted context omitted.

The problem with this, IMO, is that it is really soft. Some research has shown we make up our minds within the first 10s (or so) of an interview if we like the person. And the rest of the interview justifies this decision. I have to have some "minimum" requirement questions. These are questions that you have to get right . No matter how good I feel about you, I still will no hire you if you get these questions wrong.…

Share them, it might make someone feel smart today. ;)

fizzbuzz is an oft cited example of a simple test:

Write a program that prints the numbers from 1 to 100. But for multiples of three print “Fizz” instead of the number and for the multiples of five print “Buzz”. For numbers which are multiples of both three and five print “FizzBuzz”.

http://imranontech.com/2007/01/24/using-fizzbuzz-to-find-dev...

Re: How Effective are Technical Interviews?

#84

Post by al05 »

strlen wrote: post #64
kscaldef wrote: post #54

Earlier quoted context omitted.

In my experience, people start complaining that an interview is "theory-heavy" at about the point that you expect them to know when and how to use a binary tree. Binary trees are not hard-core CS theory, they are freshman Intro to Data Structures. They are a very basic tool (almost) every programmer should be familiar with. Moreover, when I ask candidates questions about data structures and algorithms, while it's nic…

> In my experience, people start complaining that an interview is "theory-heavy" at about the point that you expect them to know when and how to use a binary tree. Binary trees are not hard-core CS theory, they are freshman Intro to Data Structures. The other part about binary trees is by their very nature they involve pointers and recursion. Understanding pointers and recursion is the difference between being able t…

I don't understand how someone can not understand pointers and recursion. There are very intuitive, you have to probably have to study bits of math which is more unintuitive to get on computer science in the first place.

Re: How Effective are Technical Interviews?

#85

Post by yogsototh »

jswinghammer wrote: post #12
tomh- wrote: post #11

Earlier quoted context omitted.

What is the question I may ask?

Implement: itoa

I've done it on my computer. Clearly it works, but without a computer at hand, I am pretty sure I would have made many errors. For example initialize strsize to 1 instead of 0 (in order to add the '\0' at the end of the string).

I believe it is far harder than one could imagine, even more if you are nervous during the interview.

Why not just a binary search. I remember an article claiming 90% of engineer can't write it without bug.

I personnaly asked simply to write a function foo(c,string) (in any language) such that if the string contain the character c, then it returns true. And even with a question as simple as that I had more error I could have imagined.

char itoa(int i) { int strsize; int tmp; char res; int j;

    if (i==0) return "0";

    // allocate the right size
    strsize=0;
    if (i0?i:-i;
    while (tmp > 0) {
        strsize++;
        tmp /= 10;
    }
    res=(char *)malloc(strsize);

    // write the values
    j=strsize;
    res[j]='\0';
    if (i

Re: How Effective are Technical Interviews?

#86

Post by dalore »

tocomment wrote: post #69
eli wrote: post #23

Earlier quoted context omitted.

I once tried giving out a homework problem to interviewees and a surprising number of people flat-out cheated! I absolutely hate "trivia" questions, but I feel like I have to ask people to actually write code during an interview even though it's unrealistic and a bit unfair. (I also think that if a candidate is flying to the interview, the employer should cover the airfare... but maybe that's why I don't get to hire…

How did people cheat? It seems like if you ask them to create or solve something that hasn't been done before they'd have to figure it out. Of course they could get someone to write the code for them but A. You can catch that by reviewing the code with them and asking questions and B. If they can get someone to write good code for them And then review that code to make sure it's good you might want to put that person…

They could have posted the question onto a site like stackoverflow.

Re: How Effective are Technical Interviews?

#87

Post by Someone »

varjag wrote: post #65
fendale wrote: post #42

Earlier quoted context omitted.

Good point, I actually thought of doing that and then dismissed it. Maybe the best perfoming way would be to use the remainder as the index to an array (suggested in another comment)?

It's C we talking about, just add the remainder to 0x30 and you get your character.

[pedantic]: you should use '0', not 0x30.

1. The standard library C function atoi may be named 'ASCII to integer', but it should convert a numerical string in the platform's encoding to integer. For symmetry, itoa should convert an integer to a platform encoded numeric string, not to an ASCII numerical string.

2. Not all computers use ASCII for C strings. Because of that, '0' need not equal 0x30. For example, in EBCDIC, one has '0' == 0xF0.

Utterly pedantic: IIRC, the C standard guarantees that '0' through '9' are contiguous and in order. If you know better, or aren't sure, use "0123456789"[i] to convert a 0...9 value to the corresponding char.

Re: How Effective are Technical Interviews?

#88

Post by kemayo »

btilly wrote: post #75
patio11 wrote: post #20

I put tech interviews down fifty/fifty to "We don't know any better way of doing this" and "The unavoidable reality is that if a position is advertised openly then 98% of candidates are screamingly inappropriate for it and after applying a few filters to the resume we've gotten that to a more manageable 90% or so for interviews." Happily, there is a simple opt out mechanism. There are two ways to get into any company…

I consider the existence of door #2 a red flag. If decision makers who are likely not technical themselves are making that kind of decision about technical hires, odds are that they are going to make some very bad hires that I won't like living with. That's not to say that there aren't a lot of companies where your advice works. But I'd prefer to work for the companies where it doesn't.

Even assuming that you're not a bad hire, it can still be a bad idea to allow this. If the decision makers can go over the heads of the people who are in charge of technical hiring and force them to take on someone they haven't vetted then that's just going to cause resentment.

I don't mind skipping HR so much. But skipping the technical-vetting step is bad. If your hiring-committee doesn't make good decisions, that's a separate problem that you should solve without just starting to ignore them.

Re: How Effective are Technical Interviews?

#89

Post by dalore »

shortlived wrote: post #26
tastybites wrote: post #21

We hire people based on enthusiasm, general intelligence (you can usually tell after a few minutes) and a low level of demonstrated proficiency - we'll ask them to explain a code sample they wrote, or ask for a verbal description of how to solve a problem. We choose the person we like best, and if they don't work out after 2 weeks we fire them. Hot seat quizzing produces way too many false negatives. We are not googl…

Are there laws that allow/prevent the 2 week trial period for a business?

Even if it's not allowed, you could always hire the person on a contract basis for the trial period. Then offer a full employment agreement after that.

Re: How Effective are Technical Interviews?

#90

Post by kenjackson »

bconway wrote: post #78
kenjackson wrote: post #70

Earlier quoted context omitted.

The problem with this, IMO, is that it is really soft. Some research has shown we make up our minds within the first 10s (or so) of an interview if we like the person. And the rest of the interview justifies this decision. I have to have some "minimum" requirement questions. These are questions that you have to get right . No matter how good I feel about you, I still will no hire you if you get these questions wrong.…

Share them, it might make someone feel smart today. ;)

Sure. They really are super simple. FizzBuzz is simple, but my min bar is a question that no one should miss. Even someone with anxiety should get them right. In theory I could see a good dev getting FizzBuzz wrong or getting flustered. Since I use this as an absolute "no hire" bar it has to be pretty low.

Count the number of occurrances of the letter 'a' in a string. And I'm upfront that this isn't meant to be a trick question having to do with locales or some odd corner of the Unicode world. If there's something funny about the question, let me know, I might learn something, is what I'd tell them.

I'd say 1 in 10 struggle with this question. The other 9 kick it out in 1 minutes. Very little time is lost in the interview.

Another example is to code the nth Fib number with recursion. I give them the recurrence relationship, in case they don't know it, and write some examples. I'm not throwing out Fib and asking for a solution, and secretly ready to pounce and say, "There's a closed form solution!" or what happens on integer overflow or anything. I want them to convert the recurrence relation to code as a recursive function. But I don't mind hearing valid concerns along the way, although really its just a mininmum bar test.

This eliminates about 15% who often don't get it working at all. (I'm really winging these numbers... i should have kept better track of this).

Doing well on these questions means nothing. It just gets you a ticket to the rest of the interview. But not being able to do them is an indication that I don't think I can listen to the rest of what you have to say (for a dev role) and be convinced that you can do the job -- no matter how versed you seem to be with the latest buzzwords.

Post reply on HN