This happens everywhere; The superstar software developer (no) who knows everything (no) gets to interview you, and sometimes they are simply not right.

Your story reminds me my ~7th (?) interview with Google where for LRU caching I mentioned Java's LinkedHashMap; which resulted in he explaining me "what a ridiculous, memory-wasting data structure would that be!" - and going on for a good 5 more minutes bashing my lack of knowledge and me trying coming up with ad-hoc data structures.

Needless to say, I continuously refused all their recruiters since then.

(For the interested: https://docs.oracle.com/javase/7/docs/api/java/util/LinkedHa..., "This kind of map is well-suited to building LRU caches." - part of Java for more than a decade.)

This is pretty much why no one should feel bad if you're rejected after some FANG interview. It all 100% comes down to the people in your loop. You're likely to hit an ass hole or two.

I made it into Amazon, but honestly, after sitting in on a bunch of interviews, I now appreciate the amount of pure dumb luck involved (i.e. I got a loop of people who liked me and had questions I understood) rather than any skill (which is, well, pretty limited in reality).

Well I appreciate these interview loops because at least they are still far more objective than big company promo processes when whoever lies the most and forces others to do their dirty work gets promoted. I do wish the interview process was even more objective, just administer and extremely difficult IQ Test instead.

IQ tests are rarely objective and they most definitely don't measure the things most important for a large company.

Doesn't have to be a standard IQ test, I would be fine with the test being about algorithms and systems design type questions. Just please remove the biased human component from interviews and use a more standardized metric across a group of people instead of randomly chosen questions for each candidate with subjective evaluation. The current process is not great even for people with good tech skill due to the randomness and subjective evaluation factors.

Also you are wrong about standard IQ tests not being able to measure relevant skills for tech companies. They not perfect but I bet even those would do a better job than the current process. The psychometric research is clear that they are useful for predicting results across a wide variety of domains.

> standard IQ tests not being able to measure relevant skills for tech companies

I am basing this on what the HR department for the company that I work for tells me. They have been administering them for years and they have never been a reliable indicator of company performance. That doesn't mean they're not used - management loves them.

> The psychometric research is clear

Do you have some sourcing for me? Perhaps I can read up and improve my own professional experience with new colleagues.

Nor for a medium or small company. (I say this as someone who tends to take these tests very well, but they’re not that commercially relevant.)

Skills you can learn. Obviously if you have them already, it is a big plus. Otherwise, if you show you have some skills, that’s a good sign that you can learn new ones too. That’s why some interviewers ask questions more relevant to your CV than the job requirements.

It’s more important that you have a professional attitude and can contribute to the culture and values. That’s much harder yo learn. And a wrong character with even all the hard skills can ruin everyone.

My story: an interviewer stubbornly insisted that my code had to be O(n^2) because it had an inner loop, even though the inner loop was only iterating over the substructure of each element, rather than every pair of elements, and then demonstrated that he had no idea how to resolve a disagreement of that kind, and then immediately vetoed me from the rest of the day's interviews.

https://www.reddit.com/r/cscareerquestions/comments/1ilh7o/w...

If you manually unrolled the inner loop during the argument, would that have worked? (I’m not saying you should have had to, but sometimes you need to pick up a clue by four and whack someone with it.)

See the follow up comments about the experience in the Reddit thread. Everything bounced off this guy. He even thought he had “got me” by asking “what happens when the words are really long?” And I was like, “if the average word is long, that just means there are fewer of them for a given n and it cancels out.” I then clarified definitions about what “n” refers to and showed how it’s the same thing as “average word length L times number of words w”.

I even asked him what he would need to see to believe it was O(n) and he had no answer.

Nothing worked!

I've (nicely) reported interviewers like this to the recruiter. If other feedback comes back good, they might look back on the interviewer's past feedback, and they might request a follow-up interview.

> I continuously refused all their recruiters since then.

Even the almighty Google has people who don't know what they're talking about. Unless they're all like that, I'd write it off as a fluke. It's an embarrassing fluke for the interviewer--this is their problem, they should know it forwards and backwards and all the common solutions. If you get a lot of interviewers like that, then you should run.

Of all the interviews I've been to, I felt the most uncomfortable at Google. I was surprised how obvious it was that many Googlers are stuck-up, full of themselves, not just the aforementioned person.

Just because, they are Googlers.

Disclaimer: I'm not generalizing, and do have friends working for Google. Also this wasn't in the US.

Just for technical closure: Is the idea that you move an entry to the front of the linked list on access and then expire from the back of the list?

These things can always be childish when working with a bad interviewer. I once had an engineer keep interrupting me while I was explaining how sockets work because I wasn't covering small minutia details. Interviewing is an insane process. This is why building networks is more valuable so you're basically being interviewed by people you've already worked with.

> I once had an engineer keep interrupting me while I was explaining how sockets work because I wasn't covering small minutia details.

I'm going to be in trouble when it comes time to interview again someday. I am not nearly as accepting of muscle flexing (anti-social behavior) as I was 10 years ago.

You and me both. I had to walk out of an interview because the interviewer had become borderline rude and I could not think of anything at all professional to respond with.

Here's to future self-employment!

How'd you walk out? "Sorry, but I'd like to respect both of our time and end my candidacy here"?

I literally shot up out of my seat, offered my hand and said 'thanks for your time!' and got the hell out of there.

Not the smoothest, but it was just time for me to leave.

Makes me appreciate working for a large cloud with a core value “don’t be a jerk.”

Is this Microsoft? If so, good to know they've adopted this policy!

Oracle Cloud Infrastructure, actually. Oracle gets a lot of flak on HN, and some of it is justified. But the reality is that the team working on OCI is top-notch. And the product itself is quite compelling.

Oracle as an enterprise/legal behemoth is very different from the cloud transformation business unit.

Sounds like Pivotal, which literally has "Be Kind" as one of the three core values.

I get too distracted wondering if these people are always like this or just in interviews.

The silver lining is that I don't get jobs where the interviewers make me uncomfortable, so I don't have to deal with them more than once.

Sockets are easy. First there was the big bang...

I'm guessing you didn't get to do this interactively? If I interviewed someone and they seemed knew something I didn't and could prove it by actually running the query/code I would be impressed. At the very least the interviewer should have checked your claim after the interview if they were skeptical.

I think it's a real mistake when you don't let candidates write actual code and run it during interviews.

Correct, it was a "remote whiteboarding session".

It has made me absolutely loathe non-interactive sessions. Not being able to run the actual code is ridiculous. Some of the best analysts and programmers I know of are "architecture guys/gals" who can create complex systems but may not knock out the actual code so quickly, or, as I like to call it "error message programmers".

Creating an interview test to weed out otherwise-intelligent "error message programmers" is, in my book, poor interview construction.

This is me. I've used so many different programming languages over the years that for the first week of any new project, I am definitely an error message programmer. It goes something like this on day#1

Okay, I need to iterate through a collection. Which is it again?

foreach (int element in elements), no that's C#.

for (int element : elements) .. nope that's java

for (var element in elements) .. There we go.

Probably wouldn't exactly go like this, I know js isn't typed when I sit down to write it. (except for when it is!) ;)

Regardless, I call this my "tooling up" period. Each day i'm faster, and it takes about a week to get to 100%. but then I'm golden until the project is done and I inevitably have to switch techs again. I probably need to flex more than specialists in interviews because of this. Whenever pseudo code is on the menu I breath a sigh of relief.

When I see a candidate is not sure about some syntax trivia e.g. indexing expressions in Python, names for some library functions like charAt, size, length etc. I tell them to pick one (make it up) and move on. Though lately I've been using a runnable whiteboard with autocomplete so they have been able to figure it out on their own.

It makes me sad to think how hard it would be to remove bad interviewers like above. But as long as they perform reasonably well they won't get fired, and I don't think there is any interview QC system to feed back into the org. And thus we slowly slide from A to B and C territory...

This is why the real-tests should be entirely in pseudo-code and about the logical structure.

Any optimization should happen after a basic algorithm that works and might go along the lines of (telemetry suggests our platform has a bottleneck here) how would you speed things up if there's an issue in this section?

I'm with you on this, even beyond the first week. Been doing primarily Python for more than a year now and sometimes I still slide back to my Perl days and write the C-style for.

Perl has foreach which can iterate over ranges, arrays, lists and is synonymous with for, yet works just like foreach (that's Perl just being Perl).

Yup. A company reached out to me after a few years where I'd left their recruitment process because someone else made an offer (and they were being quite slow in their responses). I'd had multiple interviews, a coding project, and apparently they had been "ready to fly me out where, had I done well, I'd have had an offer at the end of that day".

So I indulged them. I spoke to a manager who said that he'd reviewed my coding project, and been happy with it ("so we can skip that"), so we talked (largely about K8s, as I am looking for an SRE management role - I'd told them I was happy where I was but was curious, and after all they'd reached out to me).

I talked about my experiences architecting K8s from a green field mostly by myself, and he was excited.

I spoke to someone else and he was excited. Okay, I thought, this has potential.

Email from HR: "We have a tech screen lined up for you. Please nominate some languages." I went with Python. Bear in mind I haven't written substantial code in _any_ language (except YAML, hah), for years. And was looking for a _management_ role in SRE.

So I had two rapid fire coding exercises (15 mins each ostensibly). Python lists and comprehensions, and some tokenization stuff. I struggled. Google was my friend but there was a good bit of "error message programming". I walked through the processes and my thoughts. I hesitated a bit at what Big O notation some of my code was, but I recognized routes to loop optimization and could see what was happening, even if I didn't know what the name was.

"Sorry, we are unable to continue following your tech screen".

Oh well. If your SRE PMs and group managers are required to write Python list comprehensions, maybe your idea of "manager" and mine... differ.

In my FB interview I was told I wasn't allowed to run the code, which seemed completely ridiculous to me. It was even more frustrating when my interviewer told me I'd missed an edge case when I was certain I'd covered it - I'm still not sure who was right.

At least you got to type your code. I had to write mine out on a whiteboard (actually, a patch of wall with whiteboard paint).

I went to an interview where there were no spare computers, so I was asked to write out a blackjack game in Java with pencil and paper. That was a lot worse than any of the whiteboard ones I've had.

Reminds me of programming tests at my college.

To be fair, in my opinion, you chose the wrong tool for the task. Why would you use a sum window function instead of a much simpler aggregate sum function (that does require a group by)?

Without the group by, you will be returning every row from the table, which isn't what the task calls for. You'd then have to do an additional row_number() or distinct or something to just get the unique rows per month per country.

I simplified the ask to be honest. It was not a simple `select date, country, sum(gdp) from table group by 1,2`. There were additional components to the question.

And as you mentioned, you can also distinct on the window function. This is not an inefficient operation in Redshift.

Also I fundamentally disagree with your premise. One result set is equivalent to another, and as long as you aren't using unnecessary nested loop joins or such, there are a dozen ways to solve a query.

In another interview at a similarly-competitive company to AWS , I was asked to do some work on orders and orderdetail tables to find all customers where the aggregate total of their orders from 2005 were greater than that of their orders from 2007. I did it using a couple of `sum(case when extract(year from datecol) = 200x then order_amount end)` statements.

The interviewer told me the question was intended to test whether the applicant was able to do a self-join but they were impressed with my alternative solution. That is the proper way to test SQL, not to say someone "did the query the wrong way"

>One result set is equivalent to another, and as long as you aren't using unnecessary nested loop joins or such, there are a dozen ways to solve a query.

If they consume similar resources I'd almost always opt for the simplest one to understand.

In cases where the simpler one is less efficient, I might still use it if the task didn't require absolute optimization.

Sure, and that would be a fair criticism, to say, "is there a version of this that's more intuitive and easier to read with the same load on the server?" But the interviewer (assuming the OP faithfully represented the exchange and the domain) is insisting that the query does not do what was asked -- when it does -- and is saying so based on the interviewer's own incomplete understanding.

That's not a good reason to reject a candidate, even if there might be other good reasons in this case.

Exactly, it would have been fair game to ask why I used a window function instead of an aggregate function + subquery joined back onto the main result set. Or, to ask if I could rewrite the query another way which would be more efficient.

However, the interviewer didn't simply insist the query does not do what was asked (when it did indeed return the correct results).

Instead, the interviewer actually insisted it was an invalid query which would not run at all.

In this case it sounds like a bad interview and that they missed a good opportunity for discussion!

From their perspective, they have hundreds of candidates and need to quickly filter a bunch out. So, having low-technical knowledge recruiters ask questions and look for a standard set of answers is the way they do it. There is no room for technical discussion during this phase, no room for nuance.

I'm not saying this is a good process or that it's fair, but it is the reality right now. You still get OK results and it's far faster and cheaper.

I’d already passed the recruiter screen and another phone interview. This was the technical interview with the manager of the group.

oh wow, damn. that is pretty sad.

You're exactly right wrt interviewing. I was talking in general and not in the context of an interview.

If you are interviewing someone and they solve the problem you ask, and then you don't give them some sort of guidance or constraints to meet your "correct" guidelines, then you aren't doing a good and fair interview.

In my experience, it is not unusual at that company for an interviewer to have poor knowledge of the technical subject matter they are asking you about, and to be unaware of this fact. Amazon has some extremely bright engineers but, unlike some of the other tech companies, there quite apparently doesn't seem to be a quality floor either and you can be unlucky in an interview.

Rather than be annoyed, you'd probably get bonus marks if you could show him the group-by query (sounds like you could have done that easily), then explain why your way is better. The interviewer would have been impressed at your maturity and skill.

The actual interview was more akin to the interviewer telling an interviewee that "python doesn't support multithreading"; something patently false. No, this kind of erroneous statement should not be glossed over.

For your information, this was the later stage of questions. The very first question did involve a simple summation group by, so I'd already demonstrated my understanding there. I showed no frustration or annoyance during the interview in case you are attempting to imply that was the case.

"python doesn't support multithreading"

wait, what about the GIL?!? did they fix that?

Python does support multithreading. The only thing the GIL does is prevent you from simultaneously running python code in more than one thread. You can still use threads to do io in parallel or to help interleave CPU tasks.

I think the parent is saying you /can/ use threads, but they will all contend on the GIL.

This is the reason whiteboarding gets a lot of hate.

It's really a great way to get insight into how people approach problems and how fluent they are in a subject. And if they get something wrong, but they thought it through, that's a problem that will fix itself pretty readily. The person who doesn't think stuff through likely won't start.

But the naive approach to whiteboarding is to do it as a test, can the person perform task X on the fly. The trouble is it's invariably an ad hoc test that generates ludicrously biased data. The really bad interviewers want to stroke their ego by stumping you with all the cool minutiae they know.

A week after, I passed a whiteboarding with one interviewer, the first of 4, at another large company (not FANG tier) writing pandas and SQL. The interviewer cared about design and the steps to perform a data loading task then querying it, and offered the choice of writing code or pseudocode (I did pseudo for python and wrote out the SQL explicitly).

That’s the proper way to whiteboard.

I remember suggesting one of my colleagues to take an interview instead of me and my manager disagreed and said I never saw him admitting to make a mistake.

Ideally you only hire people with good soft skills, but if you couldn’t, at least you should make sure they don’t do the interviews.

I hired last time someone because he showed us something we did not know yet.