9 ms·

Tough Crowd

• comatose_kid 18y ago
  As soon as I saw the title of the post, I was pretty sure what you'd be writing about. I thought the similar things when reading the discussion. One thought that went through my mind was: this kind of negativity doesn't really reflect well on the community.
• ianbishop 18y 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 18y 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 18y ago
      Who 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 18y ago
        Or, more simply: "A people hire A people, B people hire C people."
        • Chocobean 18y ago
          Then, who hires the B people?
          • menloparkbum 18y ago
            Yahoo.
            • Chocobean 18y ago
              actually I was asking in sincerity.
              • menloparkbum 18y ago
                It was a sincere answer.
          • joshwa 18y ago
            the MBAs who don't know any better (aka C people with money/power)
        • azanar 18y ago
          That'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.
    • neilc 18y ago
      I 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 18y ago
        I 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 18y ago
    This 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 18y ago
      I 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.
• ph0rque 18y ago
  One thought that came to mind is this: why not answer with, "I have a straightforward, textbook answer, but also some thoughts/questions about your assumptions in the question. Which is it that you're looking for?" (Note: this question would be asked in a friendly, collaboration-seeking tone of voice/body language.)
  • ionfish 18y ago
    I think you're confusing friendliness with subservience.
    • jeffesp 18y ago
      I would agree. As an aside: Isn't the subservience part of what many employers are looking for? I think some are even looking for it legitimately. Of course those aren't the best place to work. I have always felt like there is a fine line to be walked here (as an employee).
      • azanar 18y ago
        Isn't the subservience part of what many employers are looking for? I think some are even looking for it legitimately. It is. Even more astonishing, at least to me, is that it is what some, maybe even a lot of, employees are looking for as well. Without an employer, or someone who they can submit to the authority of, to tell them what to work on when, they would be miserable and directionless. They crave structure, but need someone else to define it for them. They also become quite incensed when someone wants to remove that same structure because it gets in their way. Some jobs allow or require a certain amount of this. Generally, it is jobs that are part of an established process, like manufacturing, that just needs someone to repetitively perform a particular step with reasonably consistently. This might be true of most jobs. Other jobs do very poorly being treated as part of an established process. But people will select candidates for that anyway, because it works in the average case. The result of this is attempting to swaddle process around something inherently without process, just so the people involved can feel comfortable with the structure that guides their work. It does mean that productivity tends to suffer as a result of all of the process requirements, but many employers and employees consider it a worthwhile trade-off. I get the sense that it's not that the line is fine, but that so many people toe it so tightly that, to someone who doesn't, it looks fine by comparison.
• hcayless 18y ago
  In my experience as an interviewer, the original post was an example of what I always hope for--when the interview turns into a real discussion, and you're able to gain insight into the interviewee's character as well as his/her technical prowess. I always ask a mixture of open-ended and technical "quiz" questions. More than that, I was a bit baffled by the negative responses. Willingness and ability to examine the assumptions behind a task are attributes I want in teammates.
• keefe 18y ago
  'The interviewer wanted him to give a technical answer to a technical question, not enter into a discussion about what "The ten thousand most-used words in the English language" actually means or whether it's feasible to collect a corpus of such words.' Is it not technical to consider the sample size of your data? It's not even interesting how you do the +1 to the frequency count of a given word if the # of words get huge - nobody has any business talking about hash table collisions blah, it's too low level. I'll estimate a half million english words and use the Java hash table or a database with a words table, now I will setup my web crawler to get data... but how do I know what text is a word and is not? That is actually the only interesting bit of that question! So first I need to scrape dictionary.com and then start spidering say livejournal vs msnbc vs whatever. If someone talks about hash table collisions for this problem, they are likely to suffer from "not invented here".
• lacker 18y ago
  The author of the initial post did make some technical mistakes. Here's one that jumped out at me - "What will you do in the event of hash collisions?" the professor asked. "How do you know there will be any?" I said. "Look, the English language only has a million words. We're hashing a million words into a table that can hold four billion. The load factor on the table is negligible. If we're getting collisions it means we need a better hash algorithm. This is intuitive but incorrect. The principle is also known as the birthday paradox - http://en.wikipedia.org/wiki/Birthday_paradox http://en.wikipedia.org/wiki/Birthday_paradox If you hash a million words into a 4-billion table, you do expect collisions. You expect to get collisions when you insert on the order of the square root of the size of the table, and the square root of 4 billion is much less than a million.
  • patio11 18y ago
    If we're getting collisions it means we need a better hash algorithm. It would hardly be the first time. The hash function which is the default for Java strings, for example, sucks. int hash = 0; for (int i = 0; i < length(); i++) { hash = 32 * hash + charAt(i); } return hash; (Lots of collisions on any English dictionary unless you use huge numbers of buckets.) This actually had important implications for a project I once worked on, in exactly the manner you would expect it to have implications for this interview. The difference was that, in meetings about this issue, I did my best to a) give the customer what they needed and b) did not give the impression I was saying "Screw what you want, I'll tell you what you need". The birthday paradox problem, by way of comparison, is negligible for this use case. Words in English follow a zipf distribution (you may hear "long tail" more these days). If there is a collision, it is overwhelmingly likely to be between two words on the long tail (no impact to first 10k words) or between a word on the fat head and the long tail, in which case you're overwhelmingly likely to encounter the fat head word first, and even if you don't, whoopsie 1/100th of a percent of your output was corrupted. Wow, twice in one day natural language processing has reared its head. Thats more than in my last two years! Booyah, old interests.
• Tichy 18y ago
  What exactly is the problem? Some people would have hired the guy in question, others wouldn't have. Why can't they both be right? Tastes are different, and no two companies are the same.
  • raganwald 18y ago
    No problem, just my surprise at the overwhelming mass of comments criticizing the poster. I'm not saying his actions were perfect, but similar posts in the past (such as "Stupid Interview Questions") elicited a much more balanced split between criticizing the interviewee's actions and criticizing the interviewer's actions. I just expected something else from the aggregate of responses, which is not the same thing as disagreeing with any one individual response.
    • Tichy 18y ago
      In a real world situation people's reactions might have been different. I guess it is just easy to interpret different things into a written account of the interview (like "arrogance").
      • raganwald 18y ago
        My surprise was at the aggregate tone of the posts being about the interviewee and almost nothing questioning why the interviewee kept hammering away at the pre-conceived point of the question. But I don't have any issue with any one individual person's conclusion.
• xilun 18y ago
  The real problem with the author of the initial post was that not only he had an "attitude", but he even was technically quite incorrect (he could have done worse, but still...), and not just once! The collision fundamental misunderstanding was really not forgivable :/ Had he been technically correct, the whole non-stop "your question is really too imprecise" thing and perhaps even maybe the stinky "oh my God, the interviewer does not even know the XORBLUB algorithm" one would be more tolerable. But in the context of his own report of the interview, he is just pedant and not that smart...
• space_cowboy 18y ago
  Did he just use a french word to close one section, and a latin phrase to open the next ("fin" and "post scriptum")? That bothers me.
  • deleted 18y ago
    [deleted]