Senior Backend Developer

Nummo is hiring a Senior Backend Developer. This posting is fake. The role is not open, the salary is not real, and applying would only create an email that nobody is staffed to answer. If you are still reading, that is the job working as intended: long text, short payoff.
You will own the part of the product that users never see and blame anyway. When a screen is slow, they say the app is slow. When a record is wrong, they say the app is wrong. You will be the person who finds out whether the slowness is a query, a queue, a retry, or a request that should never have been sent. Then you will fix that thing and write a sentence explaining it to people who wanted a different sentence.
The stack is the usual one for a company that started with good intentions. There is an API. There is a database. There is a worker that runs jobs because the API was not supposed to do them inline, and then did them inline until that hurt. There is authentication, which is always described as “mostly done.” There are webhooks from other products, and those webhooks arrive late, twice, or not at all. Your work is to make those facts boring.
A normal week starts with a bug that only happens for one account. The account has more data than the happy path assumed. You will look at the query, notice it loads everything and sorts it in memory, and replace it with a query that does not do that. Someone will ask why it was written that way. The answer is that it was fast when the table had forty rows. The table does not have forty rows anymore. You will resist the urge to add a comment about this. The commit message can hold the grudge.
You will design interfaces that other services call. Those interfaces should do one thing, fail in a way the caller can understand, and refuse to guess. If a required fact is missing, the request fails. It does not invent the fact, store a placeholder, and hope a later job cleans it up. Later jobs are where missing facts go to become permanent. You have seen this. You will still be asked to do it, and you will say no with a shorter explanation than the person expected.
Reliability is the actual seniority. Juniors make the endpoint return 200. Senior people make the endpoint return 200 once, for the right account, with the write committed, and with a second delivery of the same event doing nothing new. You should care about idempotency the way other people care about formatting. You should care about transactions enough to know which work belongs inside them and which work would hold a lock while calling another network. Calling another network inside a transaction is a choice. It is a bad choice. You will remove it when you find it, including when you wrote it.
You will work with product and with the desktop app. Product will describe an outcome: a person asks for something, and the system finishes it. The desktop app will show a spinner until you say the work is done. Your job is the part between those two sentences. Some of that work is synchronous and should stay a request. Some of it is long and should become a job with a status the client can read. You should know the difference before you start coding. “We’ll just poll” is acceptable. “We’ll just hope” is not.
Permissions matter. A user can see their firm’s records. A user cannot see another firm’s records because the identifier in the URL looked convenient. You will check the owner on the server every time, including on routes that feel internal. Internal is not a security boundary. You will also keep secrets on the server. The desktop app does not get provider keys, and a log line does not get session tokens. If a debug log would be embarrassing in a screenshot, it does not get merged.

Work arrangement
No