How I (almost) got an internship at Google(ecarmi.org) |
How I (almost) got an internship at Google(ecarmi.org) |
Then a really cool opportunity came, and I accepted that offer because you can't just sit in a rotting pool for two months.
A friend of mine stayed in the rotting pool and was told at the beginning of summer that no one at Google wanted him.
This was 2009-2010. I hope Google changed their ways.
First time, I was told a manager would call me to explain me which team I was being matched with. I received the call to tell me I had an offer... two days after the deadline set by the University. And it is not like this deadline is unknown to employers.
Second time, again, I received an offer. This time, I had to call, one week before the deadline, after two weeks of hearing nothing from them. Two students in my class were in the same situation, one had to send a hate mail to finally get a reply. The other one got one only after the deadline.
To be honest, this really isn't the best way to go about it. Makes you fell like crap as an intern. I interned at fairly large and well known tech companies in the past (Facebook, heading to Bloomberg this Summer) and got offers from many more (Amazon, Microsoft, Zynga, EA, etc.) and my worst experiences were always with Google. As a freshman, Google looked like the dream internship, the company to aim for. Four internships later, it is now pretty low on my list.
Definitely not impressed by their recruitment process. And this all happened in the past 12 months.
Sadly the recruiter who knows this deadline and the managers who have "Look for suitable interns" as one of very many todo list items are not one and the same.
I did an internship at Microsoft and now work at Google; the MS internship hiring process (in 2002) was awesome and very, very fast. Your comments about Google's relative standing are definitely interesting and clearly not an anomaly, the issue is fixing them =)
Compared to MS, Qualcomm, AMZN (I'm headed to MS) Google's process is pretty weird.
I'll give MS recruiters the benefit of the doubt, as all other candidates I met had positive experiences. They just matched me with the wrong team, and it seems like the recruiter overlooked some paperwork related to scheduling and traveling.
Other sloppy recruitment experiences include some with trading companies such as Jane Street; one such company rejected me by saying "we're only looking for juniors" after calling me on-site. The only truly positive experience I've had is with a YC startup (I was eventually rejected).
Nothing, however, compares with how bureaucratic and mismanaged Google was. I went through a smooth but lengthy recruitment process the first time, and was given a rejection letter after 1 month. Second time, I had to do some juggling between 4 recruiters before getting the paperwork settled for my first interview. I was out of the country and clearly told a recruiter that I should be reached by a different phone number, after which I was asked "are you legally allowed to work in the United States?" even though I'd already answered that in the paperwork they had given me, and I had clearly stated I was studying in the US. Then, I end up scheduling interviews for 2am and 3am my time. The 3am interviewer is not informed about the change in phone number, and is a no-show.
A couple of interviews and 6 weeks later, I get no response. So I end up sending a follow-up mail to my recruiter, who, the very next day, tells me I've been put in the rotting pool. I get no more feedback after 3 weeks, and send another mail. Apparently, I'm still in this rotting pool. I'm guessing this is just equivalent to getting a rejection.
As for interview questions, Google isn't any different from other large companies. I found it odd that they still require candidates to code in Google Docs rather than some Etherpad equivalent that formats code.
So far, searching for an internship has been just a ridiculous time sink. I'd probably get more experience by hacking on my own projects, but that's no guarantee of job safety.
Renaud, I think you should give them another shot if you're still up for it.
As for binary search, I wouldn't necessarily be able to bang it out in two hours in C, but I'd easily be able to bang it out in that time for any language I use regularly. And with sufficient testing I'd take a good stab at converting to C.
Though I agree sometimes it can be a coin toss. Once I was asked to write some code that would take dates as inputs and do something with them, it was supposed to take two hours and run on a bunch of test cases they gave you. I spent much more than two hours on it, nailed all the edge cases and boundary conditions that I could think of (basically nuked it from orbit) and turned in something which ran on their test cases and also a much longer list of much more challenging test cases. I got that job.
I missed one where they wanted something written by TDD. Unfortunately, I only know how to design something that works, I don't know how to fake a bad design that organically grows into a workable design. As above I nuked all the boundary conditions I could think of, but didn't get that job.
(Probably wouldn't have been happy there, my experience is that people who do TDD or automated unit testing have way too much faith in those forms of testing, and they neglect other forms of testing, so their actual net amount of testing is well below my standards. Things like: every single programmer I've ever worked with who claims that automated testing is sufficient has always produced code that when they claim they've finished the task it fails the eyeball test. E.g. you run their code and within 10-30 seconds of looking at the result you can spot something wrong with it.)
So in under a week, I went from initial interview, to official offer. This is by _no_ means typical (and my recruiter even commented on how unbelievably fast it was), but it _does_ happen.
A while ago, I used to conduct job interviews like this. Sort this, insert that, search for the other. I still feel sorry for some of the candidates I did this to. That process was the largest single mistake I made when hiring people. I should instead have asked for the code of some projects they had been working on recently and maybe discussed a few more creative things with them.
In fact, if I could ask a candidate just one question, it would be "what projects are you working on in your spare time?"
For example, when I was reading your writeup as a former interviewer (lots and lots of college candidates for MSFT -- I was a dev manager and did both my own hiring and was flown to colleges for those "interview days" for several years), I was far more worried that you had trouble finding the bug in binary search than that you got it wrong. Everyone gets problems wrong the first time unless they have just implemented them recently. Superior candidates are good at rapidly trying good normal and edge cases, hammering out a good solution, and writing inspired code when given hints at how to improve their solutions.
I really don't like the idea of solving contrived puzzles, but I'll never make the mistake of keeping my thought process hidden again.
I don't claim any responsibility for their success, though! The University of Chicago undergrads are a hard-working bunch. Much more so than when I was an undergrad :-)
Why are Google so popular anyway? I genuinely don't get it and would love to know from someone who has specific knowledge. Do they pay better than everyone else? Work on more interesting problems? Better perks, work environment, more status? I can understand it from the perspective of someone who joined years ago, when you got stock options and didn't have to do a full circus performance in order to get in, but not any longer.
The experience would have to be twice as good as the alternatives before I willingly submitted to this kind of process. A long process of interviews like the ones I have heard about hints at more pain and no autonomy once you actually join.
For an _internship_? If you're turning down other offers for the _chance_ to work at Google, you're selling yourself short and not getting full market value.
In many years of programming I don't remember having to write a binary search in C, by hand, in a text document, without being able to compile and test. Or having to dictate a Python program over the phone to someone.
I certainly do not remember ever having to solve stuff like:"One train leaves Los Angeles at 15mph heading for New York. Another train leaves from New York at 20mph heading for Los Angeles on the same track. If a bird, flying at 25mph, leaves from Los Angeles at the same time as the train and flies back and forth between the two trains until they collide, how far will the bird have traveled?" NEVER.
I had to implement & modify algorithms from scientific papers, I had to work with complicated lockless versions of data structures, but I probably couldn't write the binary tree search in C over the phone. If that's that Google uses to hire then I will never work at Google.
EDIT: Alright, got a angry and used the 'fuck' a little too much.
Personally I was in between jobs recently, so I sent Google my resume using their online application site. After about a month, Google still didn't get back to me -- meanwhile I managed to interview at 6 different places (all the way) and found a new job.
"I heard nothing for a month and a half" is the key problem I think. It's going to be very hard for any full time employees that are any good to stay off the market that long, they'd have to apply to Google before quitting their last job.
As for interns, I am not overly surprised since you applied in December. At my school we had the hiring booms in October/November and then again in March/April (that's when we had the 2 engineering job fairs), so anytime between that people weren't really finding a new internship (unless it was on their own).
One last thing, what exactly is a Google spreadsheet beta candidate form? Is that the same one as the optional Google "survey" where you had to rank your skills (1-5 or 1-10 was it)?
- Every step of the process involved a new person. Overall, I had to be handed off through 4 different people, each one wanting a bit more information or a filled out form, until I was scheduled for the phone interviews. This was especially confusing when I had a recruiter assigned to me, and I was being emailed by both her and someone with whom she worked with at the same point in the process.
- The first interviewer was apparently a fill-in for the intended one, which is unfortunate, because he and I were a complete mismatch. He seemed to be a C/C++ guy and I have more high-level language experience, and we ended up doing what I would consider advanced bit manipulation / number theory. (The second interview was much more reasonable, and it is my own fault if I did not pass it.)
- The amount of time time that it took from the "Hi, we would like you to apply online" email to the you are not "a close enough match" email was over a month, which is much too long for simple back-to-back phone interviews. Waiting for their responses was the most frustrating and nerve-racking part of the process. I am glad at least the OP had quick responses.
Should I go through the process again, I would strongly consider asking them to expedite it in one way or another.
On a more optimistic note, I do feel like the interviews do help highlight weaknesses in your programming skills and resume presentation skills.
Google sure makes a lot of noise about how they are hiring and competing for talent, but continue to turn away good people for unknown reasons.
It's important to know that googlers are encouraged internally to do interviews (for extra cookie points? I don't know :P), they're assigned randomly to candidates for most of the process, so they're not a part of the whole process, just a piece of the machinery. No one oversees the interviews to make sure questions are not repeated and that there's a logical thread from one to the other (especially the onsite interviews), and you might not even be asked the questions that are actually relevant for the position they're considering you for, when you're in the latter stages of the process.
The stories I've heard from the hiring trenches are all pretty much the same. It's a great company, but their hiring processes are very weird.
First, I have had almost no actual CS lessons in my university, because it was more focused on general engineering and IT management than on code writing.
However, I've done quite a bit of code in various open source projects and I've touched quite many technologies...
I went through the sets of interviews, and I really seemed to work quite well, even if many design-patterns where unknown to me (I didn't know their names). But the last one wasn't the best one.
Therefore, I got the mail telling me that they got no positions for me, which I understood and accepted easily (I had another engagement at the time).
However, I dared to ask "why?". Was it my technical skills, my personal skills, my logic skills or the way I answered the process, the cause of my rejection?
They refused to even discuss about it, which is not even reaching the minimum of politeness I expect from a company. When they asked if they could keep my Resume, I told them to go away...
This recruitment process does not seem enough respectful for me and gave me a very bad opinion of the company.
And, sure, I don't take it personally :D I just don't like this behavior.
I didn't ask for details, just a general idea.
I've done a fair deal of job interviews, in order to get this kind of feedback and improve my skills; and Google was the only one that was that little polite on the feedback (even MS was nicer)
They didn't even say: "we can't tell you because of general policy or because of fear of lawsuit"...
But the fact that it's only "[s]ome companies" that do that still suggests that it's rude and unprofessional behavior.
If you're just a sophomore, you shouldn't feel bad about not getting an internship at Google.
Another reason not to "feel bad" about it is that AFAIK the people interviewing you just take notes, and then other people review those notes to decide whether or not to take you. So the people you interviewed with weren't even the ones that made the decision.
Perhaps for the C program, you should have done something simpler than a binary search, at least to begin with. The way you described it, they didn't require you to do a binary search.
I think it tests specific knowledge of an algorithm more-so than anything else.
The problem I'm sure, was being rusty at C, not the algorithm implementation. I make all kinds of silly mistakes on the whiteboard if it's with a language I haven't used for a while.
I got my call, was inquired about my projects and current offers by HR and then got a rejection letter next week. After I inquired, it turned out that my low GPA [ 7.03/10.0 ] was the cause. They want academically bright freshers with shining GPAs and with strong CS101 skills.
But, I believe there is a method to the madness. They have so many qualified applicants that they would rather err on the side of caution. They would rather reduce the false-positives even if the number of false-negatives grows. They can afford this luxury. They want the best and they can afford rejecting good candidates.
My favorite way of thinking about this was from Steve Yegge's blog post about the interview process : "Because of the inherently flawed nature of the interviewing process, it's highly likely that someone on the loop will be unimpressed with you, even if you are Alan Turing. Especially if you're Alan Turing, in fact, since it means you obviously don't know C++"
They employ a lot of people that can write code on boards, and can certainly churn it out at high velocity. But when you start looking at the actual code... it's bad. When I first looked at the chrome code, the layer they dumped on top of webkit to make it out-of-process, the only thing I could think of was "this looks like something a kid fresh out of college would cobble up together". Same thing with most of their projects - lack of clear design, hacks, hard to maintain, lack of standards, no portability. The projects that get visibility end up getting better (more competent programmers assigned to them), the rest lingers in crappiness mode.
They're not all like that, obviously. They have very smart and very competent people there. But the general low quality of their code, the lack of polish in their products, it clearly shows the consequences of hiring people based on how fast they can dump code on a whiteboard.
given two full hours and any high-level language
(including pseudocode) only 10 percent of professional
programmers implemented binary search correctly,
according to Jon Bently.
I'm not particularly intelligent and I'm not in the top 10% -- but I could implement an in-place quick-sort in C in 10 minutes that my interviewer could run with only a minor fix (forgot a semi-colon), and I even described the parallel version with OpenMP (although there I got the syntax slightly wrong). This was for my interview at Adobe, when I got hired by them a couple of years ago; went on to other things since then.
By that logic that should place me in the top 1 percent ... but so are my ~ 100 friends that are also software developers from my city, and statistically speaking, something smells like shit in those statistics thrown around.
Maybe binary search, when discovered, used to be a hard to understand problem, but now it is taught from high-school. And sure there are lots of idiots out there, but many of those idiots also believe they are in the top 10%, because some statistic told them so.
So cut the crap and build stuff. Only by that metric you can prove yourself.
-- EDIT --
I'm not referring or addressing the article's author directly. I'm also not saying that you SHOULD be able to implement binary search, or quick-sort or whatever metric du-jour -- in interview conditions. I get it that you may be stressed by eyes watching you, or that you may be bitten by edge-cases other people haven't noticed for years.
I'm referring more to these metrics flowing around -- like, if you read HN you're in the top 5%, if you read this stupid blog you're in the top X%, if you can implement binary search ... etc, etc...
We are software developers, mathematicians, computer scientists -- surely we understand selection bias and should be able to recognize bullshit, even if it doesn't appeal to our ego.
This was quite a contrast to my Facebook experience, where I had a contract signed after I think 3 weeks. :)
I'm really quite surprised that binary search is considered difficult, have you ever tried to implement quick sort? I can write AVLs with less bugs than quick sort.
I think an important factor in these interviews is the emphasis on talent in software development. Don't get me wrong - I don't deny its importance, it's more that I question the nature of the beast. To me talent is instinct, a feel for what you're doing, and the 'right' type of thinking for the thing. It's pretty obvious when somebody has it (or doesn't), and I think obvious whether you have it too if you're honest with yourself about it.
Tech interviews emphatically do not test for this. Nor do they, I believe, test for smartness; I think once you hit a certain level of intelligence the rest is far more preparation and experience (and yes I'm getting Malcolm Gladwell on your ass) - so all a failed interview indicates is (assuming you are an at least moderately talented, moderately intelligent candidate) one or more of the following:-
* Lack of preparation (knowing the stuff, and practicing the stuff)
* Poor/incorrectly focused preparation
* Lack of confidence
* Bad luck - e.g. haven't looked at binary search for x years they ask about it, or what Steve Yegge termed the 'interview anti-loop'[1] - basically the guy interviewing you just doesn't like you and that's that.
The biggest problem with these things is that people (and I'm kind of talking to myself here more than anyone) take these things personally and put it down to some idea of talent that you might just lack. Fuck that.
The problem is that - and I'm risking repeating a well-known cliche here - hiring good people is extremely hard, and a false positive is way more damaging than a false negative. It is right, IMHO, that (good) companies probe algos, os fundamentals, etc. as this stuff matters; however failing an interview emphatically does not mean you suck.
[1]:http://steve-yegge.blogspot.com/2008/03/get-that-job-at-goog...
I cannot emphasize enough how much more awesome it makes your company look when you have a streamlined recruiting process!
Similarly, I wouldn't even bother to bring in a candidate who transcribed his interviews elsewhere.
"Similarly, I wouldn't even bother to bring in a candidate who transcribed his interviews elsewhere." - Well there are gazillion blogs and books written on technical interview questions including by ex google, msoft and apple employees. So is it really that bad that a sophomore student decided to blog about it for the benefit of fellow students.
> I got an internship with The New York Times
> the following week.
In any case, well done. Technical interviews are hit-and-miss at any stage in your career, although I have to say that a coder worth his salt should be able to code up a binary search in no time at all. Even a college sophomore.
I feel like the energy I could spend doing a side project is probably better spent getting these last two features in, or fixing those lingering bugs, or getting that automation solid, etc....
It seems really odd to actually penalize someone who leaves it all on the floor. It's like a basketball player saying, "If you really want to see my skills, come to the park. The NBA is just my paycheck." -- is that the guy you want on your team? The guy who will tell his next employer, "Company XYZ paid the bills, but my real cool work is this GitHub project I did on the side".
If, however, a programmer's day job is maintaining a legacy system that doesn't involve a lot of creativity then there's a greater likelihood that they have untapped passion which will express itself in a side project... and ultimately with them finding a new job that does require creativity.
Judging someone based on their side projects is the wrong approach -- judge them on their creativity and passion. Some are fortunate to have a job which gives them the ability to be creative and passionate during work hours. Others aren't as fortunate and need to express their creativity and passion outside of work hours. The big red flag to not hire is when someone has neither creativity nor passion inside or outside of work hours.
PS: All of the great developers I have worked with are both old (50+) and have a life outside of code. Spend some time around people with Genius IQ's and 30+ years of experience and you rethink just how important passion really is.
Now, for Google that might not be the case — they certainly should be trying to find the top talent they can get their hands on. All the more reason to ask about the extra projects, GitHub account, code samples etc. But just as many people, when they're students, don't appreciate or value the extra work you talk about, they won't do it when they work for Google and are tasked with hiring others. If all you spent time studying were algorithms and C, you won't appreciate the value of open-source contributions and feverishly learning new languages as much as someone else. And you won't hire based on that.
And yes, that's disappointing.
I think a question talking about the Django templating system when the interviewee mentions they use Django is fair game, though; and questions that revolve around 'here's a real world problem I want to do with a string, can you write a quick algorithm' are ok, but then I do things like the Greplin programming challenge for fun and I'm not even an engineer =(
I agree, but it was the only good one I could find in the article.
My feeling is that if they are claiming to be "programmers" but seem uncomfortable with basic algorithms/data structures, there could be a problem...no?
I've been a Googler for a little less than a year and so far I absolutely love it. Compensation is good, the perks are fantastic, the caliber of people I work with is stellar, the work is challenging and interesting, and the culture and processes are the best I've seen.
> A long process of interviews like the ones I have heard about hints at more pain and no autonomy once you actually join.
I believe it's the opposite. You have to run the gauntlet to get in because once you do, you won't be closely monitored and you'll be given a lot of autonomy. The hiring process is stringent to try to reduce the number of internal gates you need once you get in.
Because at this point in your career, you have no degree, no experience, and no income? He's a sophomore in college, not someone with 30 years of industry experience.
In my experience, though, I would make someone with 30 years of industry experience answer the same questions. Because I've asked people like that those questions and they have absolutely no fucking idea. The number of people that can start with a blank file and start writing a computer program is probably somewhere around 5% of programmers.
What?! There's no way this is true... is there?
The second year (last year), my experience was similar, except this time I bugged my recruiter pretty much every other week until I had a host interview (got TWO of them cancelled on me but finally the third one actually happened) and I got the job.
Despite the terrible process, it is an absolutely amazing place to work. Everything you've heard is true: the food is amazing, the work atmosphere is amazing, the people are geniuses. Also, the compensation is absolutely absurd for undergraduate interns (last year it was $69,600/yr prorated to $1338/wk, and this year they bumped it up to $80,000/yr prorated to $1538/wk, with a $3500 lump sum relocation stipend on top of that. I know it's even higher for grad interns but I don't know the exact numbers).
Despite the admittedly awful process (easily the worst I've been through), it was absolutely worth it to me and I'd recommend anyone stick with it and hope you get lucky like I did. It really does come down to luck whether or not you get a host interview once you've passed your two technical interviews.
They did, however, ask a whole bunch of conceptual questions, but I don't think this is all that surprising.
I'm going to try to find a way to feed it back to HR, because it really is much easier to think about code when what you're doing looks like code.
That was my first interview, and they said at first it was going to be a coding interview. My next interview was a design interview. We talked at length about designing a simple web application, which got increasingly sophisticated as we progressed. But my interviewer did ask me to write code to demonstrate what I had in mind from time to time and I had to code up some small methods and classes to show him. No puzzles. No CS theory or abstract problems. Just what I would do if I were building a real world application.
Oh, and they asked about what projects I had worked on both interviews.
I have been an interviewer in the place where I work currently, and I always asked candidates to write code. Some guys here ask puzzles, but I don't like that. Puzzles (like how to find you who's lying in an island on people or something) don't really show anything in an interview situation. But a short programming problem, demonstrating the ability to identify and use a well known data structure or algorithm, or to use good sense and understanding to design a solution to a problem does go a long way to show that a candidate can actually code and get stuff done. I've seen lots of bad candidates impress us with their knowledge of tech buzzwords, past projects in their CV and even talking about design patterns, but fail miserably when asked specific questions or writing even the simplest amount of code.
But if someone asks me about trains and birds, I would seriously reconsider working there
Agreed. It doesn't have to be perfect. They should be able to talk and explain it. Whiteboard design sessions are my favorite A good marker and a whiteboard are indispensable for me, and I use it in interviews as well. I present the situation as here is a typical problem we are solving, let's solve this together.
I also give plenty of chances to let the candidate tell me or teach me something they are excited about.
On the following: 1) Applications and Services: this is Google's term for the software that is directly visible to end users. People who focus on applications and services typically work on improving our capabilities in a variety of areas that span the range from new features to increasing performance and efficiency at Google scale. They will be tasked with devising and building new approaches to Google's problems, and exploring their effectiveness.
2) Systems: People who have a systems focus are oriented towards behind-the-scenes software and systems, often building them from underlying components and services. Systems work spans from platforms (hardware, OS, networking) to infrastructure (shared services such as storage, cluster management) and everything in between.
3) Sys-admin: Our system administrators keep all of Google's systems running, and help deploy new ones. They deal with issues involving single machines to those involving huge numbers. They work with native Linux environments, and Google extensions and services.
4) Verification and Test: Our test teams helps make our systems resilient and reliable - we put a lot of effort into this. Building world class applications at world class scales doesn’t happen by accident. It takes insight, innovation, and precision to verify our systems perform as expected.
I don't think it was optional, though perhaps I'm mistaken and filled it out assuming it was required.
The HN post led to this perennially popular article from Joel on Software:
http://googleresearch.blogspot.com/2006/06/extra-extra-read-...
Jeff Atwood references a good example: http://www.codinghorror.com/blog/2007/02/why-cant-programmer...
The sad truth is that many people who program professionally simply cannot so basic programming tasks. If anything, I think top 10% might be overestimating how many can do it - I suspect 10% might have some kind of idea of how binary search would work, but most of them will fail with edge cases etc.
The lack of corporate housing is kind of unfortunate, but the internship pay is enough that it isn't something I'm terribly concerned about.
Why is that an issue? I know from experience that Amazon and Microsoft have the problem pretty much solved. Just do what they do.
As a side note, if there's any chance of you being in the bay area this summer (Mtn. View specifically), I'd love to grab lunch with a fellow HNer. I'll be interning at Google starting early May and know a sum total of 0 people out in the area. If you're interested and possibly going to be around, my e-mail is on my profile page.
(Joel puts it well in this article: http://www.joelonsoftware.com/items/2005/01/27.html )
I think part of the problem is that CS programs simply aren't structured for large projects. It would be far more realistic to say on day one, "get in groups of three and hand in a functioning program by the end of the term", but that structure just doesn't work for school. Or, if it would, then nobody has the brass to try it.
Mad scientist with lots of cool toys? Definitely.
Stick him in a suit and make him give presentations to the board? Definitely not.
Woz should be the guy in the basement in the lab coat who occasionally makes the lights in the building flicker with some bitchin' tesla coils... the guy that the CTO goes to in order to find out what is going to be important in tech trends, and who occasionally coughs up a wonderful invention that revolutionises everyone's life.
I think it is important to note that Woz is still listed as an Apple employee as an engineer
The Woz type and the Bill Gates type are different by miles.
I wish it didn't play games in recruitment. I had already accepted an internship at Facebook by the time Google called. In the end I'm glad I did, because I really enjoyed Facebook and am going back full time.
First time, first phone screen, not that bad. Second interview, they push on bash, and I said, essentially, that I wouldn't use bash, I'd use python. So much for that process.
Second time, same phone screen, same self evaluate, same damn questions on the first part. This time, of course, I know the answers to the tricky questions, because they asked me the same damn questions the last time.
This time though, the process has taken nearly a month for about three calls, including the one actual phone screen. Nothing more for a couple weeks, then the "sorry, not gonna happen, and were not going to tell you why".
I'm a little confused. They call me, looking for something that I'm not a good fit for, again. I do better this time. I'd really like to know if it's me, or if their ai is just that whacked.
The reasoning appears to be that you're either good enough or you're not, and that it doesn't matter who interviews you for that to be true. However, the difficulty was really variable: interviewer 1 asked lots and lots of algorithms questions which I wasn't doing well on, caused him to become obviously annoyed with me. 2 seemed fairly ambivalent throughout. 3 really worked with me to try and get answers out of me (even though I was incredibly nervous).
I don't see why phone screens are not with prospective teams; they're the ones that will have to deal with you and have the best idea of what skills they need. Maybe they're trying to avoid people building up little fiefdoms? I generally came out feeling the way you do (and the way the OP does). It seems random, and for a company that (rightly) prides itself on the quality of its data and making data-led decisions, it makes it sting doubly.
The problem is that they do the exact same thing for people that they reach out to.
HR goes through resumes and reaches out to people. Engineering does technical interviews. I my experience, I have seen very low correlation between "HR liked this candidate" and "candidate was good."
A few keywords in your resume will get you reached out to by the vast majority of recruiters. Those same keywords do nothing for the guy asking you to solve a problem on a whiteboard and finding your answer wanting.
Not arguing with you as that gets many good people during interviews. But I'm going to provide some anecdotal evidence to the contrary ...
In binary search this problem comes from the length of an array, which is either odd or even, and then you're doing a division by 2, which should trigger alarms in your head all over. And just as when you were taught in your first CS class (either high-school or college) you pick 2 simple examples for both cases, and test with pen and paper (tools provided during any interview).
When I did interviews from the employer's side -- the people not doing this were either totally unprepared, failing most other questions, or brilliant (and lazy) people that considered the problem too easy to bother checking the implementation.
Surely, put into context it can provide a valuable filter, but it's not saying much about the top X% of the talent pool, which my post was about.
I was once given an interview project where they wanted to see how I did with their current code structure. They gave me this really horrible template of data that could never be used in the real world or for anything other than this project. I decided to restructure the template so I could make a useable application for it. After turning it in they were astonished that I reformatted it to look exactly like their production data and code.
The problem was that they didn't like that I didn't use certain basic function like require_once, autoloading or something else which i forget (this was in php). Instead I used c style programming in php which ends up being faster. They chastised me for not using the builtin php functions because they assumed they must be better and didn't hire me. The company (well whoever the recruiter worked for) sayed in the email that I just wasn't the right fit because I wasn't up to the skill level of the guy giving me the test and they needed someone "that good" because they were way behind on their deadline. I sent them an email back basically saying that they're retarded (in a MUCH nicer way of course) and showed them some benchmark results I made comparing the different ways of doing it (which showed my methods as being much more efficient).
Faster in performance, or faster to develop and maintain?
Most PHP apps I've come across have little need for CPU optimization. Not using built-in functions in those situations is likely to have no practical benefit except making it harder for other PHP devs to work with the code.
if ( ! defined('SOMEINCLUDE')) require('file.php');
then defining SOMEINCLUDE in file.php.
Only saves 3% if i remember correctly but when you're including a hundred includes it adds up and when your site is spread across 30+ load balanced web servers every bit counts. As far as it being easier to maintain, it's easier to debug this way if something goes wrong.
However for things where you've gotta build some huge function (or any function really that's more than a line or 2) to replace a built in for such a small gain in performance I would agree with you.
If you run their code and within 10-30 seconds of looking at the result you can spot something wrong with it, then besides being poor coders, they're also poor testers. Since presumably the result that you're looking for is what they should be testing.
A while back I worked on a web app with developers who used TDD exclusively. In the entire time they worked there they never viewed the web app locally, but they had complete confidence in their changes and almost never broke anything. It was a bit extreme, but it worked for them and they were very effective.
I take the point about them being poor coders and testers, though one of them was very highly regarded as a programmer (he presented well). The thing with testing is that you cannot predict everything in advance. Even with full code coverage you cannot cover every path through the code, and as soon as your code escapes into userland all sorts of whacky interactions can take place. The last, and best defence is to actually run the code and see what it does. your eye will pick up problems you never would have otherwise predicted.
With respect to the excellence of your TDD colleagues, perhaps they would have never broken it if they had less overwhelming confidence and more "well, it doesn't hurt to check"? That minor nitpick aside, I congratulate them. I think as programmers we should aspire/strive to be better than average, to be good at our art, and it sounds like they found a way that worked for them and fulfilled that goal.
I'll bite. Yeah. I want that guy. I want that guy because he's got energy and enthusiasm to burn, and I'm confident I can give him a place to use it.. Additionally, we'd love to see more open source projects come out of what we're working on..
I feel like the energy I could spend doing a side project is probably better spent getting these last two features in, or fixing those lingering bugs, or getting that automation solid, etc....
Awesome, if this was how it works, but it's not. The people that get itchy enough to bang out these projects on the side need to keep building stuff. Great stuff. I burn out on bug fixes, and automation.. and sometimes I feel like working on something different, so I bang on a new cache library for Django, or write something a little tangential to what we're currently iterating on. In my case, I'm really stoked with all of the problems we have that need doing, so none of my 'side-projects' are totally sideways to the values of our company... but lots of them aren't exactly high priorities :)
This actually might the crux of the difference. While we have an open moonlighting policy the people that work here are a lot more likely to use the extra coding energy on something directly related to the priorities we have. There's no shortage of things to do. And t's not like you spend three straight weeks fixing bugs -- there's plenty of diversity in things that we need to in the business -- and I suspect most companies I'd want to work at are similar.
And again, I'm not necessarily against side projects. But it seems like an odd way to measure a potential employees passion to the job. It does seem like a great way to measure their passion for side projects, but we generally aren't hiring people explicitly to work on side projects. It seems like a much better way to measure their job passion is to see what they actually did at their job -- look at what they shipped.
If they shipped a crap product, but had a cool side project, what is that really saying? If anything its telling you to NOT hire them, but to get them interested in your product on the side! :-)
My current employer has profit sharing, I love the work we do and there's always more interesting work to do than a 10 hour day allows. So now the projects I do at home are my pet projects for work that excite me but aren't part of my core tasks.
The question is "Is this someone passionate about programming?" and involvement with open source projects are a great way to find that out, but it's not the only way.
Some one who shows initiative and puts in extra work for a company they're excited about show's just as much passion for programming.
It's that programmer who puts in their hour and a half of coding in between reddit posts and forgets about it when 5 oclock hits that you want to stay away from.
My point is the lead dev for Angry Birds ends up at your desk and it seems almost pompous to say, "Where's your GitHub app?" This person broke his neck to ship, upgrade, and maintain a product that you can look at (the NBA game), yet a lot of people still seem to be saying, "w/o seeing your code (your practice sessions) I need the GitHub repo" (I need to watch you play at the park).
I guess as an employer this works to my advantage if more startups require GitHub accounts, since I can pick off proven talent that doesn't have this requirement. So yeah... it's a great idea! :-)
EDIT: And I should add that I was responding to someone who said that if you aren't working on something in your spare time that this is a red flag. So according to that poster, simply having great code from my "daytime" job isn't sufficient. Kobe Bryant NBA footage isn't sufficient. If he doesn't also play pickup games there must be a problem?!