151–160 of 206 posts
Earlier quoted context omitted.
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.
So I've always wondered about these leetcode interviews, having never suffered one myself, if you're given one you've seen before, are you still supposed to pretend you're working it out from first principles?
Long time ago I go the "Why is a manhole cover round?" at an interview. I prefaced that I heard this question before and followed up with 3-4 possible answers. The interviewer was still impressed.
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…
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)
I agree. We recently got rid of our more traditional "tech screen" and replaced it with a 90 minute realistic programming interview. We have 3 tests we give depending on the role (game dev, backend, or SRE). The tests replicate typical work the engineer would be doing, such as adding functionality to a 2D game, developing out a web service for a given API, or debugging and optimizing a linux server. We provide a deve…
Of course it is, it's a way to gauge whether "someone is dedicated to the job by cramming the algorithms section they haven't touched in years" I've done dozens of interviews and after all of it, I realized there are only four qualities we quantify as useful: caring, ability to listen, ability to learn.
I love this comment, not least because the enumeration leaves one to imagine what level of multi-dimensional punning and irony are being invoked.
I had the strangest technical interview recently. I didn't get an offer, but in every case where that's happened before it's been obvious to me where my deficiencies lie (which I then use to improve in that area). This time I learnt nothing. It was six individual one-to-one interviews, back to back. The first five were an ego trip for me . I was able to do everything perfectly it seems: read code, write code, talk ab…
Earlier quoted context omitted.
Sounds like my Google interview. By the end I had absolutely no interest in working there. Such a toxic environment. The guy they had take me to lunch also seemed completely miserable. Dunno if that was representative of Google or big companies in general but it turned me off forever.
Google had a guy take me to lunch as well. I suppose this is part of their process. I was surprised it was a random developer (a quiet, uninterested, also slightly miserable young guy), rather than someone who was otherwise involved in my (potential) recruitment. It seemed like a lost opportunity for them to get to know something about me other than whether I could do simple coding exercises quickly and accurately un…
Don't know the policy at Google but lunch is usually intentionally supposed to be a break from the interview process. Having somebody grilling the candidate while they are trying to eat defeats that purpose.
> "I am 59 years old, I've been working with code since I was 21 and worked out how to program a significant embedded application on an Intel 8085 CPU using nothing but the manufacturer's data sheets and a simple hex keyboard and display breadboard target."
At a FAANG, nearly everybody has similar stories, so that's not particularly distinguishing.
I'm coming to the realization that there's almost no point in spending time on a lot of the things that I love about being a developer: learning new languages, studying best practices for your tech stack, reading software engineering books, becoming involved in tech communities, keeping up with the latest trends. Interviewers don't value any of that beyond lip service. The only thing worth spending time on is leetcod…
Nail tests, get offer, ask for signup bonus, drop out 3 months later. Repeat.
Earlier quoted context omitted.
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”?