Live data from Hacker News

Gaming CS Interviews

transitivebullsh.it

61–70 of 163 posts

Re: Gaming CS Interviews

#61
post #58

Earlier quoted context omitted.

Yeah, which improves the time complexity too. Plus many languages offer easy list to set conversion

It doesn't change the time complexity. Both are O(n). Your point about convenience stands, though. Actually, if you go into fully pedantic mode, the set version is worse. Hash-based set insertion is commonly taken to be O(1), but that depends on hash comparison being O(1), which depends on using single-word hash values, which means your n is bounded by eg 2^63 (50% occupancy) or whatever. Honestly fine in practice, b…

O(1) indexing into an array is a much bigger lie in practice than relying on single-word hash values. It breaks down much, much sooner which is why we have multiple levels of caches to try and hide this.

In reality random indexing is O(sqrt(n)) for 2D memory chips, and at best O(cbrt(n)) in our 3D physical world.

Re: Gaming CS Interviews

#63

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. ¯\(ツ)/¯

Interesting! I suppose one could prepare for that by having a second profile with just a few questions solved?

Re: Gaming CS Interviews

#64
post #50
post #49

Earlier quoted context omitted.

Hah! That's awesome. I'm not sure how well it would work in practice, since you're depending on alloc() giving you uninitialized memory—if it zeroes it, then it's back to being O(n). But that's kind of an unfair quibble. And of course, it adds a branch to the lookup. Still O(1), but you'd need to check which buffer to find a given index in. Really not a problem here since as you say, the whole point is to bound the l…

It does not necessarily add a branch to the lookup, look more closely: all current data exists in buf in its entirety. It is duplicated into next_buf. This might be problematic depending on T in C++ as it would need to invoke copy constructors. In Rust all types can trivially be memcpy'd into another location if you own it, so this design would be entirely valid (as long as next_buf is not publicly accessible at all,…

Doh! You are right, of course. My head is stuck in the standard doubling approach. You are pre-copying into an upcoming buffer.

Which, as you say, is going to be weird with the language model, since the "same" thing exists in two different places. In C++, it would encounter problems with either a destructor or a copy constructor.

I still think it's a cool trick for a realtime setup for arrays of trivial types.

Re: Gaming CS Interviews

#65
post #47

Earlier quoted context omitted.

Does it? Set insertion is O(log n) and you need to insert n items.

Not if you use a hash set. This is expected O(n) time to de-duplicate an array of integers while maintaining the original order (more explicitly written than I normally would in Rust for didactical purposes): let mut hash_set = HashSet::new(); let mut len = 0; for i in 0..arr.len() { if !hash_set.contains(&arr[i]) { hash_set.insert(arr[i]); arr[len] = arr[i]; len += 1; } } arr.truncate(len);

Good point but it's not exactly a free lunch. You're trading memory for the speedup.

You can also use radix sort for what I'd like to call "fake" O(n) sort since physical hardware puts an upper limit on the hidden constant.

Re: Gaming CS Interviews

#66

Earlier quoted context omitted.

Does it? Set insertion is O(log n) and you need to insert n items.

But to order a list is O(n log n)

In the worst case, you need to insert every element into your set to find out if there's no duplicate hence it'll take O(n log n) too

Re: Gaming CS Interviews

#67
post #15
post #8

> a sorting algorithm may take O(n log(n)) runtime which is pretty common but be able to operate on an array in-place, only requiring O(n) storage. If it's in-place the sorting might only require constant space and it can be O(1 ) [edit: in terms of space complexity]

Did you mean O(n)? It seems hard to sort n items without at least touching all of them once, which would make the time complexity linear (O(n)) instead of constant (O(1)). Or are you talking about storage needs? Then it sounds very hard to go sub-linear ... I'm confused. I'm certainly not a good theoretical computer scientist, but I did quickly google this and I couldn't find any trace of constant-time sorting (unles…

Well... sorting a shuffled deck of cards can be done in O(1) time.

    def sort(self):
        pass

    def __getitem__(i):
        suit = int(i / 13)
        rank = i % 13
        return f"{rank} of {('diamonds', 'hearts', 'spades', 'clubs')[suit]}"

Re: Gaming CS Interviews

#68
I've seen people ask questions they can't answer on their own. Always ask self if you really want to work in a place that have this type of people in commanding positions.

Also given the saturation of the market with job offers YOU choose not they EMPLOYER. This might change in future but be aware of this current balance, you can game it.

Also even if you have infinite skill you might be not liked by random reason. That happens, bad/good days happen, interview is harder for interviewer than interviewee usually.

You are showing Your GOOD sides and he is assesing your BAD and GOOd sides.

Re: Gaming CS Interviews

#69
post #9

Earlier quoted context omitted.

> If you're using an interview that bares 'little relevance to an employee’s day-to-day work' and that requires dedicated prep to pass, then what you're doing is optimising a process for finding people who will tick boxes and jump through meaningless hoops. You mean all those jobs requiring college degrees? Or is that different somehow? The main reason is that difficult tests has positive signal even if they are part…

>interview prep has nothing on 4 years spent full time that's just the problem with these interviews. It's kind of obvious that a fresh grad who prepares for 2 weeks for those whiteboard interviews will completely outclass known most productive programmers and engineers in the world (take whatever example you want, I would name someone like John Carmack) who takes the test fresh and unprepared. The modes of thinking…

> a fresh grad who prepares for 2 weeks for those whiteboard interviews will completely outclass known most productive programmers and engineers in the world (take whatever example you want, I would name someone like John Carmack) who takes the test fresh and unprepared

This extreme take is highly unlikely. World class programmers are typically extremely good in maths (and possibly have an active interest in it)/algorithms, and problem solving in general. In addition to J.Carmack (who is definitely very good in linear algebra and problem solving), another random example is F.Bellard (who calculated the largest known prime, and most digits of pi). L.Torvalds is surely extremely good with algorithms, S.Wozniak with problem solving (given his extremely good design skills in electronic engineering); another one that comes to my mind is P.Bonzini, with his 40 GB/S fizzbuzz :)

Re: Gaming CS Interviews

#70

Earlier quoted context omitted.

> The main reason is that difficult tests has positive signal They provide a signal, but I don't think the evidence suggests that it's necessarily a positive one. "Can you play Czardas on the tuba" is a difficult task that would provide a strong hire/no hire signal, but that doesn't mean it would be a good signal to use when looking for developers. The big tech companies themselves admit that a bunch of their employe…

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 Voight-Kampff algorithm doesn't make you a good developer, nor does claiming 20 years of experience with a decade-old technology, nor does being the CEO's nephew. All of those things provide (at best) a totally irrelevant signal.

What if we used better methods? Ones that actually assessed and evaluated the skills/traits necessary to do the job well? Ones that couldn't be gamed as easily by "grinding". I'm not saying there's globally-applicable silver bullet just waiting to go, but there are definitely avenues to explore.

One process I went through quite recently asked me to bring along a single line of code I'd written - any language, any project. Then we had a conversation about it: what it actually did, how it fitted into its context, why I'd written it like that. It provided me with an opportunity to show my understanding, and for the interviewer to probe particular areas they were focused on. I enjoyed the process, and I could see how it was providing relevant information to them.

Again, it's an imperfect process, but I think there's potentially a lot of mileage in 'talking to developers' when hiring them, with any number of different twists. At the very least, we should be experimenting and trying to find a fit-for-purpose process.

Post reply on HN