Tough Crowd(github.com)
github.com
Tough Crowd
http://github.com/raganwald/homoiconic/blob/master/2009-05-13/tough_crowd.md#readme
9 comments
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.
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.
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.
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.
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.
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.
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.
(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.
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.
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.
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.
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.
Or, more simply: "A people hire A people, B people hire C people."
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.
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.
Then, who hires the B people?
the MBAs who don't know any better (aka C people with money/power)
A 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.
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.
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.
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
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.
"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
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.
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.
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.
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.
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.)
(Note: this question would be asked in a friendly, collaboration-seeking tone of voice/body language.)
There are two subjects: How to interview, and how to be interviewed. Say we were talking about wearing a tie. My post would be about why you don't want to require ties in interviews. Your comment is that if the company might require ties, it might be sensible to ask them what to wear before showing up.
I think that your suggestion and my post can coëxist happily.
I think that your suggestion and my post can coëxist happily.
Thinking about this from the interviewee side of the table, the answer I am given to this would provide me with a concrete datapoint about the culture I would be entering into. Is this a place where we are constantly seeking out better understanding of problems to come to better solutions? Or is this a place where the problems are not my concern, solutions are already determined before my involvement, and my role is just to grind out specifics of how that solution ought to be implemented? It might not play out that way if/when I'm hired, but it would be a big red flag depending on the answer.
From the perspective of the interviewer, I would worry about the interviewee who asks me this question. Do the feel the need to ask permission every time they want to explore the problem space? How often will they have a concern, but wanting to not appear confrontational or difficult, they don't even ask for permission to raise the concern? This may be good for workplace harmony and short-term image maintenance, but it sucks as a long-term strategy for corporate success and personal fulfillment and advancement. I realize this is in a person's socialization, and habits they form from interactions with past management. I also realize that other potential future employers would view this entirely differently; this is a sign this person is capable of fitting into a corporate culture where people just do things. This is a warning sign that this candidate would not work out well in any culture I could see myself hiring people into.
It seems a better strategy to just behave for the corporate culture you would want to be hired into, and let the ones that dislike your approach kick you to the curb. You’d probably be unhappy there once you were hired on anyway.
From the perspective of the interviewer, I would worry about the interviewee who asks me this question. Do the feel the need to ask permission every time they want to explore the problem space? How often will they have a concern, but wanting to not appear confrontational or difficult, they don't even ask for permission to raise the concern? This may be good for workplace harmony and short-term image maintenance, but it sucks as a long-term strategy for corporate success and personal fulfillment and advancement. I realize this is in a person's socialization, and habits they form from interactions with past management. I also realize that other potential future employers would view this entirely differently; this is a sign this person is capable of fitting into a corporate culture where people just do things. This is a warning sign that this candidate would not work out well in any culture I could see myself hiring people into.
It seems a better strategy to just behave for the corporate culture you would want to be hired into, and let the ones that dislike your approach kick you to the curb. You’d probably be unhappy there once you were hired on anyway.
Would this be something you'd do in a real-world situation? Or would you question the requirements and the need for such a feature?
I'd be doing the latter, so why should I have to behave differently during an interview?
I'd be doing the latter, so why should I have to behave differently during an interview?
I agree with you, but an interview is not quite "the real world", which is something that all the parties involved realize.
That is, I think, the problem with posing a question like this. I can only speak about what I'd do. This question would kick my mind into "real-world" mode. I'd want to compare alternative approaches and generally talk it out.
If this is not what the interviewer wanted, they'd be better served by asking a slightly more fantastical question that would still show problem-solving skills. Also, the interviewer should qualify the question by saying that "this isn't a real world situation, I just want an algorithm". I don't know how someone would react to that situation.
If this is not what the interviewer wanted, they'd be better served by asking a slightly more fantastical question that would still show problem-solving skills. Also, the interviewer should qualify the question by saying that "this isn't a real world situation, I just want an algorithm". I don't know how someone would react to that situation.
I think you're confusing friendliness with subservience.
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).
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.
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.
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...
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...
'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".
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".
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.
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.
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").
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.
But I don't have any issue with any one individual person's conclusion.
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.
That bothers me.
[deleted]
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?