872
reason enough to fail the interview
(lemmy.nz)
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 30 Aug 2026
872 points (98.6% liked)
Programmer Humor
33117 readers
56 users here now
Welcome to Programmer Humor!
This is a place where you can post jokes, memes, humor, etc. related to programming!
For sharing awful code theres also Programming Horror.
Rules
- Keep content in english
- No advertisements
- Posts must be related to programming or programmer topics
founded 3 years ago
MODERATORS
The point is that in a real software engineering process, specs and requirements are rarely defined precisely from the start, and the programmer should be able to identify the gaps and clarify them. A generic answer doesn't help as much as a clarifying question.
A common but amateur mistake is to just make assumptions about how something should work and then forge ahead. As a programmer in a company, you are building things for somebody else (your boss, your client), so you need to ask them first.
Sure but as I said, that's a knowledge question and not an engineering problem to solve. They're very different and unless you work in software consulting, you're not gonna get a problem that looks remotely like that from a client.
You actually get them all the time, because the programmer is more deeply knowledgeable about the features they wrote and can identify gaps better.
Boss: "Can we move the widget to the left side of the page?"
Programmer: "Sure but that means when the sidebar opens it will obscure the widget, making it hard to see both at the same time. Do we want that?"
Boss: "Hmm I didn't consider that. Let me ask the UX team what they think."
"Can we move the widget to the left side of the page" is not in the same category as "what is a hash" though?
I don't think the "what is a hash" question was a great example, but paired with the rest of the comment and context, I understood their point