4 ms·
This. Who wants an employee who never questions the requirements? I can't think of a better way to end up in project management failure than to start writing
by evilneanderthal 17y ago
This.
Who wants an employee who never questions the requirements?
I can't think of a better way to end up in project management failure than to start writing a solution to a problem you don't understand.
- azanar 17y agoWho wants an employee who never questions the requirements? More than you might imagine. Think of all the people you've worked with, in whatever capacity, who never question requirements. It seems likely they will hire people of the same sort, not just because they might have a bias toward the "good" employee being subservient, but because someone who questions the requirements to them will inevitably want them to question the requirements to their superior. They've already spent their career up to this point avoiding this, it seems unlikely they'll take some action now that prevents it.
- logic 17y agoOr, more simply: "A people hire A people, B people hire C people."
- Chocobean 17y agoThen, who hires the B people?
- menloparkbum 17y agoYahoo.
- Chocobean 17y agoactually I was asking in sincerity.
- menloparkbum 17y agoIt was a sincere answer.
- joshwa 17y agothe MBAs who don't know any better (aka C people with money/power)
- azanar 17y agoThat's oversimplifying. Based on a metric of producing code that fulfills the requirements, they may be as much an A player as the assertive developer down the hall. The thought of including assertiveness in measuring employee performance has never occurred to them. You say to them that only "A" players hire equally capable people, but they respond by saying that they are an "A" player. It is the start of an unreasonable argument. Perhaps they should hire for assertiveness, but that's a matter of convincing people that their method of analysis is wrong. That doesn't get solved with platitudes; it gets solved by showing that encouraging assertiveness provide more value that the security of the status quo. How to show this, though, is something I am still trying to figure out.
- fuzzythinker 17y agoA smart superior will always welcome valid questions about the requirements. No matter how bad his requirements may seem after the questions, it is usually better off than finding it out afterwards and letting _his_ superior know of it later. If he is the CEO, his superior is the board or customers.
- neilc 17y agoI don't think the point the original commentors were making was "don't question requirements." It was: (1) Sure, the problem was somewhat unrealistic/simplified. It's just an interview question; you're not being asked to actually build the damn thing, just sketch how you'd build what the interviewer is asking you to implement. (2) Making an initial observation about the difficulty of actually assessing frequency of word usage is great and probably better than just talking about implementation techniques, but the interviewee kept coming back to it, even when the interviewer wanted to move on. That is just obnoxious.
- Periodic 17y agoI think a good middle ground, and a good practice in general, would be to state your assumptions and make sure you recognize them as such. When you know what your assumptions about a problem are then it quickly becomes clear what questions you'd have to ask if you were going to actually implement your solution. Having a solid definition of your assumptions also lets you create a good base for building a solution and determining if it is at all feasible.