Interviewer: Okay now what if you couldn’t use the standard library? Imagine it’s a 200GB file and you have to do it all in memory in Ruby.
Me: Why the fuck would I do that?
Or with this person:
Interviewer: Okay now what if you couldn’t use the standard library? Imagine it’s a 200GB file and you have to do it all in memory in Ruby.
Me: Ah what an unusual situation, to be using Ruby without the standard library. Well, I would do it like this: <writes 20 lines of code, there's a bug, they fix it themselves without prompting>
While interviewing you might think a question is silly. But perhaps the interviewer has asked this question to 100 people and found it to lead to intelligent discussions that reveal a lot about job candidates. Don't assume that a process is a bad process just because it rejected you.
In particular, this sort of assumption seems designed to test your understanding of the linear stream processing type of programming. You probably wrote something that operated on an entire array, and the interviewer was curious to see if you were flexible enough to change that into an iterative algorithm. Perhaps you used a sort when you could have been slightly more efficient and used a single linear pass. A good programmer will be able to handle this, even if the specifics like "200GB file processed using Ruby with no standard library" are silly.
That's a perfectly reasonable question for the candidate to ask. Why would you want to do that? You'd want a damn good reason to go "off the reservation" and build something like that. Plus, the reason and detail for wanting something like that a) might be the wrong approach or b) might have an impact on the final solution.
Either way, it should lead to an intelligent discussion.
If your point is that the author presented an interview vignette where the "Me", interviewee, character reacted to an unpleasant situation with less grace and courtesy than ideal, I doubt anyone would disagree. It was likely also just for emphasis and not to be taken literally, as it wasn't core to the point of the article.
It's not that the interviewee merely didn't want to perform the exercise. It's that he questioned (or rejected) the premise of needing to do it that way. In the context of the interview, what would it show?
There are plenty of people who very much want to work with someone who will question and even push back on "going off the reservation" (as a comment up-thread put it).
It shows a willful stubbornness that is incredibly difficult to work with. Obviously I'm not asking you the question because I'm a masochist -- I'm asking it because I'm trying to glean something about your abilities. The fact that the author would rather flaunt their ego as a "real developer" than suspend disbelief for a few minutes marks them as unnecessarily argumentative in my mind.
So what you're saying is that you don't believe the GP because you come to a particular conclusion as to the signal that such a reaction in the interview sends about the character of the candidate?
Are you asserting it's impossible (for reasonable person) to come to any different conclusion as to the signal that it sends?
As compared with the author's suggested alternative, do you feel that asking such a question is a better way of determining both this signal and the something about the candidate's abilities you were hoping to discover?
i used to recruit people without having them pass coding intervuew. Never again. It depends on the job of course, but for anything that involved writing lines of code, it's not even an option.
The main problem being that a bad developer can cripple your codebase for a long time before you actually realize it. And some people are good at pretending to know what they're doing.
i guess it's more of a matter on how your coding interview are conducted. I usually try to have the person design and code some features of a program solving a real life problem. And then we talk about it. This also let me see if the person is a good fit and is able to work in a team.
We do some coding problems in our interviews, but it isn't puzzle-oriented or even requiring much knowledge of a standard library.
We're looking for basic stuff, like looking for a pattern in a list of items. Things were there will be multiple correct ways to implement it, and can choose an implementation language.
One candidate we had... oh boy. The guy could talk. Excellent, excellent verbal communication skills. He really sounded like he knew what he was talking about. But completely balked when it came to putting bits in a file. Just wouldn't / couldn't, even when I tried to talk him through the process.
My recommendation after the interview was a hard 'no', that we should under no circumstances hire this person. Management, apparently dazzled by the aforementioned communication skills, wanted to give this guy another interview, over my strong objections.
The second interviewer came to the exact same conclusion. Maybe they'll listen to me next time.
I always start interviews with soft questions (on work experience and general technical discussion, like talking technologies X vs Y, or architecture) before diving into the coding question and it still amazes me at how many people sound so competent initially and then struggle to iterate an array.
> And some people are good at pretending to know what they're doing.
This is a very important point. I know we on HN love to complain about tech interviews but it's still the single most meritocratic interview process I know of. In most fields it's incredibly easy to schmooze your way through.
If I have to answer contrived Ruby questions every once in a while to avoid working with professional bullshitters, so be it.
I was thinking about that too. Maybe because that candidate moved on to another company doing XYZ, and they tweeted about it or already made an impact somewhere else.
EDIT: But really, I think its subjective or FOMO thinking on their part.
Is it performance, or is it fit, culture, contribution? I suppose all of those can be labeled under 'performance', but I think it's obvious when you pass on a good candidate after the fact.
I try not to judge. If it's a company worth working for their contrived question usually has a point to it.
A good example: a few years ago I was given a take-home assignment for a language I had zero familiarity with it. I asked the recruiter about it, assuming it was a mistake, and she assured me it was intentional. Turns out the team had decided to optimize for people who can dive into complicated, unfamiliar domains and figure out a reasonably clean solution. In particular, this language had a feature explicitly for making problems of this sort easier and they were selecting for engineers who would be able figure that out.
That's not to say every company does it well -- I'm sure there are many cargo-cult interviewers out there -- but I certainly wouldn't say it's "fucked".
I am guilty of doing interviews with silly questions (200gb file, in memory). I usually start off the test with something like "This is a silly contrived question, mainly we just want to see how you think. Talk about what tradeoffs you're making and why." It tends to work well - the candidate tends to not be so defensive or anxious and will relax a bit to walk through the problem.
Interviewer: Okay now what if you couldn’t use the standard library? Imagine it’s a 200GB file and you have to do it all in memory in Ruby.
Me: Why the fuck would I do that?
Or with this person:
Interviewer: Okay now what if you couldn’t use the standard library? Imagine it’s a 200GB file and you have to do it all in memory in Ruby.
Me: Ah what an unusual situation, to be using Ruby without the standard library. Well, I would do it like this: <writes 20 lines of code, there's a bug, they fix it themselves without prompting>
While interviewing you might think a question is silly. But perhaps the interviewer has asked this question to 100 people and found it to lead to intelligent discussions that reveal a lot about job candidates. Don't assume that a process is a bad process just because it rejected you.
In particular, this sort of assumption seems designed to test your understanding of the linear stream processing type of programming. You probably wrote something that operated on an entire array, and the interviewer was curious to see if you were flexible enough to change that into an iterative algorithm. Perhaps you used a sort when you could have been slightly more efficient and used a single linear pass. A good programmer will be able to handle this, even if the specifics like "200GB file processed using Ruby with no standard library" are silly.