Hacker News Reader

Comment by realshowbiz | Hacker News Reader

I remember a job interview where the take home project was to parse a log file and search/sort by various top attributes as fast as possible.

I thought about writing something from scratch, but I knew that whatever I could optimize in an hour or two would be nothing compared to more robust tools that already existed. So I used sqlite to ingest the log once, and query it in various ways to produce the requested reports. The script was just a dozen lines long or so, with one dependency (sqlite pkg).

The interviewer didn’t like this answer. didn’t say why. But I’m glad to see that I wasn’t way off base about how performant sqlite can be.

My answer was of course not a prod solution, just an answer to a question with a narrow scope.

View on HN

The interviewer didn't like the answer because it didn't answer the implicit question, which is how well you can write your own software. We know that you can load a table into SQLite and have it do the heavy lifting for you. But we're often not looking for software _users_ as much as we're looking for _engineers_.

When we interview people, the answers we want often aren't real-world answers because we're trying to get a deeper understanding of how you think or how well you know the details of a complex mechanism.

> But we're often not looking for software _users_ as much as we're looking for _engineers_.

What the applicant illustrated is that he is a much better engineer than the interviewer and the interviewer did not like it.

Good software engineering is about leveraging existing robust tools in a new way, not about re-inventing a wheel while making is square.

For me that would have been an insta-hire.

I both agree and disagree with you.

I agree that the answer was a good one in the real-world sense, and one that I would like an engineer to use under the right circumstances.

I disagree that the answer demonstrated engineering prowess, however. Sometimes you have to assume the lack of existence of certain tools to understand how a candidate would have implemented the solution him- or herself to get a more thorough understanding of his or her engineering chops.

I disagree. Applicant should have done more to understand the requirements for the task. That’s a massive part of software engineering, and you would be surprised how much time software engineers will spend solving the wrong problem. He didn’t understand that part of the problem included rolling a novel solution or restricted use of a database. Almost a daily problem for software engineers is extracting this information from customers or systems engineers.

> Good software engineering is about leveraging existing robust tools in a new way, not about re-inventing a wheel while making is square.

Use of external libraries or solutions is often very restrictive (if not banned) in my field. We can use existing internal or known verified solutions. Not everything is so black and white, and not all options are always on the table. They rarely ever are.

I don’t think really think “leveraging existing tools” is a defining part of software engineering... though it certainly is part of it. Software engineering is much more than just coming up with solutions.

Some people do enjoy reinventing a wheel and making it square. And lots of managers enjoy having those who work for them to do it. It makes the managers feel smart.

The applicant solved a problem that was presented to him. If the person who interviewed him did not want him to do it that way, he or she would have specified it.

I agree that the candidate should have maybe asked if they can just use third party software but I also think that was failure on the part of the interviewer. If there are constraints about the tools the candidate may use to solve the given problem then those constraints need to be specified. Similarly to how you specify which programming language you allow to solve the problem or if you allow standard library use.

If that’s the case then the restrictions should’ve been given in the problem statement and the interviewer should’ve been able to answer why the candidate’s answer was rejected.

Consider it a test of your ability to infer the obvious (a valuable skill.)

I'm sorry but what is obvious in an interview setting? Is it obvious that you can or cannot use standard library? Is it obvious that you can or cannot use state of the art existing software to solve problems?

I do many interviews and I remember even when I started I had to be pretty clear what the candidate can and cannot use. I actually appreciate that they can find existing solutions that are likely better than what one can come up with in a few hours but if I need to test them on how they can code something like that I'll specifically state it.

Yeah, although imagine if carpenters were interviewed/judged based on the quality by which they could create hammers and drills from scratch.

But it was a good thing overall. I showed me signs that the company has an elevated degree of not invented here culture, and that they aren’t very clear when requesting/scoping work.

https://en.m.wikipedia.org/wiki/Not_invented_here

If software engineers are carpenters, the hammers and drills are the programming languages, editors, and IDEs. And sqllite is an off the shelf plank.

You deserve the programmers you're looking for.

God damn but is that a true statement.

I have come across cases like this in a couple interviews. What I did was do both. In those cases I often got an either an onsite and/or offer immediately.

that seems to be a great asnwer to the question as posed, and as would be faced in real-world situations rather than academic ones.

Reply on news.ycombinator.com