Comment by turtlebits

11 hours ago

Understanding requirements means talking to customers. A customer can be anyone, even other devs that consume your code/product.

5 comments

turtlebits

Reply
bdangubic  11 hours ago

“understanding requirements” is as much “wearing other hats” as having hands is “wearing other hats” for a carpenter.

coding is always the hard part, always. whenever I was on any project and we had more work than resource we never hired “people to wear other hats” - we hired people to write code, that’s it. thats the fucking job.

you ever see a leet-code-for-understanding-requirements? yea, me either…

  • necovek  10 hours ago

    You actually do. All of those puzzle-style questions of the sort of "how many liters of water in Mediterranean" ask you to develop a solution with a vague requirement by leveraging what you know roughly to demonstrate you can specify requirements yourself (oh, Mediterranean is roughly 5000sqkm [-> I need surface area], on average 50m deep [-> I need average depth], this gives me A x B liters total) — I'd call these the leet-code version of requirement understanding/development.

    But really, any interview is really about giving you a requirement, and seeing _how_ you understand it, how you clarify it with your stakeholders (interviewers), and then how you address them.

  • turtlebits  8 hours ago

    Carpenters don't just nail things together and expect that to be a usable/useful product.

    If you can't/won't understand what you're supposed be doing, you're either useless or making useless shit.