Hacker News Reader

> The answer he was actually looking for depended on the knowledge that open() returns the smallest possible file descriptor number -- so close stdout, and simply call open() again.

That should never pass any code review.

I almost wonder if he was really looking for an objection to that proposal, and specifically the reason for the objection.

It's the kind of thing I might do but I'd freaking TELL you, and in time so that you know how to handle the rest of the interview.

I don't think it's wrong to have a test that exceeds the range of the tested. Really no one should ever ace any test, else the test is insufficient. Thermometers don't just go up to room temp. So a sneaky question that only a truly insightful and thorough person might get, and ballsy enough to challenge the interviewer, and with good enough judgement to know when it's right to talk back, that I myself might not get, is fine. But it's there to identify the exceptional, to provide room in the plot for the spikes instead of clipping, not to kill everyone else.

I sometimes give people way too much credit though. I bet it was all face value.

> I almost wonder if he was really looking for an objection to that proposal

Nah, he wasn't. Near the end of our time slot, he shared the behavior of open() with me (that's how I learned about it).

I told him that doing it that way was silly, because it made the code's intent less clear. He didn't seem impressed.

Another point on your side is that close(); open(); is racy in threaded programs: to avoid the races you need to use dup2(), but that still has caveats related to losing errors from close().

Neither is it portable. Wonder how the interviewer got hired

> He was fixated on this one very specific piece of knowledge.

IMHO, that's what makes writing interview questions so hard: you really have to know the topic inside and out to know (or at least recognize) all the answers. If you only know one, your question is shit and you might as well have the applicant play guess the number.

That is silly. Trying to know all the possible answers is a losing game.

If I as an interviewer ask that same question and get the freopen answer, and let's say its not one I'm familiar with I can just simply say "I'm not familiar with freopen, could you tell me more about it?" And then I listen to what they say. A competent developer who is worth their salt will be able to summarise the gist of it quickly. Then if I want even more info I might describe the solution I know about and ask the interviewee to compare the two solutions, describe the pros and cons as they see them. What I would be looking for is the proof that the person I'm talking with is able to communicate complicated things clearly, and can think about code.

These skills are exactly what one needs in their everyday work, so why not use the opportunity to evaluate them? Does anyone really think that the goal of an interview question is to query if they know that specific trivia you happen to know?

And besides if I have doubts about that they are just hoodwinking me with this freopen I can just crosscheck what they told me with the reference. If it turns out to be not a thing at all, that's not a good sign and I will not recommend them to be hired, but otherwise they passed with flying colours.

> That is silly. Trying to know all the possible answers is a losing game.

That's why I also said "(or at least recognize) all the answers." You're describing some heuristics to recognize a valid yet unfamiliar answer.

The point I was making is it's silly to make an applicant guess one answer you know out of many.

Usually such a question is used not to fail you for not having the specific answer, but to observe your ability to reason about it and collaborate with the interviewer on pursuing the desired answer. What questions you ask, what resources you consult, experiments you perform, creativity you demonstrate, openness to alternatives, etc.

If you just fixate on your specific first solution and choose to dig in and argue over it despite your interviewer not liking it, it's not a good sign you're someone pleasant or frictionless to collaborate with.

Eh, maybe, but I’m guessing not in this case. Poor interviewers abound.

> Usually such a question is used not to fail you for not having the specific answer, but to observe your ability to reason about it and collaborate with the interviewer on pursuing the desired answer. What questions you ask, what resources you consult, experiments you perform, creativity you demonstrate, openness to alternatives, etc.

Trivia questions like that are absolutely awful for demonstrating any of what you're talking about. There isn't any creativity involved. And it's not like the guy followed up with something like "where would you go to determine the answer?"

There were 6 or 7 other interviews I went through that had interesting, open-ended questions that allowed me to bounce ideas off the interviewer and share my thought process. This particular interview was not one of them.

You're right, just like you were in the failed interview.

"not a good sign you're someone pleasant or frictionless to collaborate with"

That sreet must run both ways or it's an invalid charge. If you're reasoning is valid and the interviewer doesn't provide better arguments, then it's the interviewer who is not pleasant or frictionless to work with.

The mantra of every unreasonable person.

I hear a mantra myself.

Shit that was easy. Turns out anyone can say that.

It's almost like "I know you are but what am I?" doesn't mean, prove, or disprove anything, except to identify people who say things like that.

the interviewer already has the job

Uninteresting.

I wonder how dependent Google’s hiring pipeline has been on just having a huge % of every qualified candidate attempting to get a job at Google? If that is the case, then the interviewing process just needs to be good enough to have a low false positive rate. The false negatives don’t hurt them.

Yes this is well documented and I think Google publicly admits it themselves - they optimize to reduce false positives.

I'd be willing to bet that has a lot to do with it.

In my younger years I remember being in awe of the simple fact that a recruiter from Google actually reached out to _me_.

A decade changes a lot, though. I don't think I would ever want to work at Google now. I'd be curious to know if my shift in perspective on Google is common, and if they're even aware of it.

While I can't tell you how common it really is, I can tell you that we're at least two here. Same with the Amazon recruiters that reach out from time to time.

I absolutely do not want to work for Google. There's an office near me, and the few times I've been considering another job, I explicitly decided not to even send an application there. It sounds kinda like a dead-end hellhole to be honest. So it's not just you.

In universities Google and FB are now seen the same way as law firms and hedge funds were seen 20 years ago. A boring place where you go to have an upper middle class career and be conventional. Which means they are ripe for disruption.

When I was young, a Google recruiter reached out to me and I joined the firm. It was the good years and I enjoyed it a lot, learned a lot too. When I was older I quit. I wouldn't want to work there now. The company seems to have changed in deep ways for the worse :(

That’s a terrible interview question. I haven’t been at Google long enough to comment on hiring practices a decade ago, but nowadays I wouldn’t be surprised if an engineer who asked that type of question got feedback from HC to change their question.

I think that about a decade ago they still used horrible "why is manhole round" questions or "guess the trick" ones. The kind which puzzle-obsessed geeks like to ask eachother but which are horrible for evaluating fitness for a job.

This changed. I interviewed 7 years ago and they have fixed this, judging by the questions I got and the interviewer training I received. Using trick questions and fixating on "the" solution was explicitly called out as bad.

Of the questions I received two were open ended design questions and the rest was about algorithms and implementing them.

This happened with my onsite interview as well. I was working on local, user-based systems and hadn't done anything with networking/web-scale/sharding/etc.

I did very well with data structure questions, and had one difficult interview and one question about sharding a globally scaled system. I had never dealt with anything on that scale, and didn't even know how to think about it.

I realize that there was a gap in preparation, and I'm confident that that one interview out of 8 is what nixed my chances.

> I realize that there was a gap in preparation

I had a similar, but not the exactly same issue recently, and about 2/3s through the interview I was stopped and the interviewer kinda poked at my resume and successfully deduced that my prior work experience was just not at the level/scale the company was looking for. How do you prepare for that without having actually worked on that scale. Oddly, I ended up getting an offer for a different position after that though.

I can read about subject X all I want, but I would never be confident enough in an interview at just that. And large scale applications isn’t something I can just something I can replace with a side project.

So a Google engineer specifically wants code that relies on side effects?

This is one of those cases where you can be proud of a criticism rather than embarassed by it.

This is an interviewer fishing for trivia knowledge.

There are better ways to gauge knowledge competence, but this is an easy way, so people do it.

Out of curiosity, which kind of position within Google were you applying for? And how did you sell your own expertise?

This sounds like a really bizarre and very specific question for the interviewer to fixate on, unless it was particularly relevant for the position. Knowing the details of how to best do the redirect doesn't seem relevant for a generalist interview; this is the kind of thing you end up, well, googling when you need to do it. I suppose a kernel developer is supposed to know this though, were you applying for kernel development?

It was an SRE position. My technical experience has always been fairly general but largely infrastructure-focused and I had a computer science BS when I interviewed.

C only came up because I was asked to provide a list of languages I knew, and rate on a scale of 1 to 10 how well I knew them. At the time when I interviewed, I said I knew a little C (I had used it in a bunch of my CSCI coursework and some small personal projects).

So yes, it was an absolutely stupid thing to focus on.

I had a similar experience in a problem in which I was requested to extract the digits of an integer before performing some other task. I proposed doing this by converting it to a string and extracting the digits from the string, and that was rejected arbitrarily even though it solved the problem at hand just fine. So I spent entirely too much time during that session recreating an algorithm to extract digits via repeated division/modulo operations that would likely be much slower in practice.

> repeated division/modulo operations that would likely be much slower in practice.

… but that’s exactly how conversion to string works, so handrolling an algorithm would likely be around the same speed.

I don’t know enough about the question, but it’s possible that the interviewer wanted to test this specifically. I’ve had interview questions which were literally “implement itoa.”

In this case where itoa was part of a larger question, if I was conducting the interview I would let you convert to string for now so you could continue, but I would let you know that I wanted to revisit the digit conversion later.

>… but that’s exactly how conversion to string works, so handrolling an algorithm would likely be around the same speed.

https://github.com/lattera/glibc/blob/master/stdio-common/_i...

It's all bit-shifts, bit-masks and a lot of other hacks to get the maximum performance out of the system you're compiling the code on.

Could I write something with better performance on my system? Yeah, after a week to run tests and write esoteric macros.

An optimizing compiler will turn div-by-constant and mod-by-constant into multiplications and bitshifts. For example, the Rust compiler: https://play.rust-lang.org/?version=stable&mode=release&edit... (select "Show assembly" on the top-left button).

    pub fn divmod10(x: u32) -> (u32, u32) {
       (x / 10, x % 10)
    }

generates

    mov ecx, edi
    mov eax, 3435973837
    imul rax, rcx
    shr rax, 35
    lea ecx, [rax + rax]
    lea ecx, [rcx + 4\*rcx]
    sub edi, ecx
    mov edx, edi
    ret

It's still not as efficient since you're breaking on base 10 digit boundaries, not base 2, the most efficient encoding will be base 3, but alas we don't have ternary computers.

But it's a much more compact than that glibc monstrosity is. Sure, the glibc version will win in a micro-benchmark, but micro-benchmarks don't capture the effect on the instruction cache.

https://en.wikipedia.org/wiki/Radix_economy

Using a decimal expansion adds 25% overhead from pure maths. Your cache will be larger if you're working in base ten regardless of what optimizations your compiler does.

An example context where it wouldn't work is if stdin is closed, e.g. `./a.out <&-`. Awful question, I'm sorry you got hit by it.

I understand this was a decade ago, but god this is the type of stuff that makes me want to leave the field.

i had a similar experience wrt a product position. interviewer was fixated on a particular 'right' answer to a trivia-based question. was gladly not a fit there.

The interview loop is not necessarily an indication of the work environment. It is a chore, 1-2 interviews a week, about a couple hours each including prep & report writing, evaluating a candidate that will not work on your team, except in rare instances. I can see interviewers zoning into a specific answer simply because they have no energy and no interest to explore alternative avenues.

This sub-thread is missing the forest for the trees.

This interview was not the highlight of the interviewer's day. They most likely didn't overthink every angle and every word. They probably were on autopilot looking for some pre-defined criteria - and could care less if the candidate was qualified, accepted, or rejected.

That's plausible, but it doesn't change the fact that the interview was bad.

Right but Google really needs to be called out on the amateurism in interviewer training, selection, and quality control, as displayed throughout these comments. They clearly use volume and redundancy to make up for the number of failures.

I'm sure they'll come out with the argument "we give xx million interviews, we are within an acceptable failure rate with these outliers". No you're not Google. No you're not.