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 =)

Why is that an issue? I know from experience that Amazon and Microsoft have the problem pretty much solved. Just do what they do.

Compared to MS, Qualcomm, AMZN (I'm headed to MS) Google's process is pretty weird.

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.

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.

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.

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.)

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.

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.

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.