Hacker News Reader

Comment by tomgp | Hacker News Reader

This reinforces for me the importance of domain knowledge in engineering leadership. i.e. if you work for a finance company you need to have a decent understanding of finance in order to make the correct technical decisions and tradeoffs, same goes for journalism, same goes for commerce etc. etc. Successful organisations I've worked for have always included domain specific, non-technical, questions to tech team interviews whilst some of the most technically acomplished teams I've worked with have floundered through a lack of domain insight.

View on HN

I’m a software engineer and a CPA, so I’ve got the domain knowledge. However, I’m not sure how to find a gig where I can apply that. It seems everywhere I look vastly prefers someone with twice my experience as a software engineer and zero domain knowledge over my years of experience in accounting and fewer years of experience as a software engineer. Any insight on how to utilize it effectively?

Unfortunately, the likely solution to this is to keep banging out work at wherever you can gain experience as a software engineer.

Modern hiring practices are too rigid and filter-friendly for you to likely appear as a strong candidate based on the fact you have good accounting experience on top of your growing software skills.

What will really help you though, is having friends who work at a bank in the software departments. It's almost always who you know in this world. You need to network, network, network!

As someone who worked on a bookkeeping system without being an accountant (or bookkeeper in any sense), I'd say your challenge is that it's very possible to learn enough to build a decent system, assuming your engineering knowledge is strong.

I don't say this to blow my own trumpet, only to say that the non-engineering leadership at the company in question were very invested in the product details and making sure I understood basic accounting principles.

That said, I went from that role to working in a billing system that was originally built by a team where leadership weren't invested in the details. The result was a lot of issues and frustration from Finance leadership. Storing monetary values in float was not the biggest issue, either.

That being said, maybe branch out of just looking at accounting/bookkeeping and market yourself as "I know how money works in software systems." Your skills are extremely transferrable and knowing the Finance expectations will make it easier to make good design choices further upstream.

You know, it's kind of funny, but it seems like most businesses are not interested in doing things "right". As doing things "right" is time consuming, hard, and cuts off avenues to "innovate". "That's not how accounting works" is like telling management to clean their room. No one wants to hear it.

I may be able to help, I just sent you an email.

Your ideal job for utilizing both would either be to work for one of the ERP providers or accounting software providers (Oracle, NetSuite, Workday, Xero, etc.) or to launch your own targeting a specific need.

I would network to get over the ATS barrier and focus on smaller companies.

I work at a company that wants to start fixing their accounting system...what stacks are you familiar with?

I’m a general backend dev. I’ve used python, rust, and TypeScript to varying degrees along with SQL and noSQL databases. I’m pretty comfortable learning new stacks I haven’t used before.

Claude is familiar with all of them, and can describe each in terms of others without risking company code :-)

I agree with your sentiment here, but I think it helps to think of those domain specific questions as technical questions, just from a different technical domain. Finance is technical, mechanical engineering is technical, even sports management and sociology have big technical components too. I think having an expansive view of what technical competence is breeds the humility necessary to work across domains.

Yes, sure, if it helps you to think in those terms I guess that makes sense. Being a bit reductive perhaps but I think what it comes down to is having an interest in the "why" as much as the "what" and the "how".

ever since i started working for an insurance company, i realized that understanding the insurance industry is far more difficult than understanding the codebases. if the codebase is acting weird, at least i can step through it with a debugger!

Reinsurance is a beast. I spent a good time cracking layers and trying to implement the logic with a team.

I don't know about that -- I've always understood that to be the role of the product manager, to have all the domain knowledge.

It's the PM's job to work with engineering to ensure that the requirements are correct, and that the built product meets those requirements. And in an agile setting, those conversations and verifications are happening every single sprint, so something can't go for too long without being caught.

If you don't have a PM, then sure I guess your engineering team had better have deep domain knowledge. But otherwise, no -- it's not engineering's responsibility. It's products's responsibility.

There should be a system analyst. Every ERP or core banking big name works this way. Requirements have to be processed and then passed for implementation. In an agile setup rinse and repeat. As a side effect the whole team gains the domain knowledge. Or part of it.

> There should be a system analyst.

Exactly, this what we try to advance our tech people to, someone with the combination of domain+systems knowledge.

It results in more independent+correct action which is much more powerful than having to specify significant details to less knowledgeable people.

Reply on news.ycombinator.com