He appears to be good at algorithms, has a feel for the actual space and time requirements, is able to think under pressure, and has a sense of humour.
- chasing an irrelevant point (the interviewer specifically wanted to move on. NEVER stop that, that is the one single that can cost you a job).
- assuming importance (his tone suggests he thinks he knew more than the interviewer. I imagine that might have come across in the interview)
- assuming ingorance (if it seems amazing the interviewer is clueless on something then it probably isnt true. Adjust appropriately.)
- chasing the wrong issue (if an interviewer needs to draw an answer out - even in a fluid way like that - it will be a black mark on your notes)
- assuming irrelevance (his opening remarks suggest he though the question was not relevant to the interview he was having, which suggests he possibly did not treat it with the same gravity. Everything is relevant - the more off the wall the question the more important your answer is).
There are more but those were the key points I picked up: not being there and only having his side of that short portion I cant say 100% he fell into every one. But it definitely looks that way :)
This is based on similar traps I set up for our interviewee's.
The idea of "traps" is ridiculous and shows us how little some companies understand about the interviewing process.
As an interviewer meeting potential candidates YOU are representing your company. If you're acting false and laying little traps etc. and your candidate detects this, you could lose a very smart and productive person simply because acting falsely is a natural turnoff.
On the other side, if the candidate is answering questions in some sort of rehearsed way it'll be a turnoff for the interviewer.
Good interviews are no different than meeting people. As a candidate, be yourself, don't worry about silly traps. Your goal is to show them who you are and find out who they are to see if there's a fit. If you've already decided you want the job before meeting with their representatives then you're potentially making a bad decision and wasting your own and other people's time. If you're egotistical and feel a need to point out that a question is useless, then by all means do so! That way they know what they're getting and can make an informed decision about whether or not they can deal with that. You may want to work on the ego a bit in general, but not specifically for an interview... that would be fake.
Don't try to con your way into a job because there's a very god chance you'll be unhappy if you get it.
Don't be fake and cagey with candidates because ultimately you could scare away some really excellent employees. Intuition is important as an interviewer so you can detect when someone's being fake with you without being a weirdo yourself. Ask questions you actually want answers to instead of trap / fake questions.
The whole fake / fake thing just perpetuates itself and makes it next to impossible to find good fits. It should just be common sense without all this complicated trap nonsense.
Well.. perhaps "trap" is the wrong word. Or rather "designed trap" is the wrong concept.
But when answering a question there are, surely, natural traps an interviewee inevitably has to avoid. And not doing so is a potential black mark the interviewer has to watch out for.
That said your argument is fair - and I'd probably agree. But I di think laying intellectual traps can be appropriate. It really depends on your candidate and the interview: if you go into an interview (either as the interviewer or the interviewee) with any form of fixed agenda then, yes, things are going ot be fake and plastic (90% of the interviews I went to were like that). You adapt to the situation: if you candidate is showing intellect and sharpness you test that and start a sort of push-pull intellectual "battle of wills". If he detects that and doesnt like it he is not the candidate for me - I would hope he detects it, calls us on it and avoids the "traps". THAT is a good candidate, for me at least :)
You're right that he did "wrong" things from the perspective of trying to please the interviewer.
Personally I would have walked out if I got a negative vibe from the interviewer during this. Questions like this are deliberately obnoxious bullcrap pulled by recruiters and interviewers who don't understand what they're actually after in a candidate.
Everything that you want from a good software engineer (requirement refinement, minimal-effort-maximum-payout planning, awareness of a large variety of domains relevant to your company's business) was expressed by this person's response. You want these things in a candidate because they are the hardest things to find in a good candidate. But the interviewer didn't actually want real-world skills and a real problem solution, they wanted some arbitrary, bullcrap pseudocode up on the whiteboard. This kind of bullcrap pseudocode doesn't actually tell you if the person can or can't code, so it's utterly pointless.
I've walked out of interviews and refused job offers for less egregious examples of this kind of nonsense. It doesn't bode well for the company when they're so scatterbrained and insecure that they can't handle someone who actually takes your question seriously.
"Personally I would have walked out if I got a negative vibe from the interviewer during this. Questions like this are deliberately obnoxious bullcrap pulled by recruiters and interviewers who don't understand what they're actually after in a candidate."
Especially if it's for a candidate for a tech writer position. In that case, I'd say that the interviewer was the idiot here.
The problem is not real world. The data is not real world. The solution is not real world. The entire dialogue is a fantasy. So why even engage in it? Were you expecting something real-world from it?
It was an interview. You're being unreasonable to put someone under an already high-stress situation and then saying, "Now we're going to conduct an extremely difficult experiment where you try to come up with the solution to a difficult problem in one fell swoop without any of the usual access to reference and the opinions of your peers."
It is bullshit, plain an simple. A bizarre artifact of a world where people have extreme difficulty evaluating software engineering skills. It bears no resemblance to how people in the real world write code or engineer solutions.
If you wanted real world examples why not put a pre-requisite to the interview to bring in working code that does what something relevant, and then discuss it in the interview? That's a far more realistic scenario with far more useful data than this little play-acting show that you're describing.
When I operate as the interviewer, I look for responses like the one the blogger gave at the beginning, where they start to really analyze the problem domain. People like this save millions of dollars in software engineering costs because they can look at the scope of a request and start to refine it (or outright reject it if it is unreasonable and they can cogently explain why it is so). To say these qualities are a "turn off" blows my mind. This kind of attitude is nearly as bad as the attitudes expressed in the reviled modern-google-interview, and competent software engineers who are not desperate for a job would do well to refuse to tolerate it.
After all, an interview is as much for the interviewee as it is for the interviewer. Most of the time, getting to an interview like this means that the company in question thinks you might be a good hire, and they're hiring to fill a void in their ranks. The interviewee is far from powerless.
Real world examples dont work because, as this post points out very well, there are just too many variables and factors to allow anyone to produce a viable solution in the space of an interview.
The problem IS real world though: I can think of several situations in our own company where a programmer would have to manipulate a set of data, find common occurences and order them. Of course each specific problem is complicated by the data and the data source but the fundamental problem stays the same: and so the question IS valid.
The input data doesnt matter (though briefly recognising it is flawed instils confidence).
In terms of your other point about how people write code.. im not 100% sure I agree. As an engineer I break a problem down into I/O machines. Where the input comes from is immaterial so long as it is in a form that is usable. The important consideration is engineering the output.
Your right: he did see the problem with the suggested data set and that is the kind of thing that saves companies money. BUT he hammered that like it was the only issue and (by his own admission) barely considered the actual practical engineering problem. To me that would tell me he is a fairly ok programmer and is bright enough to spot problems - but he is no engineer and I wouldnt hire him :) (that said it is only a small subset of the interview and based on other stuff I have read from the guy I suspect I would find him suitable to hire: he just screwed up the one question)
Absolutely untrue. In the business world, software developers primary reason for existence is to improve the bottom line. Sure, writing good code for existing business processes is the primary route. But due to our nature of not being encased in the traditions of the departments we are creating applications for, and having knowledge and workings with various parts of the organization as a whole, we get to see a lot more of the big picture in minuet detail than almost anyone else in the company.
Numerous times have I been in situations where no one stopped to break down the problem before jumping to a solution. I've seen people so fixated on a solution that they cost the company hundreds of thousands of dollars for a problem that upon minimal scrutiny became apparent that it did not apply to our organization (hurray for tax codes.)
Users come to us describing a solution to the problem that they are experiencing. We can take their word for it, and hop to on making the solution. But it also presents an opportune moment to get people to wait a second, to look at the business process, and possibly to solve the problem through a minimal change in process as opposed to the creation of a whole new software application.
Pushing the issue in such a way takes a fair bit of self confidence and even a touch of ego. Maybe the original poster was a bit over zealous in his questioning of the problem, maybe he could have questioned the problem in a more constructive way. But the fact that he was questioning the problem, IMO, is the sign of a good developer.
It is a fine line though. And putting up too much resistance or negativity will quickly get your resume round filed.
I would disagree Errant. If the problem was "Organize a list of 1 million words", then I would agree with you. With no context, it becomes little more than an academic problem.
But by giving the problem a context, the interviewer is asking for a much larger answer. In the case of this question, dealing with the most common words in the English language, the consumption of words is likely going to be significantly more difficult and critical to the accuracy of the final product than the sorting and hashing algorithms.
If the goal of the question was to determine the applicants knowledge of sorting and hashing, then the question should have been stripped of context and presented as a purely academic "sort 1 million words by usage." question.
On the other hand, if the goal of the question was to determine how the application approaches a problem, then his act of questioning the problem was a success, although the etiquette of his approach may have been a failure.
Im not sure though: the problem was as broken down as you can pretty much get. The dataset could have been anything - the problem was to order the top 10,000 words. The input data was, at the end of the day immaterial. It is a problem to be solved in another engineering "block" (im not suggesting, in case that was the miscommunication, that is shouldnt be solved).
The last 2 paragraphs of your reply I would agree with :)
Yay abuse.... you should see some of my other writing: dyslexia really takes it's toll when you cant see the difference between "many men" and "man ymen" (a mistake I made last night) even when you read it back. It makes teeny tiny grammar errors like that immaterial ;)
Take your abuse elsewhere: I am happy to debate my points but at least bring something constructive.
I'm not meaning to be abusive here, but I would highly recommend a spelling and grammar checker plug-in/add-on. There are many solid options available to both IE and FF. Being a person with dyslexia, and obviously knowing how critical clear communication is, it would be responsible of you to use such a tool to reduce the likelihood of confusion.
Thanks - not abusive at all :). Actually firefox for some obscure reason wont spell check me any more - possibly I am tbeing lazy not fixing it. I long ago developed some default checks on my writing to make sure spelling made sense (it only really breaks down now when im tired). But to the point of this reply: can you recommend a grammar checker for FireFox? Embarrasingly I cant find one on the addons site :(
"It's" is a contraction of "it is." You mean "its" -- the possessive form.
Another black eye for you; another feather in my cap!
(Seriously, though. You're demanding tolerance of your cognitive differences -- which is perfectly reasonable -- but also asserting that engineers should approach problems by breaking it into finite automata, GIGO be damned. This strikes me as odd.)
Im not demanding anything. What I am saying is that resorting to attacking that (which has very little relevance to the discussion at hand) isn't going to win you the round. ;)
To defend my statement: I explained how I, as an engineer, break a problem down. Pretty much every other engineer I know uses much the same approach (and when I hire I look for the same skill because it fits into our team) - but it's, of course, not the only way. Each to his own.
Seriously: if your going to call out my english at least read and understand what is written ;)
Nit picking over language isn't making a point for you: it'simply suggesting you dont have a decent counter argument. Someone else posted a convincing one - you should give it a read :)
Your a "newish" commentor so I guess you havent learned the culture here :) I made the same mistake once. It's cool no harm done.
He as pointing out a potential inconsistency in your posts very subtly and politely, compared to how I would have done it.
I am a software engineer and I do not work the way you are describing. I take the actual problem to be solved very seriously and try and solve that in the most minimal way possible while leveraging and reusing existing code. I suppose I am not hired because I work differently. I've fallen into your trap of not designing complex systems in a stressful situation the way you expect me to.
So in revenge all my interviews now require a properly spelled and gramatically correct 5k word essay. It's just as arbitrary as what you've proposed. It is my "trap", which is your code word for "unreasonable and inscrutable expectation."
your assuming I wouldnt spell check a 5K essay and therefore would dail such a test... ;)
EDIT: as I mentioned elsewhere people do do things in other ways (though you seem to be suggesting my approach might not take a problem seriously??) and there ain't anything wrong with that. At no point did I say there was :)
First, you're chasing an irrelevant point. My grammatical nitpicking has nothing to do with the topic at hand. I'm writing down "easily distracted by internet arguments."
Second, you're assuming importance. By bringing my "newish"-ness into play you're effectively asserting that hanging out in Hacker News makes you better at arguing your points, which obviously isn't true regardless of how high your karma is. I'm writing down "doesn't actually look up accounts' creation dates before tossing around seniority."
Third, you're assuming ignorance. I have no interest in talking about interviewing policies with you. I am trolling. You have been trolled. Do not feed the troll. I'm writing down "has been trolled."
Fourth, you're chasing the wrong issue. Actually, this is the same as the first trap. I'm not sure why you decided to list it as a separate bullet point. But hey! Traps! Bullet points! I'm writing down "overly fond of bullet points."
Fifth and finally, you're assuming irrelevance. Not in the "making an assumption about" sense of the word, but in the "acquiring the attributes of" sense. I'm writing down "GIGO."
More traps! More black eyes! Nary a feather in your cap! Had you any friends I would urge them to see to you.
The ideal candidate for this job knows when -- as Kenny Rogers put it -- to "hold 'em" and when to "fold 'em." By not simply walking away from a fruitless discussion with a self-admitted troll, you've shown yourself to place pride above the minimax of effort in the pursuit of solution. This single-minded devotion to a stupid, stupid task is not a quality we look for in our engineers.
Instead of readjusting strategies and avoiding the sunken cost fallacy, you chose the classic 6th grade technique of pretending you knew all along and the decidedly modern approach of post-facto appointing yourself as head of Hacker News' Troll-Baiting Brigade (official motto: "We Get Made Fun Of So You Don't Have To," official song: "Nearer To Thee, PG"). When faced with a losing bet, you doubled up.
You can keep the dry erase marker you're holding, but I'm going to have to ask security to see you out.
Anecdotally, when a one-hour interview turns into a three-hour discussion of a side point, it is a really good sign. If the interviewer isn't into it, give up -- but people who can bounce ideas off of each other tend to come up with more ideas.
I agree with you and don't understand people who argue differently.
The interviewer didn't ask: "Can I find a list of the top 10,000 words usages?" Which is the question the interviewee insisted on answering.
If I am a lead and I need a list of the top 10,000 words and I go to my co-worker and end up in a protracted argument about what that means philosophically I am going to be upset. I want him to say: "Here is how I'd do what I think you want. Oh, and by the way, I'm not sure an exact list of the top 10,000 words is possible .... here is how we can get as close as possible".
Sure, the list is a moving target. That fact is simply a bullet point in the risk assesement. Note it, move on and solve the actual problem that is presented.
I disagree. This seems to suggest that no matter how stupid the interviewer is, you just need to make him feel better and you'll get hired. Which defeats the purpose of the interview. I'd walk out on that interview as the interviewee.
Anecdotally, when a one-hour interview turns into a three-hour discussion of a side point, it is a really good sign that the interviewer has the ability to bounce of new ideas and discuss them while the interviewee has not.
Good arguments (apart from the insults: conversely I wouldnt employ you because you dont appear to see any subtlety in all of this).
Look, I wasnt trying to say the interviewer is superior to the interviewee. Definitely not. But I am saying dont treat them like "ignorant douchebags" and dont assume you know more than them. Potentially you do - but assuming that is the case is a fallacy because you probably end up coming across wrong..
This is all good advice if you know the social qualities you are looking for determine whether the person can do the job or not. This issue is actually a statistical nightmare because companies think they know exactly who to hire and they try to prove it by showing off the people they have hired. But they need to compare their current employees to people they turned away. Any study on this has shown companies have no idea who to hire after the basic the basic personally and technical filters.
I would appear to have missed those traps too. From my reading, he appears to have avoided many traps of assumption, traps that the interviewer blundered into without even noticing. IE, there is no average corpus, language is dynamic, hash functions aren't all equal, etc.
I'd hire him in a heartbeat.