Comment by radicalbyte | Hacker News Reader

Comment by radicalbyte | Hacker News Reader

Parent Full thread

We tailor the interview to the applicant: so someone coming from (GOOD!) Uni should be able to verbally explain a sorting algorithm. We don't ask them to code - it will take too long and a discussion is much more valuable (and almost impossible to pass by memorizing a couple of algorithms).

Heck, I passed a harder version of the test (including the theory, I'm a senior/lead/old-fart so I was expected to implement everything on top of the discussions) and I left formal education at 17 :)

They don't have to implement a working version, just give a good outline and be able to answer questions about it :)

For experienced people we go further, and do ask for some coding.

You've got 5 years experience in SQL? Then solve this simple problem which requires using JOINs and aggregates.

You're a javascript expert? Great, then demonstrate that you know the syntax and know what a closure is.

Java expert with a focus on patterns? Then you should be able to implement one of: Singleton/Factory/Command.

We get more people who have 10 years of experience with C# are are self proclaimed experts, but who don't know the difference between the heap and the stack then we do CS students applying for the wrong job.. but that's for a different thread :)

Here's my problem with using quicksort at interview:

A developer who writes an implementation of the quicksort algorithm as part of their job should usually be removed from their post for incompetence.

The interview process should be a two-way procedure which also allows the candidate to understand what is expected of them in a role (and make their decision about the job accordingly). If regurgitating quicksort is expected, then this is a fair test: otherwise, this is not how you should be presenting the job.

Ah, that seems pretty reasonable. I think my biggest problem is that when I'm interviewing I'll try to answer too quickly before thinking through a problem completely.

But I love discussions too, and if it's something I'm comfortable with, I could keep talking about the topic for as long as the interviewer wants.

I think there's value in recognizing when you don't know the answer to something. I had an interviewer ask me the difference between call and apply in JavaScript, at the time I wasn't sure, so I started to answer him... I explain that I knew you could use both to set the context in which the function was called, but eventually I just said: I'm not sure. And the interviewer gladly explained it to me.

In my case I got an internship where they gave me a 24 hour project to demonstrate my skills. I found that way less stressful than any interview I've ever had. And after the internship the company was so happy that they offered me a full time job!

Oh, that's exactly what I want to hear: everyone has gaps in their knowledge and it takes guts to admit it. As long as you can see that, and know where to gain the knowledge, than that won't be a problem.

Unless that knowledge is something vital and general. I.e. like not knowing what HTML is.

In the future I want to use internships to find younger engineers - it lets you get to know people a bit, and keeps new ideas flowing through the company.

Reply on news.ycombinator.com