4 ms·
I actually was thinking the same thing when I scanned over the comments for this article. One reader wrote something similar to, "it seems like you fell for eve
by ianbishop 17y ago
I actually was thinking the same thing when I scanned over the comments for this article. One reader wrote something similar to, "it seems like you fell for every trap the interviewer put out".
What trap? Thinking before speaking? Someone who answers general, ambiguous questions with a general, ambiguous answer cannot be much of a programmer. Aren't we trained to do just the opposite after all?
- evilneanderthal 17y agoThis. 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.
- old-gregg 17y agoThis is strange... Suddenly everybody agrees with raganwald. Who's been posting those negative comments then? In my experience, technical interviews are always about passive-aggressive attitudes and open demonstration of "I'm smarter than you are, now prove me wrong" mentality. Every single interview I've been at was just like that. I remember one guy asked me "do you even write unit tests?" to which I gave up and honestly answered "why are you even implying that I don't?". This was one of the first questions and the dude had absolutely no ground for phrasing his question this way. For god's sake, ask me about my favorite book, or about my favorite computer scientist, or about my favorite programming language - there is so much you can talk about figuring out what kind of an engineer I am. A typical programming interview is a sham: an interviewee googles questions and an interviewer googles answers, and the job offer comes as a positive probability of them googling the same thing. And the most ridiculous thing of all, is that more often than not, after drilling you on various hashing techniques and optimizing tricky algorithms in space and time and quick-sorting bible on a whiteboard, they'll assign you to a high-school level job - pushing SQL statements and HTMLizing the output, web 2.0 style. Yikes.
- Periodic 17y agoI have to agree with the passive-aggressive mentality being common. I think all the nervousness surrounding interviews shows how adversarial they are. For how aggressive some interviewers are, I believe half of that aggression comes from the interviewee. If they start with some passive-aggressive questions and you get defensive then you're just as much a barrier to communication as them. When you read someone else's answer to an interview question and are struck by how well they answered it is rarely because they had a witty answer that stunned the interviewer, but rather that they were open, honest, and entirely non-aggressive and so were able to show how smart they really were.