mrkeen
11 hours ago
Interviewed for them this year.
Got into a heated argument where the interviewer insisted it was perfectly acceptable to store money as a mutable row in a database.
I pushed back with the standard "You append transactions (including corrections) to a ledger" but he wasn't convinced.
I whipped out the standard two-ATMs -separated-by-a-distance overdraft example, and how you can create or destroy money that way.
He said it made no sense as an example because it was buggy and you would never release buggy code.
I asked if he'd done bug fixes before (yes) but obviously he was going to keep digging in further.
The irony of it was that he was part of the blockchain team.
Ezhik
8 hours ago
Revolut refused to help with a dispute. They rejected it after like 2 hours, first claiming they contacted the seller, which it turns out they did not.
Then they claimed my evidence was incorrect, without any opportunity to correct.
And finally in their complaint system they completely refused to look at any of the evidence and sent me a generic refusal letter that referred to me by the wrong name.
All this despite other banks successfully handling chargebacks for the thing in question. Sad.
randunel
10 hours ago
I don't see the difference between a ledger (possibly with a unique sequence enforcement) which would take the balance to a negative number, and a mutable row in a relational database with optimistic locking (same unique sequence enforcing). Would you mind helping me out, how would a ledger work better to prevent a negative balance, given that the enforcement isn't specific to ledgers and can be used in relational DBs? After all, both can go to negative balance by applying atomic subtractions, and both can prevent writes with the wrong sequence.
mrkeen
10 hours ago
I don't think you can avoid negative balance, without giving up on availability (i.e. moving from AP to CP). And then an outage like TFA takes down your whole system.
You might be assuming that there is only one database, and that all consumers are reliably connected it. So who owns the database: Visa or MasterCard? Because ACID doesn't span across database instances (let alone database vendors or companies).
If you write down that "Bob withdrew $20", that cannot be wrong, (at best it can lack info that you later wish you had).
If you write down "Bob's balance is now $10", you already know the problems with that from your question.
sksksk
10 hours ago
I get you with needing a ledger, which most banks use.
I'm assuming Revolut do as well, but this engineer wasn't aware. Or perhaps it was a different question they thought they were asking, or maybe a misunderstanding.
But the two ATMs problem would be solved by securing a lock on the database before proceeding with the transaction?
mrkeen
9 hours ago
He suggester that they had both. My question was what to do when they disagree, and he wasn't able to either conceive of the 'two sources of truth problem' or wasn't able to suggest a solution. He pushed back saying: if they disagree then you've got buggy code, and that your job is to not write buggy code. "That's why we test". "For race conditions?" etc. etc.
Who owns the database in your locked example?
sksksk
9 hours ago
Revolut would own the database in my example.
How would a ledger work without having some kind of lock, how would you prevent a negative balance?
When someone checks their balance, would you to retrieve every transaction from the ledger and calculate the current balance?
ergl
9 hours ago
> But the two ATMs problem would be solved by securing a lock on the database before proceeding with the transaction?
You can also let an overdraft occur. Now the user ows the bank some money and you can charge them interest for their debt.
strideashort
9 hours ago
Probably hybrid is best.
Row level locking and update indeed works, most of the time - bugs are a real issue.
som write ledger and update row in the same transaction.
then in bg have a batch ledger verification, probably on a read replica, and flag any discrepancy.
TacticalCoder
9 hours ago
> Got into a heated argument where the interviewer insisted it was perfectly acceptable to store money as a mutable row in a database
Hey, not only he didn't believe in appending to a ledger but moreover he probably believed it was fine to store the amounts in floats (I know, I know, everybody who's using floats never make any mistake, knows everything about rounding rules, has read and could write by heart "What every computer programmer should know about floating-point numbers" etc. But I'm still not using floats for monetary amounts).
thiht
9 hours ago
> you would never release buggy code
He's right, just make no mistakes!
igravious
11 hours ago
even if you were technically correct why would a company hire someone who demonstrates that they are unable to disagree in such a way that a heated argument does not ensue? i'd say they dodged a bullet.
mrkeen
10 hours ago
The interviewer's job (I was briefed beforehand) was to make sure I know my concurrency, because they use a lot of it there.
I have all the patience and time in the world to discuss my ideas.
I had the problems, the solutions, slide decks and a Miro board ready to go.
He wanted to shut down discussion at every turn with nonsense like "so you think no banks work at all?". Sure, I can grin and eat shit, or I can say "banks predate your CRUD operations by just a little bit".
If he had working knowledge on how to represent mutable money amounts in a distributed environment, he didn't let on. I was all ears.
So I pushed back on him, and I'll push back on you:
> even if you were technically correct why would a company hire someone...
Because I'm technically correct.
You're certainly not alone in your appraisal of the situation. The market over here works exactly this way. Correct, reliable systems come a distant second to agreeing with the team.
Technical discussions are incredibly likely to devolve into people discussions.
No people discussion has ever worked it's way back into being about fixing the broken software.
fyredge
10 hours ago
Pay him no mind. I shiver at the thought that he might be at management level and passed potential hires because they didn't not disagree in the way he liked.
If anything, you dodged a bullet from a potential job where nothing gets done correctly.
strideashort
9 hours ago
ah yes… an interviewer recently proudly presented his interview sieve… a non-policy book he swears to by a “successful professor”.
Interviews are a gamble. If he interviewer has a specific framework in mind - no matter how correct or incorrect it is - good luck hitting the right spots.
igravious
9 hours ago
it's a strawman that the only two available options are the mutually exclusive "grin and eat shit" one or alternatively a heated argument
i stand by what i said here down-votes be damned; judging by our brief interaction and your telling anecdote you come across as a smug disagreeable know-it-all and in their position i wouldn't have hired you -- there is after all the option to hire someone who both knows their stuff and doesn't come across the way you do
Oh Revolut's down are they? Let me tell you about an interview I did with them. Blah blah blah. Yeah, no thanks.
mrkeen
9 hours ago
I would love if it all engineers were professional enough to avoid the personal criticisms and stick to the comp sci, which is far more interesting.
This is why I wrote:
Technical discussions are incredibly likely to devolve into people discussions.
No people discussion has ever worked it's way back into being about fixing the broken software.
I wouldn't dream of calling someone a smug disagreeable know-it-all.
I'm here for any discussion of the tradeoffs of balance v ledger, though.
tasuki
11 hours ago
Yes they did, and so did mrkeen!