Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The technical interview is an ego trip

blog.kowsheek.com

Post reply on HN
Print view View original

141–150 of 206 posts

Re: The technical interview is an ego trip

#141

Post by jhanschoo »

leafboi wrote: post #130
cottonseed wrote: post #124

Earlier quoted context omitted.

> The Domain and Codomain for both functions are exactly the same. This is not true. > def List[A].foldLeft[B](z: B)(op: (B, A) => B): B > def List[A].foldRight[B](z: B)(op: (A, B) => B): B Notice the signature of the fold op: the arguments types are swapped. This is because fold left and right on a list [a, b], say, is the difference between: (z op a) op b and a op (b op z) (If this isn't compelling enough, consider…

Elements in sets are not ordinal. In principle they are the same as the set (B, A) is the same set as (A, B). If you're saying that foldRight in scala exists aesthetic reasons... well can't argue with that. I figured it was more for legacy reasons as the original poster said that there use to be a performance difference. As for the associative thing I mentioned side effects. Function composition is always associative…

Parent wasn't slightly wrong, you just tunneled in on the signature of the operator function, when the reason why parent comment brought it up was to illustrate that the operator function is not necessarily associative, and that the function signature was meant to suggest the difference in associativity.

You're wrong about the operations possibly not being commutative; as you pointed out, whether the parameter list is (A, B) or (B, A) doesn't really matter, so it doesn't pose a problem.

An example is the subtraction operator: with just two elements, I can change `(a, b) => b - a` to `(b, a) => b - a` with with no difference in result. But there is no way I can write a subtraction function for foldLeft that gives the same results as a foldRight on subtraction in general. That is, I can write op such that a op b = b - a, but not that (a op b) op c = (c - b) - a. Nevertheless, I can still write op such that a op (b op c) = (c - b) - a due to some dual notion of commutativity.

Re: The technical interview is an ego trip

#142

Post by roflc0ptic »

leafboi wrote: post #130
cottonseed wrote: post #124

Earlier quoted context omitted.

> The Domain and Codomain for both functions are exactly the same. This is not true. > def List[A].foldLeft[B](z: B)(op: (B, A) => B): B > def List[A].foldRight[B](z: B)(op: (A, B) => B): B Notice the signature of the fold op: the arguments types are swapped. This is because fold left and right on a list [a, b], say, is the difference between: (z op a) op b and a op (b op z) (If this isn't compelling enough, consider…

Elements in sets are not ordinal. In principle they are the same as the set (B, A) is the same set as (A, B). If you're saying that foldRight in scala exists aesthetic reasons... well can't argue with that. I figured it was more for legacy reasons as the original poster said that there use to be a performance difference. As for the associative thing I mentioned side effects. Function composition is always associative…

I don't think I understand the point you're making. I just tested it, and empirically your assertion is incorrect:

// this makes a linked list ten million and one elements long, from zero to ten million

val longList = (0 to 10000000).toList

// this adds the elements

longList.foldRight(0)({ case (l, r) => l + r})

This does not stack overflow.

You write:

>> a plain fold has the exact same inputs and outputs as foldLeft or foldRight

but if you use fold over a collection of type T with the fold function in Scala, the result must be of type T. Fold left and fold right don't have this constraint. Further, this fold is only coherent if the operation is commutative, because it doesn't happen in any particular order. You can add integers in any order to make the same sum, but you can't add pages of a PDF in any order to make a PDF.

Framed via recursion schemes, I'm pretty sure foldLeft can be viewed as a catamorphism where foldRight is an anamorphism. You're consuming the tree from different directions. They may have the same domain and codomain (I'm a little hazy on that) but they're not apparently the same function. y = 2x and y = 3x both have the same domain and codomain, right? But the difference between them isn't aesthetic.

Re: The technical interview is an ego trip

#143

Post by seanmcdirmid »

TheCapn wrote: post #10

This was my take on interviewing with Amazon at one point a long while ago. The initial interview itself was pretty straight forward, but it seemed like every answer I gave was "wrong" because the interviewer was looking for key phrases instead of understanding of the concepts. We talked about hashing, and when he asked if I knew what hashing was I said sure, its a one-way function to create a unique identifier. He a…

I’ve heard amazon interview experiences are all over the map, just like their teams are. Some are really good, some are really bad at it.

Google and Facebook seem to be a bit more of a consistent experience, but interviews are done generically and not by the team that would hire you.

Re: The technical interview is an ego trip

#144

Post by minot »

hashkb wrote: post #110
reader_mode wrote: post #92

Earlier quoted context omitted.

I see nothing wrong with this, why would I write algorithm X from memory or taking my best guess at it on the spot, isn't the whole point of learning them recognising when are they applicable and how to find them quickly ?

It's kind of like knowing multiplication tables, or intervals in music. There's some stuff you just gotta know.

Knowing the multiplication table is such steaming nonsense. I know 7x10 is 70 so half of that, 7x5 is 35. I can add seven to 35 fast enough that I don't have to memorize 7x6 is 42.

Memorizing is not knowing.

Re: The technical interview is an ego trip

#145

Post by leafboi »

jhanschoo wrote: post #141
leafboi wrote: post #130

Earlier quoted context omitted.

Elements in sets are not ordinal. In principle they are the same as the set (B, A) is the same set as (A, B). If you're saying that foldRight in scala exists aesthetic reasons... well can't argue with that. I figured it was more for legacy reasons as the original poster said that there use to be a performance difference. As for the associative thing I mentioned side effects. Function composition is always associative…

Parent wasn't slightly wrong, you just tunneled in on the signature of the operator function, when the reason why parent comment brought it up was to illustrate that the operator function is not necessarily associative, and that the function signature was meant to suggest the difference in associativity. You're wrong about the operations possibly not being commutative; as you pointed out, whether the parameter list i…

Function composition is associative but not commutative.

So in essence given three functions z,g,f and composition operator 

   f . g . z != z . g . f (commutativity)
which is sort of what fold left or right is doing (but with z g and f being the same function).

but:

   f . g . z == z . (g . f) (associativity)
My edit is right about the operations not being commutative. Parent is wrong about associativity as it has nothing to do with this, but he is right that the codomains of left and right are not equal.

Function composition isn't completely accurate to what's going on, it's a more higher order form of composition going on with fold but the rules remain the same.

Whatever, either way, Overall I'm wrong

Re: The technical interview is an ego trip

#146

Post by wolco »

smabie wrote: post #43
pmiller2 wrote: post #41

Earlier quoted context omitted.

I don't know what the interviewers expect, but, generally, your "reward" for admitting you've seen the problem before is a harder question to answer. It seems more in the candidate's interest to pretend to work out the solution than to be honest.

Yeah, I've been asked a lot of leetcode questions and always pause for a couple minutes before the answer hits me in a "brilliant" stroke of insight. This con works really well.

It would be more impressive if you solved it right away.

Re: The technical interview is an ego trip

#147

Post by minot »

seanmcdirmid wrote: post #143
TheCapn wrote: post #10

This was my take on interviewing with Amazon at one point a long while ago. The initial interview itself was pretty straight forward, but it seemed like every answer I gave was "wrong" because the interviewer was looking for key phrases instead of understanding of the concepts. We talked about hashing, and when he asked if I knew what hashing was I said sure, its a one-way function to create a unique identifier. He a…

I’ve heard amazon interview experiences are all over the map, just like their teams are. Some are really good, some are really bad at it. Google and Facebook seem to be a bit more of a consistent experience, but interviews are done generically and not by the team that would hire you.

I waited for the last of my four(?) interviewers for like fifteen minutes in their garbage nih Amazon chime thing and disconnected.

I failed my Google interview as well but at least it went better simply because the interviewer wasn't a no show.

Re: The technical interview is an ego trip

#148

Post by roflc0ptic »

leafboi wrote: post #145
jhanschoo wrote: post #141

Earlier quoted context omitted.

Parent wasn't slightly wrong, you just tunneled in on the signature of the operator function, when the reason why parent comment brought it up was to illustrate that the operator function is not necessarily associative, and that the function signature was meant to suggest the difference in associativity. You're wrong about the operations possibly not being commutative; as you pointed out, whether the parameter list i…

Function composition is associative but not commutative. So in essence given three functions z,g,f and composition operator f . g . z != z . g . f (commutativity) which is sort of what fold left or right is doing (but with z g and f being the same function). but: f . g . z == z . (g . f) (associativity) My edit is right about the operations not being commutative. Parent is wrong about associativity as it has nothing…

But sincerely, thanks for commenting. If I'm walking around self righteously asserting incorrect stuff I much appreciate people pointing it out

Re: The technical interview is an ego trip

#149

Post by swatkat »

hashkb wrote: post #109
Impossible wrote: post #73

Earlier quoted context omitted.

It's funny that his expected answer was "Google it". In most cases when people answer with that (it could be the answer for any tech interview question...) you get encouraged to actually do the problem, so it's a time waster. For the interviewer it gives them no signal outside of you having the ability and awareness of the existence of search engines, although there could be some vague behavioral signal that shows yo…

False. We want you to be confident and admit you Google all day every day. Simple as that. You seriously would have done all that before Googling it?

>> We want you to be confident...

Who is this “we”?

Re: The technical interview is an ego trip

#150

Post by roflc0ptic »

pmiller2 wrote: post #139
bradlys wrote: post #126

Earlier quoted context omitted.

> It was a cheap way of figuring out I shouldn’t even consider working there. I mean - all you're experiencing is the HR/recruitment side of the pipeline at that point. You can't really say that an entire company is shit just because some subset of its HR/recruiters do shitty things. How many CTO's actually give a shit about IC interviewing experience and dig into the entire methodology that recruiters use when inter…

Regardless of how many CTOs do care, 100% of them should care. The reason they don't is there's no real incentive for them to care. Outing companies who do things like ghost candidates or have shitty, arbitrary interview processes probably isn't going to be enough to get most of them to care. But, some might, which is why I think it should be a regular practice.

Yeah, you don't need 100% enforcement to enact behavior change. You just need occasional, disproportionate punishment.
Post reply on HN