Hacker News Reader

Comment by tocomment | Hacker News Reader

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 they never asked me any technical details about it. They then proceeded to ask me what happens when you add a '4'+4 in javascript. My mind kind of blanked. At which point they assumed I couldn't program :-( Even though I had created this web app they all loved.

They sent me home after one 30 minute interview even though I had to take two days off of work and fly across the country. A very dismal experience it was.

View on HN

In a similar vein, my favourite interview (and actually the one that scored me my first real gig) was explaining existing code in some of the products that I would be working on if I got the position.

That way I had not seen the code before, but at the same time this was for real, "live" code. It was awesome, as not only did I get to show I could understand code, but more importantly it showed that I was able to dive into an already existing project and work through what I needed to.

It also gave me a little insight into how those projects were organised, in a way.

I think in all, I was given 5 snippets, all getting 'harder'. The way it worked was the first snippet was a complete function, comments included. That allowed me to infer things from the comments, as well as function and parameter names. By the end, they were showing code with the function name changed and all comments removed, but the rest was still there.

I thought that whole process was quite interesting and having lead some interviews myself since then, I always ensure that I try that with the hires we are looking at...

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 informative than actually working with someone.

> and the Javascript question was to test whether you've ever done anything numerical in JS.

It's a lousy test, then. The fact that someone can't tell you the answer to that question, off the top of their head under interview conditions, might mean they are a newbie claiming to know languages they really don't. However, it could also just mean that they have experience with several dynamically typed languages but, since they would never write something daft like '4'+4 in real code, they would have to look up which interpretation JS happens to use.

In case anyone is wondering, in JavaScript, the answer is 44. However, in Perl, it is 8. In PHP, it is also 8. In Python, it is a type error without an explicit cast. You get the idea.

Of course it's a bad test.

Google says they only hire people above the mean skill level of a Google engineer, so you need to look better than an average Googler to get in.

http://googleresearch.blogspot.com/2006/03/hiring-lake-wobeg...

> since they would never write something daft like '4'+4

The question is an artificial simplification. They don't care about that literal construct. They care if you know what the + operator does on strings vs. numbers and what the implicit type conversion rules of the language are (and what the resulting 'gotcha' is). No one is worried about you literally writing '4'+4. They are worried about you writing foo + bar and being sloppy about the types of your variables.

> They are worried about you writing foo + bar and being sloppy about the types of your variables.

In that case, perhaps a better question would determine whether the candidate understood that in a dynamically typed language, variables don't have types, values do...

I realize you are trying to make some sort of "Aha! You don't know what you're talking about!" point here, but in practice taking advantage of the fact that you can store multiple types of values in the same variable in a dynamic language is almost always a bad idea and subjects you to exactly the sort of bugs that this question is bringing to light. So, enjoy your sense of superiority because I made a slight mis-statement. The point that the question is phrased for simplicity as a concrete example, in order to see if you are aware of certain general facts, stands.

Apologies if the similar wording came across as some sort of personal jibe. I was merely trying to point out that even if the question was a simplification as you said, it was still a poor way to assess a candidate, because it's still getting hung up on a technicality rather than determining whether the candidate understands the underlying issue.

I guess I read too much into your comment. Apologies in my part for overreacting.

As to the technical issue, I don't think this has anything to do with dynamic vs. static typing. It would be theoretically possible to define operator+ in C++ to produce the same behavior as Javascript.

> I don't think this has anything to do with dynamic vs. static typing.

Well, yes and no.

In a sense, the real problem here is the overloaded + operator, which has two quite different meanings, numerical addition and string concatenation, depending on context. This is particularly a problem in a dynamically typed language, though, because you don't know in advance what that context is and therefore which overload will be chosen.

> It would be theoretically possible to define operator+ in C++ to produce the same behavior as Javascript.

In C++, you can't actually change the behaviour in this particular case, because you can only define overloaded operators where at least one operand has a user-defined type.

So in fact, just to make things simple, the C++ answer on most modern computers will be 56. Go figure. :-)

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.

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 many people)

I interviewed a candidate who had an impressive college project involving compilers on his resume. Almost any question I asked him about it was answered with "I don't know, the other guy did it." Even asking him "What did you work on?" resulted in an "I don't remember."

Maybe you should have asked who the other guy was and interviewed him.

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 in managment.

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

I still don't think a person could intelligently discuss his solution if it was handed to him like that.

And not that I'd advocate hiring a "cheater", But if all the tools he uses to "cheat" eg google, stackoverflow will also be available to him during actual work, it's always possible he could still get the work done.

i think you failed the whole interviewing process when you agreed to complete and did complete the _unpaid_ "homework".

Reply on news.ycombinator.com