Hacker News Reader

you can often give a company a pass for a shitty interview, but you should name & out them for ghosting you as that is a far more systemic problem indicator. When I'm interviewing I want the poeple we don't hire to go away and have good things to say about us because they will tell many people about their experience. Companies that are disrespectful and inconsiderate to the point of just cutting off contact should pay the price.

Yeah, I'm ambivalent about that. From a purely theoretical standpoint, sure, bad actors should be punished. There's also slim but non-zero chance that they'll reciprocate and attempt to harm my reputation, and we'd end up in some dumb internecine conflict. It's good for bad actors to be punished, but usually irrational to be the one doing the punishing.

Can you come back in a year and share?

I don't think I've ever told anyone about a good interview experience, but I certainly have talked about a few bad ones.

I appreciate whenever I see people in your position get angry about ghosting, but in my experience, for positions that I’ve interviewed for and didn’t get, I think only one ever let me know.

I’ve come to rationalize this as a risk-avoidance tactic, and I think the negative effects of reputations damage to the company are mostly unaccounted for.

I hate that post interview ghosting too. Is super inconsiderate.

I’ve never experienced it before now - how common is this? Is it a west coast thing? This was my first interview with a west coast shop. I don’t need an essay on why they thought it wasn’t a good fit, but radio silence seems eminently unprofessional.

Not sure how common but this has happened to me as well. Coding challenge complete, follow-up interview scheduled... then cancelled. Rescheduled... then ghosted.

It was a cheap way of figuring out I shouldn’t even consider working there.

> 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 interacting with candidates? (And actually keep track of what their recruiters do) I'm gonna give a wild guess and put 0 out there.

In my case, it was a small shop and entirely through direct communication with the manager making the hiring decision. He seemed like a genuine, nice guy, so I'm leaning toward it being evidence that the dude does destructive, avoidant behavior, which is an unsettling tendency in a manager.

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.

Assuming the data structure is a singly linked list than yes it's not stack safe.

At a high level foldLeft and foldRight represent abstraction leakage. The Domain and Codomain for both functions are exactly the same. If there is no performance difference or side effects to consider then there is almost no point in having two fold functions as a plain fold has the exact same inputs and outputs as foldLeft or foldRight.

Typically for side effects you don't want to put it in a fold as you're integrating way too much IO with your functional computations. Rather functional languages tend to have something along the lines of "foreach" for using side effects on the content in a functor. That being said it's strange that scala has a foldLeft and a foldRight with identical performance characteristics. Maybe it's a legacy thing. I dunno, not a scala guy.

Just bringing that up. I still agree with you that the interview question sucked and that the interviewer was wrong. Personally I wouldn't have ever figured out that was what the interviewer was looking for even when I do possess the requisite knowledge.

> 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 [a, b, c].) Not all functions are associative. For example, consider a cryptographic hash function.

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. Unless you have side effects. See: https://www.wikiwand.com/en/Function_composition (search for associative)

I don't know much about crypto but I'm assuming you're referring to things that aren't side effect free. In general though a hash function should be associative under function composition as it is just a surjective mapping from domain to codomain.

Also can't exactly read that syntax nor the stuff below it. Not a scala dude. Maybe a more traditional map implementation in like python or JS pseudo code would make more sense to me, but that may be too much to ask.

edit:

I think you actually may be right. We're both a little wrong with our reasoning though. Function composition is not commutative. And FoldRight and FoldLeft reverses the order of composition which has an effect on operations that are not commutative.

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.

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

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

You're right.

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

> it's a more higher order form of composition

More precisely, a fold performs function composition on the provided operator curried with the respective elements, so that z g and f above are different functions (hence not commutative in general, but associative in general, wrt folding).

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.

> Function composition is always associative.

You're still confused. There is no function composition here.

op in the example above is just some other function, like +. The associativity of + and function composition are true for totally unrelated reasons. Associativity of plus is an inductive argument that follows from the Peano axioms.

Function composition says:

(f o g) o h = f o (g o h)

as functions. It is true because unary function application "serializes" function applications. Formally, I mean:

    ((f o g) o h)(x)
      = f(g(h(x)))
      = (f o (g o h))(x)

Function composition has one value flowing through several functions. Fold has several values flowing through one function.

It's a higher order composition of functors. Lack of Commutativity still applies and is the factor for why the codomains aren't equal not associativity. It's all pedantry though. Overall you're right.

Intuitively the composition is similar enough to function composition that is has the same basic ruleset and is how I'm working out the logic in my head. Think of the functor as a tuple of the accumulator and the value: (acc, x), and the function is just an op that takes in this tuple as a parameter and spits out a new tuple (acc, z) with the next value in the list.

I addressed it earlier here: https://news.ycombinator.com/item?id=24449271

What's happening here is more subtle. The interviewers question didn't carry enough information to get the answer they wanted.

They created a puzzle where you needed to ask for more information. Intentionally or not, they were discovering if they could communicate with you. That the communication failed doesn't mean your somehow less then them. It means you just have a different background.

Now to the problem, the problem people don't set good goals. It probably doesn't make sense to hire a carbon copy of yourself.

Huh. Other than taking the opportunity to talk about tail call elimination, I'm not sure what you could have done to salvage that interview. Bullet dodged, indeed.