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

▲

bdangubic 4 hours ago | parent [-]

“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 3 hours ago | parent | next [-]

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.

	▲	bdangubic 3 hours ago \| parent [-]
		URL please?

▲

turtlebits an hour ago | parent | prev | next [-]

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.

▲

Jach 3 hours ago | parent | prev [-]

Thanks for giving me a laugh, I was just imagining https://programming-motherfucker.com/ as an absurd "Hat-wearing, motherfucker" site instead.