Tough Crowd
github.com
github.com
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?
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.
(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.
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.
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.
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.
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.
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.
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.
"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.
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.
(Note: this question would be asked in a friendly, collaboration-seeking tone of voice/body language.)
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.
I think that your suggestion and my post can coëxist happily.
I'd be doing the latter, so why should I have to behave differently during an interview?
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.
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.
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...
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".
But I don't have any issue with any one individual person's conclusion.
That bothers me.