> What was the answer? Sorry that's not we wanted. We would like to see, how you would solve it with general code. This could have been poor communication on t

> What was the answer? Sorry that's not we wanted. We would like to see, how you would solve it with general code. This could have been poor communication on their part, or it could have been a test of your communication. Was there an opportunity to ask about requirements before coding up a solution? When I interview (usually in person), I encourage candidates to ask questions. I'd certainly never ding anyone for asking "can I use <library X / programming language Y / tool Z>?" but my answer might be no. I'm not a total jerk. When I see candidates make a bad assumption, I'll try to correct them, but depending on the assumption and their communication style that might take 10+ minutes (of 45). I don't want interviews to be about speed, but losing that much time (maybe more than once!) hurts for sure. I'm probably thinking of another candidate who asked the right questions, described an efficient algorithm and its time/memory complexity, implemented it, debugged it, and moved on to something else. Ideally, interviews are a microcosm of the job. And at least in concept, that principle holds here: on the job, people often rush the requirements and design work, which wastes much more time than it saves and/or causes the project to fail.