Hacker News Reader

Comment by nostrademons | Hacker News Reader

Companies - even ones that use the "false negative is better than false positive" heuristic - would also rather that you ask enough questions and adapt them to the candidates background so that you can rule out "false" anything.

This can work if you really are an expert at something but just got a bad interviewer or bad interview question. The tricky part is that you have to be an expert at something. I wasn't really seeing this from the author's blog post - experts typically wouldn't go for a bunch of blog articles and YouTube videos to learn more than a cursory overview, they'd look for the source of existing open-source libraries and implement a couple projects on their own.

View on HN

There's also something to be said for specifically targeting areas a candidate is not strong with to see how they handle their weakness. If you clam up, get defensive, or try to bullshit your way that's an automatic fail from my perspective. I don't want to spend 8 hrs/day working with any of those 3 personality types.

I've interviewed a lot of people, but I've never seen one that didn't BS just a little bit.

What annoys me is outright lying, like saying on your resume that you worked on some cool-sounding project, but your role was to get coffee for the people doing the actual work. What annoys me more is that when you do the same thing, but with something that doesn't even sound cool, like "converted a database to a CSV file". (I am not making this up. I saw this on someone's resume and thought, "hey, at least they're honest... maybe we can guide them towards being useful". Nope. The candidate had clearly never even typed code into a computer before.)

Interview questions I find relevant:

  * reverse a C string
  * what do you hate the most about your favorite language
  * if you could spend a week trying something new, what would it be
  * what projects are you working on in your own time right now

It is amazing how poorly people do at the middle two. Getting the first one wrong, I can understand -- you have to know how to program, and most companies will hire bad programmers if they can BS a little. The last one, fine, you have a three hour commute and eight kids, and you don't even like programming or making things.

But really... you can't think of anything you hate about your favorite language. Do you ever write any code? Nothing? Not one single, solitary thing? Nothing annoys you in the slightest, tiniest bit? LIES.

And... you can't come up with some BS about what you want to learn? You have no ambition in your life? You care so little about your field that if we gave you money to learn something, you wouldn't do it? You're not curious about "Web stuff"? You have no interested in Scala? Really? Really?

Programmers, I've found, are very, very rare.

The second and third questions are particularly mean in an average interview environment, whereas they are incredibly easy in a relaxed environment.

It's really really hard to think of stuff like that off the bat, sure in an hour long friendly chat I'll probably complain about many things in languages, thus answering your question. But if you straight ask my mind goes blank thinking "Huh ... well I could complain about a lot of stuff, but what is THE thing that bugs me ..." see, ordering by priority is very difficult to do. First one has to decide what their favourite language is (very difficult for programming polyglots) and then what the most annoying thing is.

That's hard.

Same goes for the third question. Well if I have a week to learn something, what on earth should I pick!? There's so many options, how many are really viable for a single week. And what would I like not to learn because I'm learning this. Again, prioritisation is hard here.

I think it all boils down to the fact that those two are BS questions.

> "I think it all boils down to the fact that those two are BS questions."

Useful if your goal is to hire people willing to put up with BS and looking to put their own BS skills to work within your organization.

At a deeper level, the problem is that a person who actually hates features of their favorite language is likely to be miserable using the one their job requires, and a person who views languages as a tool for getting things done (rather than tribally) can't give an honest answer. A better version of the second question might be, "Are there any technical shortcomings within your favorite/current language?"

Likewise many honest answers to the third question are entirely inappropriate within an interview, e.g. "I'd like to try a nudism for a week." A better version is quite possible. For example, "If you could try any other position within our organization for a week, what would it be?" is open ended, relevant to the context, and provides useful feedback about the candidate's career and growth objectives.

Yep, exactly.

I mean, if I had one week to learn _anything_ I'd probably pick sky diving or rally driving. I can learn about the stuff I do every day, well, every day. That one week should be special, something completely out of what I currently know how to do.

It's easy if you've coded enough to know. I hate the fact that in Python, to reverse a string, I have to do slicing:

string[::-1]

In Ruby, I can do string.reverse() so that makes me hate that about Python, well... that and a few other things, but otherwise I love it.

I think he's looking for knowledge enough to know what you would do differently if you could change the language. Otherwise, you're not interviewing a qualified person.

I can tell you plenty of things I would do differently. But I probably couldn't think of them right off the bat.

For example in python I'd change how function references are passed around. Especially in regards to passing them around to children processes.

I agree with your point about the flow being completely different between a normal social setting and an on the spot interview question.

It's amazing how your mind just goes BLANK as soon as the phone rings for the interview.

Out of curiosity, how long does it usually take people to answer the second question? I'm talking about good candidates, not people who don't code.

I'm asking because I've actually seen this question mentioned before, and each time, I spend some time thinking about it (as applied to Python). But it honestly takes me some time to think of problems with Python; not because it's perfect, just because I don't spend every day thinking "hey why can't it do this".

I always miss anonymous functions when coming back to python after a bit of perl or javascript.

If you use multiple languages regularly surely there are some things in each language which you think is better in the other ones?

Anonymous functions in Python are what immediately popped into my mind. I do embedded work and mostly use C, but a lot of the problems with C actually make since when you have less than 1 kB of RAM. I'd prefer to use Lua for building test applications and the like, but I keep going back to Python because the library support is tremendous in comparison.

In any event, I think the question of what problems you have with your favorite language is at least a good conversation starter. It would be nice to know that those kinds of conversations are easy and interesting to a candidate. Although, that isn't necessarily a requirement.

Python is easy. Just complain about the GIL like everyone else does :)

On the other hand GIL is an issue of the CPython interpreter, other interpreters don't necessarily have it, e.g. IronPython.

I use Python mostly, and I was asked this in an interview question (shortly after being asked if I could enumerate the differences between 2.6 and 3, when I said 'quite frankly no, I'm building a real world app and focused entirely on 2.6 at the moment since migrating to 3 isn't an option').

I was actually working closely with Django so ended up listing things I disliked about Django rather than Python itself. I think one of the easier ways to answer would've been with a Javascript/C/ML/Lisp hat on - was chatting to someone at the weekend who was totally against the space-indentation, for example.

Python has it's share of warts. Its automatic memory management is not a modern GC, it involves reference counters that are slow, take up memory and don't play well with copy-on-write semantics of modern virtual memory managers. Its functional programming support is half-hearthed, its implementation is slow, there is no optional static typing, the GIL sucks. And yet it's the best programming language for me - the others are worse.

Don't ask these questions. Okay, ask the first one. Throw away the other three.

I have also interviewed (and hired/not hired) dozens of people at several companies, some small start ups and others massive Fortune 500 companies. I've also judged collegiate and high school interview competitions and been through several corporate hiring and interview training programs.

This is not meant to say anything about me, personally, it's that I have learned that almost no one in start ups or even large companies have any education about hiring. Almost everything that we see routinely practiced is done by folk-wisdom, 'feel' and common group think.

There's only a handful of questions that any interview is intended to determine:

1. Is this person QUALIFIED to do the work (easy to figure out)

2. Will this person DO the work (not as easy to figure out)

3. Will this person actually fit in here (very hard to figure out)

Go back and re-read the interview question above. #1 is a pretty basic programming question. But what are you expecting from #2, #3, and #4? What are 'right' answers? What are 'wrong' answers? Are you trying to get a sense of who the person is?

Why wouldn't a smart person just lie to you? These questions are easy to BS. What am I working on in my spare time? I'm building a neurolinguistic interpreter to decipher real time requirements gathering. Or, whatever else I can conceive of in the two seconds between the time you asked me and the time I spit it out.

Recent college grads are adept at these BS answers by the way. People who have a lot of experience are likely to wonder why you're asking such off topic questions.

The key is that these questions lead to good follow-up questions. "Oh, you don't like memory management in C++? How do you mitigate the downsides?" "Neurolinguistic interpreter? What language did you use? Walk me through the core algorithm."

These always help with your #1 and #3. Nobody ever knows if anyone will do the work, but it's pretty easy to determine whether or not they'd be able and how they'll approach it.

Couldn't agree more with the relevant questions. Especially the first two. Show me you can write some simple code and show me you've pushed a language far enough to get frustrated with it in some non-trivial way.

Of course, after questions like that you still have to figure out whether someone will actually get s* done. That's another matter, but hopefully you can get a feel from their enthusiasm.

> "converted a database to a CSV file".

I just did this a couple of days ago:

http://stackoverflow.com/questions/3710263/how-do-i-create-a...

Maybe you need to put yourself on the other side of that interview.

* What is my favourite programming laguage...?

I don't hate anything about it because, you know, if I found it annoying then it wouldn't be my favourite language anymore. Maybe it's just a personality thing, but I personally don't settle just so I can say iI have a favourite.

Most of the time I would spend answering that question would be taken up by me thinking which language I liked the most and that'd (at the moment) be Lua and only because it's very small and I can feel like I understand most of it. The only thing I find annoying about it is that it's standard library is small which means I have to rely on third-party libraries but that I think is necessary for me to actually like it more than Python which is so huge that it just doesn't feel very fun to write anything in. Many people might say the fact that it doesn't have classes. It does however support OOP via prototyping, I just see it as different, not a disadvantage and it actually fits very nicely with the laguage, possibly better than classes would.

* I'd say write a couple short stories. I have enough unfinished projects, why would I want to waste a week either starting a new one that I won't finish in a week or continue on an old one that I also won't finish in a week.

I wasn't asking... but your first answer is fine, and the first sentence of the second answer is also good.

why would I want to waste a week either starting a new one that I won't finish in a week or continue on an old one that I also won't finish in a week

I would keep this to myself in an interview. The reason you work on your own projects is to structure some learning; sure, there is some finished product that you want, but there is also the experience of making something that's important. You can't learn programming if you don't do it, and the usual 9-5 work environment is 90% distractions and 10% actual programming. So to be the best among programmers, you need to supplement your 9-5 job with something that's 100% programming and 100% you.

The reason I work on my own projects because I enjoy doing them. Why does everything have to be for "structured learning"? I bet you learn and discover more just randomly fiddling around....

Reply on news.ycombinator.com