Hacker News Reader

Comment by otterley | Hacker News Reader

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.

View on HN

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.

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.

> 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.

You deserve the programmers you're looking for.

God damn but is that a true statement.

Reply on news.ycombinator.com