Live data from Hacker News

I had to give a wrong answer to get the job (2017)

dewitters.com

291–300 of 409 posts

Re: I had to give a wrong answer to get the job (2017)

#291

I bombed an interview at a game company because I gave a right answer that I couldn't get them to understand. I don't remember the exact problem they wanted me to solve, but the answer involved a dynamic collection and they wanted it to grow with constant time complexity. They were probably looking for a linked list. But I said I'd use a dynamic array because those have constant time when averaged over a series of ap…

am I the only one concerned that this would even be a point of contention? This seems too trivial for anyone doing hiring or being hired to be hung up on.

I mean, I'm guessing this is the main reason that they passed on me, but I'll never know for sure. Maybe they didn't like my personality. Maybe it was some other question I thought I did well on but didn't even realize I got wrong. Maybe a combination of things.

For what it's worth, I didn't get a very good vibe from them. The impression I got was that their culture was more aggressive and competitive than I like. (Maybe this was to be expected for a company that made a competitive eSports game.) I'm not really what you'd call a brogrammer.

So it was probably for the best that they said no. I ended up at Google, which has been better for me in every possible way.

Re: I had to give a wrong answer to get the job (2017)

#292

I was once asked to write a function that, given the time, draw an analog clock. Given the nature of the position I was applying for, this wasn't an unreasonable question. I wrote something on a whiteboard. What followed was the most surreal discussion I've had in an interview. My function took into account the seconds, minutes and hour for the hour hand, and so on. Just like a normal clock would. The interviewer ins…

Ugh. This reminds me of when I interviewed with Google some years ago. It's a somewhat long and boring story, but basically, it was a distributed map-reduce problem. I clearly stated my assumptions and asked for clarification/confirmation so we could disambiguate. The interviewer and I were very clear what he was asking and what I would be answering.

So I proceed to answer the question, describing what I was doing and writing code, and at one point he stops me to say, "That won't work because X may not be the case." But X was one of the points of clarification up-front, so I called him out on it politely but firmly. I wasn't sure if it was [a] a language thing (he's a non-native English speaker with a fairly heavy accent), [b] an issue with experience (he was being reverse-shadowed in the interview), [c] him trying to test soft skills in some really bizarre way, or [d] some bullshit that won't fly.

I have no real problem with a,b,c, though the more experienced engineer doing a reverse shadow should step in when things go amiss, so I fault that engineer for jumping in. But regardless, I was thoroughly nonplussed by the way Google runs interviews, and I've essentially sworn them off. It wasn't until Facebook that I found a company that I want to work for even less.

Re: I had to give a wrong answer to get the job (2017)

#293

Earlier quoted context omitted.

The goal of the interview shouldn't always be to get the job. If you have any length of career, you are interviewing the company as much (or more) than they are interviewing you. My approach would have been to go with the new idea and see what discussion can come out of it. If they don't have time to get into it, that's one thing but if they are simply not open-minded to new ideas, I don't want to work there.

I don't think I could make a decision about whether I'd want to work for a company on the basis of a single employee's attitude. That person might not even be part of my day to day work group.

And yet the company chose to let themselves be represented by this person. It might also go the other way around, you are interviewed by someone that's awesome and you end up with another team that truly sucks.

In that case bad luck but if they send a dick to interview you it is more likely that the rest of them are also gonna be dicks. I like companies where you actually interview with some of the people you will be working with at least as the last interview round.

Re: I had to give a wrong answer to get the job (2017)

#294

Earlier quoted context omitted.

> Arrays used as backing for lists are faster than linked list in almost all cases, assuming they are implemented correctly (as is the case in Java, which I bring as an example). I think you're overcorrecting here. There used to be a conventional wisdom that linked lists were always faster than dynamic arrays because you don't have to copy or shift items. But then CPUs got faster while memory didn't and caching effec…

> There used to be a conventional wisdom that linked lists were always faster than dynamic arrays because you don't have to copy or shift items. But then CPUs got faster while memory didn't and caching effects became so prevalent that that conventional wisdom is no longer true. Nothing to do with caches or conventional wisdom no longer being true. Think for a second, if you want to insert somewhere inside your shiny…

> Think for a second, if you want to insert somewhere inside your shiny linked list, how do you find where to insert?

You usually have a pointer to the node where you want to insert.

I don't think many people would suggest using linked lists in cases where you actually do need to seek for the insertion point.

Re: I had to give a wrong answer to get the job (2017)

#295

Earlier quoted context omitted.

Wow those sound like such badly designed questions. What country is this?

I don't know about that person, but a friend of mine from India was telling me about a driving test question there - [translated] "How far should you stay behind another car - A) 2 meters B) 2 seconds". Apparently the correct answer is 2 seconds. In my opinion, the question is weirdly ambiguous.

"Two seconds" is what I learned too. The book here says that you should be at the spot where the previous car was two seconds ago, which is good advice, as it's independent of speed.

You can think of it as "it'll take you one second to react and one to brake to a stop, so you should be two seconds away".

Re: I had to give a wrong answer to get the job (2017)

#296

Earlier quoted context omitted.

None of the comments above yours in the thread mention any form of the word "fast" or "speed". They mention "performance" in reference to big-O complexity. Big-O is not always about speed.

> None of the comments above yours in the thread mention any form of the word "fast" or "speed". They mention "performance" in reference to big-O complexity. Big-O is not always about speed. I am sorry, do you want to say "performance" and "big-O" have nothing to with trying to make the program go faster? I think you have lost your way and need to backtrack a little bit. The whole point of big-O analysis is to be abl…

[deleted]

Re: I had to give a wrong answer to get the job (2017)

#297

I bombed an interview at a game company because I gave a right answer that I couldn't get them to understand. I don't remember the exact problem they wanted me to solve, but the answer involved a dynamic collection and they wanted it to grow with constant time complexity. They were probably looking for a linked list. But I said I'd use a dynamic array because those have constant time when averaged over a series of ap…

am I the only one concerned that this would even be a point of contention? This seems too trivial for anyone doing hiring or being hired to be hung up on.

> am I the only one concerned that this would even be a point of contention? This seems too trivial for anyone doing hiring or being hired to be hung up on.

You'd be surprised! I've done probably 200+ interviews across a couple companies. Over time if anything my questions have gotten simpler.

I look for someone who understands the fundamentals of the stuff on their resume, asks good requirements questions, thinks a bit before leaping into the weeds, can explain their thought process, ideally does some of their own double-checking, and (if it comes up) can debug a problem I spot without my spelling out their error.

And last but not least: I don't want to cause a panic attack, which would be mean and tell me nothing. Sometimes my candidates have been too nervous for me to know if I should hire them, and it's not a good experience for anyone.

So I make the problem as simple as I can and make sure we get through the rest of that in as relaxed a fashion as I can manage. I'll ask a simple (often first-year CS) coding problem or a design problem, rarely both in the same interview slot. I never ask for tons of code on a whiteboard in a 45-minute slot.

Re: I had to give a wrong answer to get the job (2017)

#299

Earlier quoted context omitted.

None of the comments above yours in the thread mention any form of the word "fast" or "speed". They mention "performance" in reference to big-O complexity. Big-O is not always about speed.

> None of the comments above yours in the thread mention any form of the word "fast" or "speed". They mention "performance" in reference to big-O complexity. Big-O is not always about speed. I am sorry, do you want to say "performance" and "big-O" have nothing to with trying to make the program go faster? I think you have lost your way and need to backtrack a little bit. The whole point of big-O analysis is to be abl…

No it’s not, it’s about trying to quantify algorithmic complexity.

Re: I had to give a wrong answer to get the job (2017)

#300

Earlier quoted context omitted.

None of the comments above yours in the thread mention any form of the word "fast" or "speed". They mention "performance" in reference to big-O complexity. Big-O is not always about speed.

> None of the comments above yours in the thread mention any form of the word "fast" or "speed". They mention "performance" in reference to big-O complexity. Big-O is not always about speed. I am sorry, do you want to say "performance" and "big-O" have nothing to with trying to make the program go faster? I think you have lost your way and need to backtrack a little bit. The whole point of big-O analysis is to be abl…

"Performance" depends on a number of factors beyond the code itself.

To take a real world example, immutable operations in Javascript are often more performant than mutable operations--thanks to the fact that the Chrome Engine "cheats" with its hot path functionality.

However, in Big O, constantly generating new data structures, even within loops, would clearly trash the algorithm's space complexity. On compilers that don't optimize for immutability, the Big O algorithm is more performant; on the ones that do, the immutable approach is more performant.

It's because of example like these that you want to disconnect the concept of "performance" from Big O. Because context matters for the former, while the latter relates only to the algorithm itself.

Post reply on HN