> Sergey [Brin] nodded his agreement, then asked about my six months in Siberia, casually switching to Russian to see how much I had picked up. Finally, he leaned forward and fired his best shot, what he came to call "the hard question". "I'm going to give you five minutes," he announced. "When I come back, I want you to explain to me something complicated that I don't already know. He then rolled out of the room toward the snack area.
I looked at Cindy. "He's curious about everything," she said. "You can talk about a hobby, something technical, whatever you want. Just make sure that it's something you understand very well"...
I went to the whiteboard and furiously drew circles and squares and unleashed arrows like Legolas. I was nervous, but not very. Sergey bounced on a ball and asked questions that required me to make things up on the spot...
Later I found out that Sergey did this with everyone he interviewed. An hour wasted with an unqualified candidate wasn't a total loss if he gained insight into something new.
From "I'm Feeling Lucky: The Confessions of Google Employee Number 59" by Douglas Edwards, page 11
Personally I think that most of these questions are horrible and as somebody being interviewed, I'd be a little bit annoyed at a company trying to make me jump through hoops. I'm sure there are tons of developers that can sort arrays like there is no tomorrow, but sometimes I would like to work with people that can create software. People that write tests, are able to set up a sane build process, keep the clutter to a minimum and make nice APIs.
What I'm looking for in coders is passion. Ask people for their personal projects and let them talk about it! Ask for a Github account upfront and look at weather they commit fixes to other projects and show initiative, look at their personal toy projects, look at weather or not they're able to work with complete strangers and improve software just because they like doing it.
Some people might not have a Github account. But honestly, most of the people I like working with have one.
I've stopped a couple interviews mid-process when it became evident that the interviewer was going to focus on this sort of crap. Their shock is its own reward.
The interview process provides very little information to both parties about each other. Both of you have to make a decision on what you know. It is entirely possible that walking away from such an interview would, in retrospect, be a mistake.
However, it's a hot market. For every company that sucks at interviews, there's a company that's good at it. Why put up with it? Why waste hours?
Once upon a time, I was interviewing at two companies. The first, was a great interview..the seasoned and experienced found/CEO got me excited and interested and really made me feel that they were equally excited and interested in having me on board. They asked smart questions, they had obviously spent time reading my blog and looking at my public profile.
At the other company, it was painful...for both of us. I felt..like a chore that had to be done...going through a checklist of increasingly irrelevant questions. You could challenge the question, but the answer was "we want to see how you work through problems"....which is silly...are you so lazy that you can't come up with relevant questions that do that? Plenty of other people have.
My point is that, like everything else, some companies are clearly 10x better at interviewing/hiring than others. And, again like everything else, the shitty companies/interviewers have no clue how shitty they are.
Surely that might say something about the individuals and companies as a whole? So, again, why put up with it?
Bravo! Part of the reason HR is so broken is that few will speak up when exposed to this kind of crap. Thus the crap peddlers (I used to be one of the trick question kind, merely because I was emulating others) are left with the idea that they're following "best practices" or some such nonsense.
Job candidates should be turning down companies as often as companies should be declining to make offers.
If you're not ready to walk away, then you're desperate and you're going to end up in a crappy job.
I regret letting my last interview for a web development job turn into a "reverse this list"-type questions. An hour completely wasted, and lowered my opinion of the company I was interviewing with (formerly high)
I think each company has their own recruitment process, and it depends on the kind of job openings they have. I recently had my Google interview which was totally algorithmic. Despite of a number of projects and research papers in my resume, the interviewer did not ask me any questions pertaining to those projects.
But at the same time no way did it appear to me that the interviewer was not looking for passion in me. The questions that were asked from me probed whether I had the ability to respond to tricky problems, the ability to understand the intricacy of the problem and ability to respond.
At the same time the interviewer also tried to gauge my general skills, whether I would be able to contribute in a project or not. So I feel everybody has their own method of hiring. Particularly college graduates may not have github accounts to show that they have contributed to different projects. Sometimes I feel it is the only way to judge freshers in the sense they may not have a lot of projects to show, but they do have what it takes.
Getting responses about those projects isn't interesting. By now all the answers you will give will essentially be committed to rote memory, so the interviewer won't be seeing any actual thinking going on. It's also hard to gauge which contributions came from you, or from the people around you, based on your responses and your resume -- most people are happy to steal credit if they think it won't actually hurt anybody.
> I'm sure there are tons of developers that can sort arrays like there is no tomorrow, but sometimes I would like to work with people that can create software.
Companies should search for developers that can do both.
Questions are always displayed in full, whether you are logged in or not. There is a separate page for each question where you can comment, see the answer, etc. which requires login. But, you are right! We need to improve the UX ;)
These things jump out at me. I didn't actually leave the site in a huff. I noticed the /accounts/ URL structure on your login page, and if I'm not mistaken, you're building the site on django? I had a good poke around, and I really like what you're trying to achieve. I look forward to seeing the site evolve as you iron out the kinks.
Thank you collypops! Just to let you know, this site is built in just 2 months with a team of 3 people, and launched just 3 days ago. So, i guess we have a lot of kinks to iron out and figure out the right direction ;)
I can't believe how many people here are averse to the idea of demonstrating coding ability in an interview.
Github doesn't reflect the amount of time that somebody put into writing that code. It doesn't reflect how long it took for them to iron out bugs from a poor initial implementation.
My experience is that correctness AND speed both count when a person is developing software. I'm sure you guys have worked with people who are really sharp, can talk the talk, but just flail around helplessly in an IDE, constantly solicit help from their neighbors, and burn up milestones doing very little. I want to make sure that those people don't get hired.
I also want to know that these people are going to use idioms that aren't wasteful, that their naming conventions are sane, that they are being thoughtful and methodical about their implementation rather than grafting edge cases onto edge cases.
Github doesn't even reflect whether somebody actually wrote that code themselves or merely copied it and tweaked some identifiers. It's not that I want to be this suspicious, but I find I have to now that the salaries have attracted so many losers and con artists to the industry.
This too. It's much too easy to lift source from somewhere else, or hire somebody from India to write code on your behalf.
I generally don't trust anything that I can't verify firsthand. Stated experience gets a guy in the door for the interview, but their performance during the interview is all that matters to me.
Some time ago I was surprised that there isn't (or I couldn't find one) any site with recruitment questions based on Stack Overflow engine. Anyway, the best one I found was http://www.careercup.com/page with a lots of questions from various companies.
...where the following advice is given: "But your strategy while answering this question should not be directly this answer. Generally in the interview you should start with the worst answer and then improve upon it.
If you directly give this answer then the interviewer would know that you had done this question before and may not give credit to you for the answer."
Hmm....
Sound advice, but there's something morally off, IMO.
Do you hate the player or the game, I wonder?
Or the online site that helps the player play the game?
In my opinion answering like that gives interviewer idea that u have thorough knowledge and know all the solutions in the incremental level of improvement (complexity and space usage etc).
The grammar alone on this site is just dreadful, who the heck says "Codes"? And then career v. careers in the same slogan two different places. If I saw this on a resume, it would be placed straight into the circular file.
More often than not, very basic things get over someone when he/she is writing a lot of backend and frontend code in a team of 3 people for just 2 months. Btw, thanks for bringing this to attention :) Will try to look for all such errors and remove them asap! Thanks ;)
The grammar alone on this site is just dreadful, who the heck says "Codes"?
I see this quite a bit in the scientific community, and find it somewhat annoying. Of course, the people who use that form are the same who insist that "data" must always be used as a plural.
what i feel personally is that many companies nowadays are asking these type of questions and this site has covered many topics well and is moderated. But this can be further improved by increasing user interaction.
Its a good thing I stopped working for other people, because I feel sorry for anyone who tries to interview me with these prejudiced questions:
Q: What's your github id?
A: Tell you what, tell me yours and I'll criticize your project and language choices. I'm sure I can find multiple reasons to conclude you're incompetent. Oh, look at this, every language you've checked code in is a scripting language. Do you realize you're not even really a programmer?[0]
Google: "There are N houses in a row. Each house can be painted in either Red, Green or Blue color. The cost of coloring each house in each of the colors is different. Find the color of each house such that no two adjacent house have the same color and the total cost of coloring all the houses is minimum."[1]
Answer: "Explain to me the mechanism by which YB2C3O is superconducting, including the role that electron spin plays in the theory. Describe the meissner effect. Posit a theoretical superconducting compound that would exhibit a more consistent meissner effect.[2]
I'm sure its not obvious but the error that both these questions make is that they presume the interviewers worldview, or put another way, they are extremely narrow-minded. Neither of them actually tests whether you'd be good at the job, but instead tests whether your worldview is similar to the interviewers.
The first one presumes that open source is a sign of being a good programmer. This is a complete nonsequitor. While I'm working on an open source project right now, my github account is empty because in my 20 year career, all my contributions to open source projects were prior to github. There are programmers who actually write code at work and then spend their hobby time doing other things. For me it was building robots, and while I did write some interesting code for that, it wasn't really appropriate to open source (too specific to the hardware) and the very idea that I should have open sourced it is a bigoted one. You could just as easily claim that a very active github account is evidence that the employee was slacking off on the last job, working on projects unrelated to what the company was doing (assuming of course they weren't hired to do open source.)
The brain teaser is exactly the same thing. It isn't testing whether the candidate can solve problems, its testing whether the candidate is good at brain teasers. These are very different skills.
Two much better questions:
1. Tell me about something you've done that was difficult, challenging, or highly technical, outside of work, as a hobby or as a personal project.
2. [Google] As you know, Google is a search engine. We spider the web continuously. That produces a lot of data, of course. Give me a high level overview of how you'd architect one component of that process- any component will due, spiders, or analyzers, or the overall workflow.
In both of these cases there are many followup questions. For the first question, you ask them details about their side project, with an eye to learning as much about the project as you can yourself. What this teaches you is whether they can communicate ideas or technology well. And of course, with passion. For the second question you can drill down, using real world examples of issues a search engine has run into, to see how they would resolve them. You should (probably MUST) also give them some of the solutions that you've come up with as part of solving these problems, to get them thinking with enough context to discuss it. The main thing you're looking for here is the ability to generate ideas, even if they are stupid.
In both of these examples you're turning the interview from a confrontational situation where some half assed programmer sits in judgement of the candidate to one where both parties engage in a dialog. In both examples, you've got some opportunity to reveal info about the company, in the hopes of attracting the candidate to want to work there.
I've been on enough interviews that I recognized, in retrospect, were simply exercises in stroking the interviewers ego to know this happens far too often.[3] You may be interviewing for a job they wanted, for instance. Or their friend might also be interviewing. Or they may just be a jerk and insecure and looking for the ego boost.
Or maybe they are sincere but they simply don't know enough about the world to know that people's minds are organized differently... brain teasers are vastly easier for some people than for others, and there's no correlation with productivity as an engineer. Same thing with interest or activity in open source.
[0] I'm not actually bigoted against programers who use scripting languages, but the interest in github is founded on the prejudice that interest in open source means you're a good programmer.
[2] anyone with a college degree should be able to answer this, as well as anybody under pressure tries to work out the colored houses question. I'd give them more context and clues than typically are given in these brainteaser situations.
[3] In fact, I'd say its the case the majority of the time. Though it varies widely by company. Generally, if one person who interviews you at a company is doing this, most of them will be as well, not sure why that is.
That's why I prefer asking for any links to their work online, whether it's on github or elsewhere. And I suspect most others who ask for a Github ID would not mind a sourceforge link or whatnot.
I ask for this before the interview, not as a way to filter out people with no work available online, but mainly to gauge their coding abilities so that I know how much I need to cover that in the actual interview. If someone happens to have a great Github profile, it just means that I can skip most of the coding part of the interview and focus on other things.
My employer (not posting the name since I don't care to be directly googleable) de facto forbids open source work. In order to share essentially any code we're supposed to pre-clear it with our internal "open source council" by filing a jira ticket and asking permission. Each time, every time. They meet monthly, so you potentially wait up to 30 days. Of course the company realizes they only own our work that is directly related to our employment or that is done with company property. On the other hand, they have two in house attorneys, one of whom was a partner at a very high end law firm. So in practical terms, in any legal pissing match I'd lose, no matter the merits of the case, since I can't afford my own $600/hour IP attorney.
Which is a long way of explaining that many people have very high barriers to sharing code. So the only code I really have to share is written for my employer, and I obviously won't be sharing that. I think that having shared code on github is a poor estimator for quality of an employee.
It's a misconception that every employer who asks for a Github ID as part of a job application process is looking to use it as a way to screen applicants. For us, it's just a shortcut to see whether someone can code. If they don't have a Github (or bitbucket, or technical blog, or whatever else is Googleable or that a candidate wants to provide us), it just means that I have to spend extra time during the phone screen or in-person interview on their coding abilities.
[1] Dynamic Programming is a large part of computer science underlying efficient programming. It's not just academic trivia or irrelevant a company building software at the largest scale ever attempted.
I looked at Cindy. "He's curious about everything," she said. "You can talk about a hobby, something technical, whatever you want. Just make sure that it's something you understand very well"...
I went to the whiteboard and furiously drew circles and squares and unleashed arrows like Legolas. I was nervous, but not very. Sergey bounced on a ball and asked questions that required me to make things up on the spot...
Later I found out that Sergey did this with everyone he interviewed. An hour wasted with an unqualified candidate wasn't a total loss if he gained insight into something new.
From "I'm Feeling Lucky: The Confessions of Google Employee Number 59" by Douglas Edwards, page 11