In such situations I tend to ask that question directly:

"It was my understanding that you looking for someone who will help you with Django tooling. I can do that. Although number theory sounds interesting, I never felt the need of diving into it in order to solve any Django-related issue. I would be happy to learn more about how you think number theory relates to Django tooling should I start working here."

When people try to be important like that, it is paramount to take them at face value. In a lot of geek environments this happens all the time. People trying to push that one niche topic they really know about, because this is their comfort zone. The problem is: that one niche topic will rarely be a natural fit for any given conversation. More often than not just asking how they think this relates to the conversation at hand is enough to tame them a little bit.

Many times the stuff people say will contradict with the stated (or implicit) goals of a conversation. in this case the chosen topic was one with which the interviewer felt at home.

So another approach would have been to make it even more about them by e.g. instead of answering their question showing that you did your research: "Ah number theory! I saw you majored in number theory, I admittedly never had the need to dive too much into it — what role does number theory play in $Companyname?"

Great answer. Connect with the current position.

I would add here, that you may ask in a polite way, how number theory relates to the position at hand, here Django. This way, the interviewer has to open up specifically. There might be something, that could be important and interesting or simply a bluff.

Not exactly the same situation, but from a snarky interviewer I've gotten the answer equivalent to

"lol I was told you were the Django expert? According to your resume? Are you not supposed to know that?"

Still it does tell you that you have to work with this massive asshole, so it's a worthwhile approach to get more info about the workplace you'll be in.

> get more info about the workplace you'll be in.

or about the bullet you just dodged...

if someone connected django with number theory in their head and assumed everyone else can see the connection just as spontaneously, i'd much rather leave than try to handle that arse.

Tell him "I use Django Modules, not Django Modulus."

This doesn't always work - many software engineers believe that you should be a bit of a generalist. However, if you ask the question about Django tooling, you are at least keeping the door open.

Asking the "what role does number theory play" question is a way to send a message and lose your chance at the job, but so does "optimus prime."

You SHOULD be a generalist for software development, but I would argue college level number theory is not a "general" mathematical thing. For example, in my college degree program, I was expected to be broadly introduced to math and science concepts. To that end I took low level physics, chemistry, and math classes, including calculus, discrete math, and linear algebra.

I was not expected to know how to calculate the static load on bridge segments like my engineer friends, but I was expended to learn the basic motion equations and be able to apply them. Equally, I did not take organic chemistry, though I had the option. I can balance an equation but not tell you what an "amine" or an "aldehyde" is.

My college's opinion, and one that meshed really well with my personal opinions on learning, was that you are better off having some surface level understanding so when you are asked to implement some sort of very complex algorithm about a domain specific problem, you will be better equipped to understand the domain expert and understand the common pitfalls that you should avoid.

My friend was a math major (and other majors) so he took number theory. I didn't totally understand all the things we talked about, but thanks to my understanding gathered from other higher level math classes like calculus and discrete math, he could dumb down his information a little less, and I could follow things like how it was funny when he was able to "prove" something on a test by doing every possibility, since there were only 24 possible outcomes, and why that displeased his professor.

Depends. I am a decent software dev by all the standards I can observe. Yet I don't know a lot about number theory. I know a ton about other fields like e.g. control theory. If I now interviewed a django dev and asked them about control theory or hardware registers, I wouldn't even ask them whether they know that, because the answer is not really relevant to their position. I might ask them just our of curiosity, but then I would not care so much if they don't know it, I would care about how they handle dealing with something they don't know.

If they go all optimus prime that would be a red flag. If they show curiosity a green one.

I remember being told once in an interview "I'll be your google, your stackoverflow, so anything you'd usually search for on there ask me".

Eventually I got to the point where I forgot how to do something simple where you'd usually just google it to refresh your memory. I decided to take his advice seriously and asked him, to which he responded to me basically by rephrasing my question as another question back to me.

I can tell you now there is no chance Stackoverflow would be as big as it is if the responses you got back where riddles.

A more realistic answer would have been, "[duplicate] Closed 4 seconds ago."

I agree in principle, but also see how the interviewer might have felt that there's a good opportunity there to assess your reasoning skills about that thing. I actually like it when an interview takes some small detours.

I had an interviewer say something very similar to that to me once during a live pair coding session. I got to a point where I asked him a question about how javascript worked and he said "Hmm, I don't know. Let's see!" We spent the rest of the interview trying to figure out if javascript did indeed work that way. I didn't get the job.

At least the person who wanted to be your google didn't collect all your personal information then serve you targeted ads.

That sounds like a lame pick-up line, and they sound like a crazy stalker!

My google coding interview was much l33t.

He asked me a graph search question. However at the time I didn’t know what a graph was. I’m self taught.

But I did understand the ask, which was to find a path through a series of locations.

I also happened to have some experience with slime mold finding optimal paths and once even tried to simulate it using a genetic algorithm.

That was the best solution I could come up with, a genetic algorithm that would optimize a path through a series of locations based on a reward system.

However, I did not say the word “graph” and its not an optimal solution.

I didn’t pass.

I view the situation as both “I wasn’t prepared” and “google missed an opportunity to hire someone who might approach things a bit differently”.

> and its not an optimal solution.

Therein lies your problem, and you can see it writ large on everything Google does. Because they're so dominate at so many things (search, video hosting / streaming, etc.), anything that doesn't fall under "optimal solution" and "immediately profitable" goes to the waste bin near immediately.

There are entire websites dedicated to how fast Google kills a project that could have been really great with a year or two of love and care.

They've come to expect overnight success because it's been so dramatic for the past two decades. This blinds them to a lot of opportunities, and it comes, pretty much, from the top down and has filtered into nearly everyone.

> “google missed an opportunity to hire someone who might approach things a bit differently”.

That isn't what they want. See above. Optimal solutions, instant / near-instant profitability.

As a counterpoint to this, I interviewed at Google and was sure I had flunked. On every one of the follow-up questions, I didn't produce a working solution, let alone an optimal one.

I still got the offer.

Truthfully I do attribute much of it to luck. From what I have heard, most people had more difficult questions than I did, often with more strict interviewers. It's a high variance process for sure. If I were to interview for the same position now, I would most likely not pass the interviews.

Congratulations. I hope you enjoy working there. A close friend of mine used to work there in a very high position and they left after about a year or two, but left for what I consider to be pretty ridiculous reasons.

I'm not quite sure how much I could share without revealing their identity, but essentially they were sat down and told to work on their appearance. They had enormous technical chops (probably in the top 10 people in the entire world at what they do), but at least 60 lbs. overweight, no sense of style or fashion, etc., and as unfortunate as it might be to hear it... when you reach Director-level / C-suite positions, you need to physically project that OR you have to be so absolutely dominant at what you do that they cannot ignore you. They aren't that dominate.

A shame really, but they went off to work for a private startup and seem to be quite happy anyway.

I did okay in my interview with google but was passed over. The truth is they are always interviewing, so I think being hired has more to do with the timeframe of your interview than anything else. It's very similar to how the military drops many "requirements" of a soldier when what they need are bodies.

At some points, google is spinning something up, and at those points they need more devs, so they hire more of the interviewees. I think the rest of the process is basically random, based on the gut feelings of an entire team of random people.

I think you're a bit full of yourself here. There are objectively correct ways to search a graph, and it sounds like your solution was nowhere close.

You didn't get rejected because you "did not say the word graph", you got rejected because your solution was very wrong.

Software engineering is not just about knowing syntax, CS degrees include a Data Structures & Algorithms class for a reason.

> There are objectively correct ways to search a graph

Objectively false.

Years ago I was talking to some sort of CS professor who had been specializing in networking. He mentioned that within an organization you typically see network's being mapped out with dijkstra, but between them (with BGP for example) you actually see packets routed the long way around. He claimed service providers did this because it allowed them to charge their competitors more money when they had to use their network. Although, a more charitable interpretation is perhaps that a service provider will naturally want its own traffic to have the best experience and will send their competitors traffic the long way so that they don't over saturate the network of their primary customers.

Perhaps the best of all worlds would be mapping your network such that your primary customers get the optimal path using dijkstra. Then you figure out how to get your competitor's traffic routed as fast as possible without dropping your primary customer's packets. Maybe something a genetic algorithm might be good at figuring out?

There are some objective things in this world. The optimal way travel from point a to point b in a graph is one of them. However, this is the optimal way to travel, not the objectively correct way to travel.

I once traveled home from work using the backroads in a move that cost me probably 30 extra minutes. Roads are a graph. I followed the objectively non-optimal path. However, the way the clouds were that day formed something like 20 rainbows. Which I got to gawk at the whole way home. Objectively non-optimal, but not objectively incorrect.

The path is still optimal, but the weight of the edges are not speed or distance but a complex utility function that best represents the needs of the business.

It's also not about thinking creatively all the time. When I did interviews at a FAANG, there were many interviewers whose questions ranged from understanding basic CS to inventing new algorithms in specific circumstances. Generally, the second set of questions rarely had optimal solutions that took longer than O(n), and the first set of questions had answers that come out of a CS textbook.

In other words, the first set of questions is about doing normal tasks in the normal way, and the second set of questions is about solving relatively simple problems in a way that scales up massively.

When you are doing something that has a well-known optimal solution, your colleagues will expect it to be done in the well-known way. They don't want to have to read through your "creative" code to determine that you are just doing a graph search in a different way than they are used to. Engineering at a place like Google isn't about doing cool things: it's about doing things that are kind of cool in a way that a mediocre CS grad from a high-ranked school can understand and extend your solutions.

In my interview for my current job, I was asked to implement an algorithm that finds the edit distance between two strings. This is a classic algorithm, one that I had learned and implemented about a year before in my algorithms class, and loved for its utility, but I could not remember a specific little detail!

However, neither did my interviewers! So we worked together trying to re-derive the algorithm from the problem, the expected output, and the rough idea of how it worked. We did not succeed, but we did demonstrate an ability to work through things together, an ability to stand up and point out incorrect things, an ability to reason through a problem, etc. I got the job.

I would have hired you on the spot based on your slime mold experience!

Google notoriously hire Megatron supporters. You should have known!

Well what do you expect from a person who majored in number theory but makes a living working on django tooling in a company that doesn’t really use django to begin with? Delay and reschedule interviews until you get an interviewer whose LN profile does not clearly indicate a mismatch

Really sounds like the guy wanted to talk about himself instead of actually interview you. I hope you were able to send some feedback to his superior, since they missed a hire because of his shit.

They were well aware of how he acted. I was warned by another interviewer earlier.

"Whats the rest of your day?"

<shows schedule>

"Oh. X is from Google and he still does their style of interviewing"

Then having him still in the interview chain is an organization failure and a great signal to the interviewee (you) that team dynamics are going to be a problem.

I want to believe this is satire but I know it's not even an egregious example.

Whist number theory may never come up in Django tooling. "Something you don't know" always will; it is valid to try and determine how people respond to questions they don't know the answer too.

If the candidate says they don't know a topic, that is a valid response. It's not worthwhile to ask detailed questions about the topic. That's a sign of an inexperienced and/or unprepared interviewer.

Asking someone "how many prime numbers are there?" seems pretty valid to me. It's an easy question. The two valid answers are: "a lot" or "infinite" (with "more than 10" also being a fine answer IMO). I'm not sure the interviewer was expecting the actually correct answer here (infinite) - lots of programmers don't know that there are infinite prime numbers - I think he was trying to set up for an explanation of an algorithms problem.

By saying "Optimus Prime," OP has shown that he prefers to cover up gaps in his technical knowledge with snark and being an asshole rather than taking a stab at it and working in good faith. That answer would have disqualified him in my opinion. Even respectfully saying "I thought I was intervieweing for a Django tooling position" would have opened the door to further conversation.

This was a ways in to the interview and I do not think I was being as asshole. I didn't say it in a mean way or anything. I was laughing about it and said I had no clue and wasn't something I was interested in. He came in ready to grill me and I did not then, nor do I now, see any benefit to adversarial interviews.

I said I knew nothing when he asked about number theory. I never tried to cover up anything in my gaps. The interviewer proceeded to ask questions about it.

I don't have a CS degree, I have never claimed I did or that I enjoy or even want algorithms heavy jobs. This was an internal tool to manage datacenter component ordering.

I would never ask a bunch of questions about something borderline esoteric to someone that has already said they don't know anything about the field. I have had plenty of interviews where I am doing the hiring and when I realize the candidates are in over their heads I politely ask some fielding questions (like, do you know number theory is great, and fair) and then just conclude the interview kindly or toss them a different set of questions depending on how the interview has been going.

I assume you were flustered by that point due to a previous interview, and feeling a little frustrated or defeated. I've been there, when I think it's not going well but they still want to talk.

Nevertheless, it appears to me that those were setup questions for his real problem to figure out how to explain it. If you had approached it with a more open mind, you may have gotten the job. You would have at least heard the question.

I know that most people here hate the Google-style algorithm problem, but I think the question he was going to ask would be about computing the nth prime or counting the primes less than k.

I will also point out that many people who know nothing about number theory know that there are infinite prime numbers. It's not necessarily redundant.

If the job had been some sort of super low level position requiring a lot of hand written advanced data structures, then I might agree with you. Hashes, priority queues, skip lists, etc all rub up against more math heavy topics (number theory, statistics), so you would expect a candidate to at least have some familiarity with prime numbers.

However, for a web framework? Like, primes are pretty simple, but they're also pretty niche. What range of 'easy' questions that are not directly or indirectly related to the job are allowed to be asked? Can we ask questions about the correct leavening agents to use for different types of bread? I mean technically we're just trying to see how they cover up gaps in their technical knowledge. And all questions are 'easy' for the right people.

If you lure someone into a place with the promise of gainful employment and then waste their time with niche questions that are unrelated but you happen to have warm fuzzies about, then you should probably expect to get a bit of snark.

Still, whether or not the question was valid/appropriate/useful doesn't really matter. On the job, sometimes you will be asked things you don't know, or things you shouldn't even be responsible for knowing. The way this person responded to receiving a question like that indicates that they might be a difficult person to work with.

The interviewer sounds probably bad. After the person made it clear they didn't know about number theory, they should have moved to a different topic. But still, answering "Optimus prime" just suggests immaturity or even combativeness in the face of a difficult situation, which isn't someone you want to hire. There are a thousand better answers. Even snarky answers are fine as long as the person is meaningfully engaging.

"I don't know. Probably a lot"

"Maybe infinite. I'm not sure."

"It's an interesting question. Am I allowed to look it up?"

(As someone else said) "Definitely more than 10. Outside of that I'm not sure."

"I don't know. But here is how I would write a script to figure it out"

It comes back to the "move mt. fuji" style questions mentioned in the article. The point of an interview is not to determine whether you would be able to move mt. fuji anymore than whether you are able to answer the number of primes. It's about how you communicate and approach a problem. "Optimus prime" is such a non-starter that it doesn't even allow for a discussion.

I'm speaking as someone who passed a google interview and worked there for several years, so there may be some reason to believe my feelings around interview approaches are based in fact.

I think if you're going to ask a subsequent question about an algorithm for predicting when bread is done proving, you are allowed to ask about leavening agents. That way, you can bypass the long explanation, and just say "Given n loaves of bread with X characteristics, design an algorithm to predict when they are done proving." That might actually be a decent data science interview question.

I used to ask an algorithms interview question based on bridge (the card game), and I asked a setup question of "have you ever played a trick-taking game?" That lets me see if I need to use the short explanation or the long explanation, and if you answered that you knew how to play bridge or spades in a follow-up question, I would ask a much harder version. If you've never played a card game in your life, I would switch questions (this has happened several times). In real life, most people understand that this kind of question is a setup for a subsequent algorithms problem, not a quiz of your knowledge of bridge or prime numbers (particularly after you say that you don't know number theory).

The interviewer didn't care how much you know about prime numbers any more than I cared about whether you knew how to play hearts/bridge. The interviewer was almost certainly trying to figure out how much he needed to explain in the problem statement for the algorithms problem.

Responding with snark only shows that you are not willing to work with them in good faith, and you are not willing to see where the question is going. It shows that you think you know what they should be asking you, and you have contempt for them because they are not running the interview the way you prefer.

By the way, if the primes thing was actually a quiz question that didn't go anywhere, I would encourage any Django programmer to say a gentle "fuck you" at the end of the interview. I certainly would.

I think this is an 'okayish' position to take. There are some people who absolutely can't handle being wrong, and I've personally seen them wreck havoc when they get out of their depth.

However, there has to be a limit to the nature of the questions that are being asked. If I'm spending my free time to go check some place out because they're telling me that they might be willing to give me a job, then I'm going to be kind of put out when they start asking me questions about what the 50th letter is in shakespeare's macbeth. The questions have to be somewhat on point. This isn't a medieval system of patronage where I have to be subject to every whim of my patron. We owe each other to not waste each other's time. And if they're going to 'break trump' then I don't see why I shouldn't as well.

I can hear the objection though, 'oh primes are relevant to development.' But are they really? Maybe for advanced data structures like hashes, but what are you doing with a web framework that necessitates you write your own hash function? Besides, if you know about prime numbers, but not weak primes, strong primes, strong pseudo primes, safe primes, etc do you really know about primes and their CS applications? No, you just picked up some random trivia in high school and you're put out that everyone isn't as excited about it as you are.

I think you forget that even technical interviews are still aimed at examining soft skills.

"What is the 50th letter in macbeth?" could easily be interpreted as "How would you go about finding the 50th letter in macbeth?" which is plenty relevant to basic scripting.

"Do I have a source I can pull macbeth from?", "How does that source work?", "Can I query it for individual characters/words/chapters/etc.?"

I think a fundamental problem a lot of people in the comments section are missing is that these interviews are designed to examine the approach to solving problems, not the actual answer to the problem. Sure, if you get a question about traversing a tree, they probably just want you to repeat some basic knowledge.

Maybe something that will illustrate my point: If you happened to know the 50th letter of macbeth off the top of your head, it would defeat the purpose of the question. The point is to examine your problem solving process. If you were to just answer "r", then the interview would quickly pivot to: "Ok, what is the 307th?" or "Ok, what is the 50th letter of Othello?" The point is not to answer the question, so much as to establish the person's ability to answer questions. Any answer that was a straight up answer isn't useful in any way.

There are all sorts of ways your example could be expanded into a useful examination of someone's programming abilities. If prompted, the interviewer might provide: "Let's say we have an api for querying the text of a given shakespeare work" "Could we expand that to other historical plays?" "What if we wanted a service to provide an arbitrary letter from an arbitrary play?" "What if we wanted to allow the user to specify between several options for the api we might use?" "How could we handle differing responses from different apis?" "Should we be counting punctuation or whitespace?"

It isn't so much that a certain subject (historical plays) might be relevant to the job requirements, it's that these questions are more about examining problem solving approaches.

Alternatively, this could be taken to fall into the bucket of brainteasers, where a good answer might be "e", since it's the most frequently occurring letter in the alphabet in english texts.

The fact that the twitter interviewer introduced themselves as a xoogler is absurd.

You would be surprised how common this is. Lots of startup companies also love to brag about how many xooglers they have recruited. I once interviewed at a startup and the CTO introduced himself as "xoogler". After the interview I checked his Linkedin profile and he had a summer internship at Google 7 years ago.

Now I’m really curious if they pronounce it “zoogler” or an “exoogler”. Either way seems to be another “how do you know if a man went to Harvard or the Marines” type cliche.

What the heck is a xoogler? Sounds like some sci fi slime mold monster.

Here ya go: https://www.quora.com/In-Google-recruiting-what-does-Ex-Goog...

Xoogler is a slang term for someone who used to work at Google (ex-googler).

And MeToogler is a slang term for someone who used to work under Andy Rubin at Google, and won part of the $310 sexual harassment lawsuit settlement.

https://www.cnbc.com/2020/09/29/googles-310-million-sexual-m...

https://www.cnbc.com/2018/11/01/google-employees-walk-out-in...

Oh, this is hilarious. Well done for the 'Autobots roll out'! :D

Do you think they blacklisted you from twitter after that encounter? :P