3 ms·

When I see someone complain about how programming in interviews isn't practical, most of the time that tells me that they haven't spent any time thinking about

When I see someone complain about how programming in interviews isn't practical, most of the time that tells me that they haven't spent any time thinking about the difference between programming talent and programming knowledge, and have been coasting by in a world that elevates mediocrity. Do whatever makes you happy, but as an interviewer I see far too many "experienced" candidates who show themselves to be absolutely garbage at conceiving, planning, structuring, and writing code all while complaining about how impractical it is to be asked to show me that they aren't bullshitting their supposed proficiency. You can get all the brownie points you want for having 20 years of experience when I start seeing that years of experience make more of a difference than they currently do in this godforsaken industry.

WalterSear 2y ago
And how does memorizing leetcode patterns demonstrate that?
- BugsJustFindMe 2y ago
  I think it says bad things about the industry that so many people think you need to have seen them before to do them. Do you also memorize solutions to the advent problems before completing them?
  - WalterSear 2y ago
    I don't have to complete advent solutions in 20 mins while someone waits for me to demonstrate any reason to cut me from the 10 others they are interviewing that week. The problem is psychosocial, not technical. I'm not necessarily going to lose out to a better engineer, but a better leetcoder - I'm objectively terrible in leetcode interviews, unable to put two sentences together. I can code fine. I've practiced enough leetcode problems to be fine with them too. Just not in interviews. But, you didn't answer my question. It says bad things about the industry that so many people still lack the insight to see the disconnect between performing well during social evaluation and effective software engineering. It's been decades now.
jakebasile 2y ago
The problem (other than your casual insults) is that leetcode does not demonstrate the ability to conceive, plan, structure, or write code. The whole method behind it is nothing but rote memorization of trivia questions, almost all of which are pulled from one or two websites. There are piles of books made specifically to help people memorize the solutions to these puzzles. This has nothing to do with actual software engineering work which very rarely involves rote memorization. A far better approach is to talk through the design of a system - conceptual or previously worked on and ask questions about it. Strike up a conversation with the person. I find it extremely easy to tell if a person knows what they're talking about and enjoys the subject _on subjects I am familiar with_, which is quite common in the situation where I am interviewing someone to join my team.
- BugsJustFindMe 2y ago
  When the OP gives any kind of examples of interviews gone bad, maybe we can discuss something meaningful. But the moment someone says they object to programming challenges that aren't "practical", that raises huge red flags. Too too too many people call simple programming demonstrations "irrelevant" and "impractical" and "not realistic" and "leetcode" and then proceed to show that their brains are mush, that they lack the talent for understanding code and what it's doing and why it was written and how to write it themselves. It's a meme at this point for people who call themselves software engineers to complain about being asked to write code because they're above it while simultaneously being terrible at it. > A far better approach is to talk through the design of a system - conceptual or previously worked on and ask questions about it. Hard disagree. It's far too easy for people to talk about concepts without having a brain that understands code well. That's the difference between knowledge and talent. A talking approach may find knowledge. I'm looking for talent.
- gcheong 2y ago
  "design of a system" The open-ended system design interview comes after the initial leetcode interview now.

WalterSear 2y ago

And how does memorizing leetcode patterns demonstrate that?

BugsJustFindMe 2y ago
I think it says bad things about the industry that so many people think you need to have seen them before to do them. Do you also memorize solutions to the advent problems before completing them?
- WalterSear 2y ago
  I don't have to complete advent solutions in 20 mins while someone waits for me to demonstrate any reason to cut me from the 10 others they are interviewing that week. The problem is psychosocial, not technical. I'm not necessarily going to lose out to a better engineer, but a better leetcoder - I'm objectively terrible in leetcode interviews, unable to put two sentences together. I can code fine. I've practiced enough leetcode problems to be fine with them too. Just not in interviews. But, you didn't answer my question. It says bad things about the industry that so many people still lack the insight to see the disconnect between performing well during social evaluation and effective software engineering. It's been decades now.

jakebasile 2y ago

The problem (other than your casual insults) is that leetcode does not demonstrate the ability to conceive, plan, structure, or write code. The whole method behind it is nothing but rote memorization of trivia questions, almost all of which are pulled from one or two websites. There are piles of books made specifically to help people memorize the solutions to these puzzles. This has nothing to do with actual software engineering work which very rarely involves rote memorization. A far better approach is to talk through the design of a system - conceptual or previously worked on and ask questions about it. Strike up a conversation with the person. I find it extremely easy to tell if a person knows what they're talking about and enjoys the subject _on subjects I am familiar with_, which is quite common in the situation where I am interviewing someone to join my team.

BugsJustFindMe 2y ago
When the OP gives any kind of examples of interviews gone bad, maybe we can discuss something meaningful. But the moment someone says they object to programming challenges that aren't "practical", that raises huge red flags. Too too too many people call simple programming demonstrations "irrelevant" and "impractical" and "not realistic" and "leetcode" and then proceed to show that their brains are mush, that they lack the talent for understanding code and what it's doing and why it was written and how to write it themselves. It's a meme at this point for people who call themselves software engineers to complain about being asked to write code because they're above it while simultaneously being terrible at it. > A far better approach is to talk through the design of a system - conceptual or previously worked on and ask questions about it. Hard disagree. It's far too easy for people to talk about concepts without having a brain that understands code well. That's the difference between knowledge and talent. A talking approach may find knowledge. I'm looking for talent.
gcheong 2y ago
"design of a system" The open-ended system design interview comes after the initial leetcode interview now.