221–230 of 238 posts
Earlier quoted context omitted.
Quoted post unavailable.
you’re the kind of nerd sniper that gets off on this kind of interview style. it’s a well established phenomenon that LC style interviews do little than to fan the flames of the ego for the interviewer.
Well established, where?! In hn discussion boards?!
Earlier quoted context omitted.
You are committing a corollary to the green lumber fallacy described by the article. Just because code challenges are not relevant to job duties doesn’t mean the results are irrelevant to job performance . They are a proxy intelligence test. General intelligence is the best predictor of success in almost any role (not just software engineering). This is what confounds people. They think the interviews are designed th…
> They think the interviews are designed that way because they are supposed to be representative of the job — I don’t believe that’s the case. This may be the case. But even if it does act as an effective proxy--and I'm not sure it does; my worst yeses in interview loops have been very adroit programmers who I passed against my better judgment when my "not sure I want to be around this person every day" bells were ri…
As humans with a strong confirmation bias, it is extremely difficult to tell what's behind your feelings for those worst yeses. It could have been the case that the candidate had red flags, you saw them, but couldn't articulate them. Or it could have just as easily been the case that the candidate had a cultural and/or communication style that was different from your own, and they also happened to perform poorly after being hired. It's important to remember that no interview process is going to yield perfect results: there will be false negatives and false positives, you can only move the trade-offs while simultaneously ensuring that you're avoiding any conscious or unconscious discrimination against protected class to the fullest extent possible. That's a hard problem to solve.
Earlier quoted context omitted.
I do think there's a real place for interview questions where you identify algorithmic opportunities in real world problem scenarios quickly, but you also may be missing some of the incentives for testing the way it's currently tested: Coding floyd-warshal importantly shows that you can code, and generally signals at least one of two things: 1. You studied hard for the interview, you're willing to do difficult and un…
I would say: 1. You're fresh out of school or you have a lot of time on your hands. 2. You memorized some interview preparation book. I do agree that a candidate that has shown some effort preparing for an interview is a positive. Other than that this seems like a silly game. The flip side is the candidate that memorized the book, prepared like it's a test at school, and is useless on the job, can't operate at all ou…
I think this leaves out the possibility of high mastery. I think it is instructive think about algorithm skills as similar to those for algebra. If the most advanced algebra you ever solved was linear equations, remembering how to solve a linear equation may be difficult. However if you're skilled at solving advanced calculus problems by hand, your understanding of algebra is so deep that you could re-derive the process as necessary. Many of us with a lot of math experience will never forget how to solve linear or quadratic equations barring steep cognitive decline and this is also so true for certain classes of algorithms. Personally, I've studied graphs and graph algorithms beyond what you might find in just CLRS or other introductory algorithms textbooks and as a result I can re-derive many classic graph algorithms on the fly, no memorization necessary. I have done this interviews as have people I know.
Earlier quoted context omitted.
> Not to split hairs - but it does seem to be a peculiar choice of words, there. Perhaps not; I think the "publicly viewable" part is going to the sticking point, most of the time. Most people don't have significant/impressive side projects that they can show off to prospective employers, their work is at prior companies. Anyway, I can see why DSA interviews are popular. IIRC studies show IQ tests and work sample tes…
Yeah, that's what I see it as -- in part as a quick stand-in for a higher-end IQ test (or whatever of one wants to call "innate" intellectual ability). As well a way for the company to signal that of course they're all of very high innate intelligence themselves, and they know how to test you for it, too (by asking you to do what amounts to a few carefully rehearsed parlor tricks). And lastly, as a cathartic bonding…
Nah. Parlor tricks would be the old riddle questions about manhole covers and light bulbs being warm. It's difficult to gain competency in algorithmic whiteboarding questions without being smart and at least half decent at coding. They're not perfect gateway questions, but most of the alternative suggestions I've heard here or on Reddit are worse.
> And lastly, as a cathartic bonding ritual: "You went in on this high-pressure, slightly (or sometimes very) humiliating performance rite with us together and it looks like you've passed! Or at least it seems now you do not have completely damaged DNA. Now we are ready to forgive and accept each other as equals, or some approximation thereof."
Having worked at Amazon and Google, I really don't see this. People bond over other parts of the company culture, but the entry process, not really. I guess people do talk about the painful Google recruiting process, but that's mostly how fucking long and drawn out it is, people don't seem to really mind the questions themselves overmuch.
Earlier quoted context omitted.
> The reason is that programming tasks like this are pretty uncommon to encounter as a professional software engineer. I'm not so sure. One aspect is even recognizing that the task can be done by a known algorithm. Not knowing the algorithms may make one mistakenly believe that the opportunity to apply algorithms never came up. > I can’t imagine that you would need to build a binary tree data structure or an algorith…
They are trivial to implement, but not desirable if you want your project to integrate with the company's existing codebase and be able to draw on a large base of preexisting algorithms. A company like Google/Facebook(Meta)/Amazon doesn't want many redundant copies of binary tree implementations per language in their code base. In general they'd want one implementation with a suite of algorithms that can operate on i…
I agree with you about things like "convert this string to a number", where it's too easy to get wrong (like not handling overflow) or be inefficient. But binary trees (and linked lists), like I said, are so trivial it is just not worth the bother.
I've heard bitching about some of the interview questions our team asks before, but here's the thing: each of those questions is about a problem our team actually had to solve before, reformulated into an interview-style question. Yes, we've had to use Hamming distances, worry about the scaling (N log N vs N^2) of particular solutions, use error-correcting codes, interesting data structures and all of that. Is that m…
What kind of stuff does your team work on? Seems like you have to solve a lot of diverse problems.
It's interesting work.
I've heard bitching about some of the interview questions our team asks before, but here's the thing: each of those questions is about a problem our team actually had to solve before, reformulated into an interview-style question. Yes, we've had to use Hamming distances, worry about the scaling (N log N vs N^2) of particular solutions, use error-correcting codes, interesting data structures and all of that. Is that m…
> each of those questions is about a problem our team actually had to solve before On my last job search I had one interviewer state (very proudly) the systems design question I was being asked was an actual problem his team had to solve. I don't doubt the veracity of his claim at all, but it probably wasn't solved by a single person under the time constraints and pressure of an interview. Most likely someone on that…
So in the context of an interview, I'm trying to treat the interviewee like a colleague who I'm coming to with a problem I'm having, so we can come up with a solution together. That often involves drawing things out on a whiteboard: not code, but more diagrams to describe the problem. Then we come up with ideas on how to do it, under various constraints that I share.
Usually I have in my pocket 2-3 different approaches that we tried when we did it ourselves, and I'm looking for: can you understand the tradeoffs between these different approaches, do you understand how they work, and are you capable of implementing them to test and cross-compare them?
Earlier quoted context omitted.
When it comes up do you need to code it up in 20 minutes or is looking the algorithm up in a textbook ok? If all you want to test that sort of knowledge just ask the knowledge question. I don't need to memorize Floyd-Warshal and be able to code it on demand to be able to recognize when it's needed and look it up. I'm sure I remembered it back in school, haven't used it since, but if the day comes I'll look it up...
Quoted post unavailable.
Earlier quoted context omitted.
> each of those questions is about a problem our team actually had to solve before On my last job search I had one interviewer state (very proudly) the systems design question I was being asked was an actual problem his team had to solve. I don't doubt the veracity of his claim at all, but it probably wasn't solved by a single person under the time constraints and pressure of an interview. Most likely someone on that…
The context is more like this: we regularly have internal brainstorming sessions when we run up an interesting or tricky problem, to come up with ideas on how to solve it. So in the context of an interview, I'm trying to treat the interviewee like a colleague who I'm coming to with a problem I'm having, so we can come up with a solution together. That often involves drawing things out on a whiteboard: not code, but m…
So a lot of the more complicated DS&A questions seem ridiculous, but I had to check on "inverting a binary tree" to see if it was really as simple as it sounded. It is. Just swap left and right, recursively. It's one of the easiest possible tests of being able to grok recursion[0]. You should be able to do this, even if you're self-taught or early in a college degree program. Am I missing something? The only excuse I…
I agree with this. But asking the candidate to invert a binary tree is one thing and asking the candidate to flawlessly solve back to back leetcode "hard" level problems is another. I think the latter is mostly what people lament, where you end up doing so much prep that it boils down to "I've seen this one before" and you proceed to regurgitate what you memorized.