Comment by overshard | Hacker News Reader

Comment by overshard | Hacker News Reader

Technical Interviews should be a sit down and code session for an hour or two with someone on the team (it can even be a remote screen-share session). Everyone I've ever hired/not hired I've done this with and it is quickly obvious if they can do the job. I just give them an issue from an open source project I have and a clone of the master branch and ask them to solve it, they can use Google or whatever resources they want. With me looking at their process I can easily tell if they are qualified for the job.

I just hired someone for a job who's first response was to copy and paste the error code into Google and view a stack overflow post with a similar problem. From there he took what the response on stack overflow said and crafted a solid solution to the issue. It took him about an hour and I saw that he had to Google a few functions (Python language) but he showed he knew the resources he needed and the basics to coding solutions to problems.

I don't care if you know how to create a linked list in C on a piece of paper or why we have round manhole covers instead of square, this isn't useful in the real world, I want to see if you can solve a real problem and the method you go about it.

This is definitely a really useful component to the interview, but I don't think it should be the only component. A lot of our jobs are doing straightforward things: "implement spec X, where X is pretty close to what's been done before." But occasionally we'll encounter a problem that requires us to think up an algorithm. It might be similar to what's out there, but it's not going to be a googleable solution. It's these cases that define a good engineer.

I'd liken our jobs to those of pilots. Most of the time, anyone can fly the plane: just punch in the flight plan to autopilot, and press 'A/P engage'. However, when a pilot is near cumulonimbus clouds with an engine failure, he is forced to step up to the plate. This is what pilots are paid for: to handle the crazy emergency situations that can arise when you're in the air. This, too, is what good engineers are paid for: handling the difficult problems that occasionally arise during development. If you're not hiring for this, you're hiring code monkeys.

I agree this shouldn't be the only component overall, you need to see if he fits into your team but I feel like if he can solve a problem in a timely manner that I deem moderately difficult using google and some experience based tricks with me looking over their shoulder then I can judge if they are a good engineer. Everyone I've hired using this method has never been fired for incompetence or issues with their skill. My issue is judging peoples personality and team fit. I still have yet to find a solid solution to this and asking Microsoft interview questions or how linked lists in C work isn't going to do that either. People are often overly nice/fit for the first few weeks/months but then go downhill from there as their true personalities show. I see no way to judge this other than calling contacts/past employers and even that doesn't always work.

This is pretty much exactly how I got hired.

In my case, I had to show design capabilities in addition to code and being creative didn't mean just applying hacks found on the internet. But my boss had to actually see if I can get through with building the project using a combination of existing knowledge and the ability to find solutions.

My challenge was to build a discussion forum from scratch with user registration and a reasonably attractive UI. So that's PHP + Photoshop + CSS/HTML/JS

That sounds like an awfully big project for a job interview. If someone asked me to do this, I would probably install phpbb.

To be fair this was after the initial screener interview and I did have a couple of hours to get it done. And we're not talking all the features (certainly not of phpBB) or anything.

3 Tables "posts", "replies", "users" (replies was a closure table), topics index, topic view page, a form page for registration and one for the profile page. JS form validation and a simple layout via CSS and HTML5.

It was more of a Twitter-lite (a very poor man's Twitter-lite)

This. Technical interviews are important but their purpose should not be to check whether you know a particular function/API whatever. Their purpose should be to take a real world problem and show the interview how you resolved it. Sure, remembering specific details of a technical subject is always handy but just because I don't remember the function that does task 'x' in language 'y', doesn't mean that I cannot use it.

Reply on news.ycombinator.com