Live data from Hacker News

Gaming CS Interviews

transitivebullsh.it

71–80 of 163 posts

Re: Gaming CS Interviews

#72
post #2

> Guidance is expected; a great interview should be more of a conversation than a one-sided question and one-sided answer. I had a particularly awful interview at Google where the interviewer scoffed at me needing assistance. And in an interview at Twitter with a xoogler they asked me what I knew about number theory and I said "nothing" and they said they majored in it and proceeded to ask me number theory questions.…

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”.

Re: Gaming CS Interviews

#73
post #19

Earlier quoted context omitted.

The issue isn't telling people about basic things like you learn in a CS major - it's about taking random problems and solving them on a whiteboard without any errors (syntactically or otherwise) while explaining the solution, alternative solutions, and figuring out any gotchas that they love to throw in less than 20 minutes. An easier one would be something like this - https://leetcode.com/problems/combination-sum-i…

I've seen some very bad interviewers that will fault you for non-perfect solutions, but most will have some sort of reasonable leeway in what they will take as a solution.

This experience varies too much for the individual. I've been given almost no leeway with all of my interviews. Most of my peers are in a similar bucket but I will admit - I seem to get some of the worst experience out of my peer group. I am often given more LC hards than my peers and still rejected even if I give multiple solutions with optimal complexity. At this point, we all suspect it's due to superficial factors but can't obviously do anything about it.

Some people I know who are URT would not even have to solve the problem to get a passing grade. Some know this and actively take advantage of it (and good for them) but others are blissfully unaware and are shocked when they find out that what they experience isn't the norm.

Re: Gaming CS Interviews

#74
post #2

> Guidance is expected; a great interview should be more of a conversation than a one-sided question and one-sided answer. I had a particularly awful interview at Google where the interviewer scoffed at me needing assistance. And in an interview at Twitter with a xoogler they asked me what I knew about number theory and I said "nothing" and they said they majored in it and proceeded to ask me number theory questions.…

[deleted]

Re: Gaming CS Interviews

#75

Hmm I feel like the best way to "game" these interviews is just to learn solutions to the top 100 leetcode questions and then act as if you're figuring it out on the spot. That's what I started doing in preparation for a Facebook interview but I think that's not actually going to happen in the end anyway due to the hiring freeze and also the ridiculous H1B situation.

Recently gave an interview where they asked me to open my Leetcode profile, and checked if there are any prior submissions to the asked questions. ¯\(ツ)/¯

Seems like a flawed system. I would just use a fake profile or say I only used CTCI as prep.

Re: Gaming CS Interviews

#76

> Strings are just arrays of characters, so any algorithms you learn for arrays also applies to strings. I.e. don't believe the anti-American propaganda on Unicode.org.

This is roughly true. Obviously with UTF-8 or UTF-16 you'll have O(n) access times for an arbitrary code point, but you can always convert to UTF-32 and that encoding is just an array of code points so you get O(1) random access back.

Re: Gaming CS Interviews

#77

Earlier quoted context omitted.

YMMV but in college I learned lots about - having to work together with assholes towards a common goal - how sometimes you can cram for a deadline, but sometimes you can't - how, often, how well you do is just politics and networking Obviously fuck everything I learned about however pushdown automata worked. That's not relevant to my career now. All the above still is.

The automata class I took years ago has been one of the more relevant to my career.

TBH I was struggling to come up with a class that was relevant enough that I recalled it, but not relevant enough that I never used it ;). It's been a while since I graduated, so I probably suppressed a lot of memories about courses like Advanced Partial Differential Equations.

Re: Gaming CS Interviews

#78
post #31

The conflation of "amortized" with "expected" feels a bit off to me. Amortized O(f) strongly suggests that the sum of n operations is very very close to O(n×f). I wouldn't say hashmap insertion is amortized O(1), because if you craft input that always incurs a hash collision, then n insertions is much worse than O(n). I would say that it's expected O(1), meaning that with high probability an insertion takes constant…

Ordinary hash maps are still amortized expected O(1) — they will hit an O(n) case, guaranteed, when they need to grow the array, and it’s expected that the amortized runtime is O(1).

Being merely “expected O(_)” would be appropriate for algorithms that lack amortization, such as quick sort.

Re: Gaming CS Interviews

#79

Earlier quoted context omitted.

Maybe it is not the best system, but isnt it at least relatively fair and transparent in compare to "having luck on interviewer's stack/xp"?

Why would that be the only other option? That's exactly the same kind of hoop-jumping, perhaps even a little more honest. This is exactly what I was talking about above. The solution for a known-to-be-broken system isn't another known-to-be-broken one, and it isn't keeping the broken system because it's already in place. Development isn't about rote memorisation or slavishly repeating past mistakes. Knowing the Voigh…

The question I have in regards to your suggestion is, how scalable is it ? Can/could it be applied to a FAANG-sized company ? I'm not rejecting any of your points, its just that every time someone critiques the current hiring practices they fail to provide an alternative system that does not introduce other problems (the first and most notable one is scalability, but there are many others)

Re: Gaming CS Interviews

#80
post #2

> Guidance is expected; a great interview should be more of a conversation than a one-sided question and one-sided answer. I had a particularly awful interview at Google where the interviewer scoffed at me needing assistance. And in an interview at Twitter with a xoogler they asked me what I knew about number theory and I said "nothing" and they said they majored in it and proceeded to ask me number theory questions.…

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.
Post reply on HN