Google's a bit ambivalent about Python. On one hand, you have a contingent of programmers who don't consider python a "real" programming language. These types seem to be mostly on the search team. On the other hand, there are plenty of pockets within the company where Python is used pretty heavily. The most notable is arguably the App Engine team.

I found this out during my interviews at Google; after I solved a problem using Python the interviewer gave me another and said "this time use a real language." Ouch.

That's the sort of thing that would make me strongly consider ending the interview, at least if I was going to be working directly for the interviewer. No need to waste more of their or my time than necessary, and I really wouldn't like working in that kind of insulting environment. And from a probably-immature perspective, the feel of power from being the guy saying "sorry, I'm not interested anymore" instead of hoping they call you back is nice.

Or, if I was really annoyed: bust out some Common Lisp for the next problem, then leave.

Seriously, he said the next question was string manipulation or something:

    #include <stdio.h>
    char f[8] = {70, 117, 99, 107, 32, 121, 111, 117};
    int main(){
      int u; for(u=0; u<8; u++) { printf("%c", f[u]); }
      printf(".\n");
    }

Thank them for their time and walk out.

You should definitely mention things like this to your recruiter. Sometimes interviewers misunderstand or make a mistake, and that shouldn't be counted against you.

Obviously it's rational for this event to make you uninterested in working for Google, but if that's not the case, it helps to escalate your concerns or complaints.

That's pretty bad. Interviewing should also be about selling the candidate on the company. If they get an offer you want them to accept. If they don't then you don't want them bad mouthing you to other potential candidates.

If an interviewer insulted me or my language choice in an interview it would definitely make me wonder how they would treat me as a coworker.

The entire Google interview process is slanted that way. They keep making you feel privileged for being able to take that interview, and almost never try to make you sell the company to you.

This has changed a lot for the better in recent years.

Also, a lot of geniuses are socially inept. I doubt you said everything right in your interview either. It helps to smile and keep going when one person in ten shows a flaw.

When I get stuff like that, I'm generally like "oh wait I'll try a real company". Not that C is not lower level for example. I love C. But since the interviewers are actual devs and managers at Google, it shows quite a bit.

I'm guessing it'd be nice starting writing in a lesser known language or even just go for some old arch object code (like 68k object code which is pretty simple to write, and the chance is high that the interviewer will be clueless and find this a bad joke - and yes i can write that as i did a lot of it 15years ago, its straight forward)

Then Google writes you as an "do not employ" person of course and say that you do not fit (while you declined them), but hey, honesty, balls, and being dumb sometimes feel good. Sounds like a true story.. oh, I know.

Anyone who's a common victim of recruiter spam might actually consider being blacklisted a plus.

That's a lame response from the interviewer, but you should probably have asked him what language you should use before doing it. If he did not say, then his question is underspecified (maybe to test you).

When I interview someone, I explicitly prefix coding questions with "you can just write pseudo-code or whatever you prefer" or "please use C/C++".

This is good advice. I believe I did ask and get the okay for using Python on this particular problem, which made the reaction a bit more surprising to me.

The next question had to do with string manipulation and I think he was just worried it would've been terribly easy if done in Python.

At least it sounds like the interviewer was just focusing on the next question and not putting you down for using Python.

While Python is a sizeable part of App Engine (SDK, admin console, tooling .. some other things I can't remember right now), the majority of the code is Java and C++. It's one of the reasons Python isn't listed as one of the top needs (http://googleappengine.blogspot.com/2011/07/wanted-app-engin...) over C++ and Java.

That being said, it's a very Python friendly team. Guido's on it (HI GUIDO).

and youtube

Every time here at Google that I've started a project in Python, I've finished it in C++ because Python had neither the speed I needed nor the maintainability I wanted. Every. single. time.

I can understand the speed part but maintainability? Sounds interesting, would you like to elaborate?

Static typing is a godsend when you're working with code that you only vaguely remember from the last time you worked with it a year ago. It also gives me much more confidence when refactoring: the compiler will find the callsites I missed.

C++ also has a great feature which a lot of more modern languages (Java, Python) have forgotten about: const correctness.

    class Foo {
        type_t getValue() const;
    }

When I call foo.getValue(), I can be certain [1] that foo has not been mutated.

[1] In C++, things like memset((void*)this, val, 1024) are always possible.

>const correctness

I love that C++ programmers still believe in the false gods of the const keyword.

Zen: reflect upon the meaning of a const volatile pointer.

-> exits stage right

Won't proper testing help on that matter too?

I've worked on rather big projects in Ruby and Javascript, and testing always managed to keep things sane. Static typing helps you refactor things or make sure certain variables are the correct type, but in the grand scheme of things, I'm not sure type casting is the major source of bugs/errors in any system

I do like Python but haven't used it for anything more than a few thousand lines.

The dynamic nature puts many errors into the runtime stage and increases verification complexity. Can be limited by static code checking, but grows cumbersome.

What do you use for longer programs?

Go if possible, C++ otherwise.

Duck typing makes for difficult debugging in large programs.

python's loose typing can cause some problems when new people start contributing to a sizeable project, that can be caught earlier in languages with stronger/earlier type checking.

But isn't Java the middleground between those two?

Not even close.

I'd say Go is, though.

When I was there is was more by 'layer' so if you were in the customer facing side you were pretty much talking Java or C++ but if you were in operations it could be Python, C, or bash scripts even.

> if you were in operations it could be Python, C, or bash scripts even.

As the case may be of late...Haskell.

YouTube's codebase is largely python, but it was sort of grandfathered in. I'm unsure if it would be used if they were to rewrite it today.

Some parts of it are being rewritten from the ground up, and I know of at least one sizeable portion that's being rewritten in python.

edit: depending on who you meant by 'they', I bet go would be a contender for (parts of) a total rewrite

YouTube is starting to use Go quite a lot. They even released this: http://code.google.com/p/vitess/

What does "grandfathered" mean? Seen the term in a few recent HN posts as well, dealing with accounts at web sites where they change plans, etc. TIA.

The part of the codebase I work on in maps is written in C++, making it the language used most often within my team. I've finished a number of projects in python though, and I don't get any impression that I'm required to program in these languages should I think another is more appropriate.