From the other side of the desk, what I am most afraid of is letting someone with weak coding or technical chops through the door. It destroys teams.
Yes, culture fit is important as is someone who really likes to program and build. You get to that after you've established that the person can code.
I'm not talking about the google "how many jelly beans in a bus" thing either. I'm talking "what is an inner join", "what will this loop output". Basic. Stuff. 9 out of 10 can't do it. Until you establish that you can, the odds say you can not.
As someone hiring, someone about to put my money in your pocket in exchange for the skills you bring, I've got to be sure the ROI is there.
I have never interviewed at google. I was going off of the "how to prepare for google interviews" or "a rehash of my google interview" write ups linked to from HN.
Apologies.
I also would note that some candidates for our positions think "wow, all these guys know to ask are basic MySQL and PHP questions?", which makes me suspect other companies or the coder culture at large are asking the type of questions I derisively referred to.
Why not give everyone a simple test, but give A LOT of people a simple test (which SELECT statement is an inner join...)?
What I always here is that 90% can't write a for-loop or a basic regular expression, but look great on paper, and vice versa.
EDIT: Recruiters are probably too stupid (usually) to be able to either administer or evaluate such tests and so will always be more interested in the "crisper" resume which belongs to some MBA doofus.
Nonsense. I've worked in an organisation where we trained our recruiter to ask simple weed out questions. We would use questions like 'what is an A record?'. The candidate must give a two sentence or less answer right away. The recruiter didn't really know what an A record was, but knew how to ask the question. This saved us so much time because he could filter out tons of bad candidates for us immediately, without even looking at resumes.
As for 'crisper' resumes ... this guy was a Santa Cruz hippie at heart. He knew what was up in the tech industry. If you pick your recruiters for having some personality, it makes your hiring process go so much better too.
PS - This is about Operations hires, there are similar tricks applicable to Engineering hires.
> give A LOT of people a simple test (which SELECT statement is an inner join...)?
That is like asking, how do you implement a reduce function in CouchDB? The answer is easy, and would only take a couple of minutes with Google to answer, but I bet even many top programmers could not answer that question off the top of their head.
If you are looking for someone who writes SQL queries all day long, maybe that is a good question. But if you are writing software that does complex visualizations, occasionally pulling some information from an SQL database, should a recite-from-memory knowledge of SQL really make or break the candidate? INNER JOIN syntax is something you can easily query Google for.
I would disagree. There are questions which if you fail to answer this means your understanding of the field is near zero. For SQL, I would say question about "which kind of joins there are and why" is like this - if you don't understand this, you don't understand relational databases. Which may be OK if the job does not require that, but at least you'll know that about the candidate.
Another thing is that some candidates (or their recruiters?) "inflate" their resumes claiming expert knowledge for things that they heard about in passing or maybe did some trivial task with it. Asking such trivia knowledge allows to find it out very quickly - if one claims to be SQL expert with 5 years of experience and don't know what inner join is - he's probably lying. And this is a bad sign - to start relationship with a lie. I know some people like to do that (especially because of the keyword-match approach) but it's a huge turnoff to start an interview with a supposed expert in the field you need and find out the most work he did in the field was a toy project 10 years ago in college of which he remembers nothing and isn't even interested in doing that.
> For SQL, I would say question about "which kind of joins there are and why" is like this - if you don't understand this, you don't understand relational databases.
This is like saying if you can't write a controller in Ruby on Rails off the top of your head, you do not understand programming. SQL is a vendor-specific technology, and while it is related to relational databases, is not tied to the underlying theory. You can have a relational database that does not use SQL at all.
> if one claims to be SQL expert with 5 years of experience and don't know what inner join is - he's probably lying.
I agree with this. If you want to hire someone who understands the inner nuances of, say, MySQL then it may be a good question. This is quite a bit different to understanding relational databases though – one is theory, one is application.
No, it's not like that at all. RoR is a very specific application, if you can't write a controller then you probably don't know RoR, but it doesn't say you don't know programming in general.
Yes, you can have relational database that doesn't use SQL at all - how many of those are around and popular though? There are some, but not many. What are the chances that you worked with a lot RDBMS, yet never encountered SQL even at the basic level, and it is not immediately evident from your resume, which still says "SQL"? But OK, if that's the situation, you can say "you know, I worked with non-SQL relational databases, and let me tell you about this cool thing I've done that is way better than SQL JOIN can do" - and that might be fine too. Usually though the case is just that people inflate their resumes and think they won't be called out on it. It's very unpleasant because when you interview somebody whose resume looks good, you unconsciously plan that you'd get a great addition to your team - and then you discover he doesn't even know joins... Bummer.
BTW, inner join has nothing to do with MySQL inner nuances - it exists in virtually any SQL implementation out there AFAIK.
I've hear that Interview Street is aiming to solve this problem by letting people show their chops in coding contests (https://www.interviewstreet.com/challenges/) , pass one of those and you're closer to getting into the door of a big company than you were before.
what I am most afraid of is letting someone with weak coding or technical chops through the door. It destroys teams.
Only if you don't fire them. Making hiring mistakes is Ok if you can correct those mistakes. As it stands hiring seems to be a high stakes game of win a job until the next round of layoffs.
Yes, culture fit is important as is someone who really likes to program and build. You get to that after you've established that the person can code.
I'm not talking about the google "how many jelly beans in a bus" thing either. I'm talking "what is an inner join", "what will this loop output". Basic. Stuff. 9 out of 10 can't do it. Until you establish that you can, the odds say you can not.
As someone hiring, someone about to put my money in your pocket in exchange for the skills you bring, I've got to be sure the ROI is there.