Hacker News Reader

Comment by dakiol | Hacker News Reader

The thing is when I’m the interviewer I’m not looking for coders. I’m looking for people who can understand the business, find a solution that is business oriented and produce (if needed) good enough code (we are not Google). So, if you cannot invert a binary tree from scratch but are good at the other skills I’ve mentioned above, I want to work with you.

What good is someone who can code the best algorithm but cannot understand the business? Unless you are working in the top 1% of the companies out there (where you may have the luxury to invent new ways of doing things), for the rest of us our main skill is: to solve business problems with zero or minimal good enough code. We (99% of the tech companies) don’t need a Messi, just an average Joe.

View on HN

This is the reality that most engineers that spend their lives online don’t seem to get.

We don’t need you to be the best engineer using the most cutting edge tools that a YouTuber told you about. We need you to be a good colleague who people can trust, can communicate with, and isn’t going to cause a ton of stress for others through maverick behaviour or major levels of incompetence.

Then don't ask this question if it's not relevant for your position? Presumably those who would ask it don't want to hire engineers that have never heard of recursion. It's a basic level CS concept, not rocket science.

Out of 100 people I interview, maybe 1 would know what recursion even is.

Does the role you're hiring for require knowledge of recursion?

You need to talk/complain to your pipeline, sounds like the 20 something non-technical "recruiters" are wasting your time.

What a team I worked in did, is we reminded the interviewee what a binary tree is. It's a pretty simple concept, much simpler than most businesses, so it makes a good test for basic general logical thinking skills.

We were hiring for a C++ role though. I can imagine people used to higher level languages might find the very need to deal with pointers confusing

Pointer vs reference: What's the difference? Practically, not much. All "higher level" languages (that I know ... er... except Perl) use references instead of pointers.

    > I can imagine people used to higher level languages might find the very need to deal with pointers confusing

I'm confused by this remark. What do you mean? Is this meant to be condescending? What do you use pointers for in your C++ project that references cannot do in a higher level language?

My point is that in higher-level languages you might spend your entire career not thinking about how your data is laid out and what points to what, while in C++ you are exposed to this reality daily even if you are working on trivial problems.

That is my hypothesis on why some people might consider inverting a binary tree an unrealistically complex problem. If you are not able to solve this problem without thinking too much you are probably not being able to write working C++ at all, but might still be able to even solve real business issues with, say, Javascript.

Never worked in tech so I find this mindset really alien. Why no specialisation and separation of duties? Why not have someone really good on the business side and someone else who is really good at coding?

Finding good solutions often require simultaneously considering both the business side and the programming side.

The business-only guy won't see the limitations and possibilities of code, while the programming-only guy won't see where the business side is flexible or where it is rigid, thus the optimal solutions can take a long time to find.

The business side might also be prone to specifying X-Y problems, which can be very difficult to spot if you're not into the business side.

At least in my experience, having significant domain experience in our dev department has been a super power of sorts, allowing us to punch well above our weight.

edit: I didn't have any domain knowledge when I started, but I was willing to learn.

Why not both in the same person? It's cheaper to pay one really good person 50% more than paying two people. It is quite common in domain-heavy tech areas (financial markets, etc.).

That's already the starting point. People who really understand the business, and developers who work with them. The point is that the developer also needs to understand the business well enough. You cannot separate that from coding if you want good results. A good technical business analyst that sits in between the business and the developers can really help, but that is no substitute for the developer having good knowledge of the business and what it is actually trying to accomplish.

Sometimes the business only has a high level goal in mind and it is up to the developer to invent a solution, keeping in mind how the end user will interact with the system in their day to day work, and foresee potential issues in how the changes would impact other systems and business rules and so on. The developer has low level visibility of systems that are not readily apparent to business people. It is necessary for us developers to hide some of that complexity from the business. Some backends are very complex webs of business rules.

The developer needs to have some bigger understanding of it all, otherwise they are reduced to a code monkey who implements spoon-fed acceptance criteria from Jira tickets, makes stupid mistakes that break other functionality and systems, and won't recognize various issues that were not apparent to the business person who originally wrote the AC's. Basically we need developers to collaborate with the business to design and develop solutions properly.

Exactly this

Reply on news.ycombinator.com