Hacker News Reader

Comment by FLUX-YOU | Hacker News Reader

>Many candidates will immediately start writing a program in Java or Python, if they get it right, then they will start optimizing the algorithm

> and in most cases programmers who are comfortable with the command line version are also the ones who are better at writing code

These two statements indicate to me that you are ineffective at communicating what skills you are looking for in a programmer.

The reason they are coding a sorting algorithm is that you're interviewing a programmer for a programming position. The assumption is that they are being tested on the knowledge in that domain, which includes sorting algorithms.

If I answered the exact same question by putting the file lines in a data structure and calling Sort() in someone else's interview, I might be thrown out for not giving them the actual algorithm that Sort() implements.

Or maybe you just want people calling system()/exec()/execvp() or whatever. I dunno.

View on HN

Heh, I got rejected once, a long time ago, for almost exactly this. I was asked to whiteboard a C function to convert an ascii character to an integer, and I wrote one that just returned the result of atoi(). I thought it showed knowledge of the best way to get the job done, but I guess they disagreed.

How does a rejection like that work in practice? Was that the question the interview hinged on?

A reasonable interviewer could just say "Alright, now can you do it without using the standard library?".

I should be clearer. They didn't specifically reject me for that. There was just a sense that the interview wasn't going well from that point forward. They may just have felt that their request was clear and my response was smart-assed, and in truth that is probably fair.

> If I answered the exact same question by putting the file lines in a data structure and calling Sort() in someone else's interview, I might be thrown out for not giving them the actual algorithm that Sort() implements.

Best of both worlds answer for that kind of question: "In any real program, I'd normally call the standard library implementation, unless there's something wrong with it or profiling suggests that it's a bottleneck. Are you looking for how that library function would be implemented?"

That shows that you know the right real-world answer, but that you're also prepared to explain how that function works as part of the interview. The interviewer could then choose to have you write out the algorithm, or alternatively they could ask questions like "why might the standard implementation be a bottleneck?", which leads in interesting directions as well.

Came here to say exactly this. When someone asks you to "transform this data" in a programming interview, then you assume it's to test your programming skills, so you start to showcase them.

The question also doesn't talk about platform. Windows doesn't have the GNU suite (or BSD for that matter) by default. On the other hand, if we start programming in a language, there is at least the assumption that the language is installed and configured on said system.

Hi OP here, I am sorry! I should have added more context to the post. I have never rejected candidates solely on this basis.

Its just that I appreciate programmers who think of simpler solutions first.

I can appreciate this also. Your `sort` question reminds me of an interview where I asked the candidate to give me an example of where he used his general coding knowledge to solve a problem. He told me how he had two long lists of email addresses with duplicates that he needed to sort and merge into one unique list.

He explained his solution in which he spent considerable time writing a C++ program to do this - iirc it even wrote the unique entries to a db. He seemed stunned when I explained that he could have achieved this easily with something like `sort -u a.txt b.txt > sorted.txt`. Sorted! To be fair he was inexperienced, but there is a lot of power in the command line that some developers don't seem to be aware of at all.

In other cases, some developers who do know will still grab to the new and shiny solution every time. The simplest solution is usually good enough, and the most maintainable (if that's a concern).

Ted Dziuba's 'Taco Bell Programming' nails this perspective pretty well. I'm sure it has been posted on HN many times already:

http://widgetsandshit.com/teddziuba/2010/10/taco-bell-progra...

Have you asked them why they are started to writing a code in first place? Maybe, since it's a programming interview, they thought you are trying to measure their theoretical knowledge than their practical day to day knowledge.

You should probably reword your question and give a hint that a candidate can use any available tool. If it's a programming interview my first instinct would be writing a code, if it's a sysadm interview I would use available tools in the system.Context is important...

You definitely have a point, but parts of the expectations from candidates at an interview is to ask questions about the problem domain, the available solution space etc.

So in this case, I think if a candidate then asks something like "Are you expecting a solution in code, or can I use command line tools like grep, sort etc?" it shows something about them.

This should be a perfectly fine answer and any interviewer who knows what they're doing should be prepared to roll with it. (by, for instance, pointing at the Sort() function and asking how it works)

The goal is never to see if a candidate can produce a specific program, but to watch them reason and explain that reasoning.

Reply on news.ycombinator.com