Coinbase | IC4 | Reject

Hi,

Reposting as earlier post somehow is not accessible to other users.

Posting my interview experience as leetcode community and experience ancetodes helped me a lot in preparation.

OA:
Happened on Codedrills.

Was a very lengthy, but easy question on creating a bank interface. Q ahd 4 parts, each of the next part needed some refactoring in previous parts. We had to support operations like:

Deposit in a account P1
Withdraw from account P1
Check balance P1
Find top K users with maximum transaction activity P2
2-3 more functions, cannot remember for P2
Begin Money Transfer to a given account - P3 . It should deduct from the account but not deposit unless second account accepts the transaction. Incorrect inputs must be taken care of.
Accept Transfer into account from a given account. P3. Note that this should update the financial activity only on accepting transfer for both accounts.
Merge two accounts but history for individual should be available P4
Give me balance at some timestamp T.
I solved P1, P2, P3 fully and got ~90% in P4 and proceeded to Interview.

Interview was to comprise of 2 pair programming rounds.

Pair Programming Round 1: 1hr

This Q was on leetcode but not to the detail it transforms into later.

We have N transactions with <id, size, fee,>.
We are given a block size of 100, we want to fill it with transactions such that the fee is maximized.
We do not want an optimal, but a scalable solution (Basically no NP knapsack DP).

I went around making a class of Transaction and another child which would encapsulate the data from Transaction and used it to solve the problem via priority queue using the ratio as guiding principle. I did call out that knapsack is the optimal solution but its not scalable.

We proceeded to next part of the problem:

Now each transaction has a parent transaction. Child transaction cannot be done until parent transaction is mined.
The problem talked of some SSPF or something which was basically incentivizing the trader to mine a low fee parent by giving it along with a very high fee child.
I brain farted in creating the graph (should have been a HashMap[id] = Transaction and then make a graph between IDs) so I did the problem in an alternate way.

I proposed Toposort to respect the parent child constraint and asked if we are fine iterating the list of transactions each time to check if any new child could be put. Interviewer said its a good Q and we are focussing on completeness and gave a go ahead to my Toposort so I went ahead with that solution.

For part 3, we ran out of time, but it was asking to calculate the fee a child Cn should have to incentivize the trader to take P->C1->C2->...->Cn in block, for all Cn.

I discussed graph making and recursive DFS to calculate the value in such a way that the parent-child list has best value to be at top of priority queue.

Verdict: No Hire.

Feedback said I understood the initial problem correctly and gave a good solution. But the code was cluttered (?!) and had multiple redundant classes (referring to transaction & its child class I made). Code for part 2 did not give correct answer and he could not have solved it unless hint for graph would be given. He also mentioned variable names were poor and didnt follow idiomatic convention for C++ (Trust me, I named them well. Not the x, temp, curr etc :/)

Reflecting back, perhaps the second problem meant that we want the entire parent-child chain to be mined if thats optimal, instead of greedily picking nodes, but to be frank, the interviewer should not give go ahead to a wrong solution only to waste the interview.

I had taken interviews myself too, and given the amounts of "good", "nice", "greats" I had been hearing the entire interview, I feel the interviewer was new and needed callibration.

Pair Programming Round 2: 1hr

This was taken by a senior engineer at Coinbase and encompassed certain behaviour questions like why coinbase, what can I bring to the table, what values I resonate with etc.

We then moved to programming problem, which was another problem already posted on leetcode.

Given N transactions with <id, timestamp, user, currency, ...>, write a code to filter out records by time range, userId and currency.
On surface, it looks like an easy problem of iterating through the list, but there are a few gatchas you can fall into:

Do we want to support multiple filters at a time (Yes!)
Are the filters joined by AND or an OR (i.e. a record is filtered if any filter passes or all filters must pass).

The interviewer was very experienced. He was live reporting any coding error I do - syntax, logic etc. Since I usually catch errors in a dry run after coding, this seemed like a setback to me as the itnerviewer caught some nits and logical errors as I was typing. Try to focus on writing code which works in first try itself, dont let time pressure get to you.

Once this is done, we discuss real life scenarios where a DB may return such a list and I highlighted that Pagination is needed in all such scenarios in production since god forbid we return a billion records and throttle everything down. (Apparently the title of this problem was pagination. 0 points to me, should have noticed it earlier xD).

He asks how I would implement pagination and I went with how we can make m_latestIndex a member of my current Database class (which is performing filtering) but that works for this problem, if I think of multi threading scenarios, I need to think more. To this, he prompted that we can make the method return this and each thread can continue without any issue.

Overall, we also had multiple back and forth discussions on OOP, ideal design for the classes and it was a learning experience for me, although I knew it would be a no hire.

Verdict: Soft Hire despite having implemented only basic code, which otherwise people would do in 5 minutes. He seemed impressed with our discussions and said I could have done the problem had I had more time.

Overall, it seems to be interviews are random. Hopefully this will help future interviewees, and please keep posting your own interview experiences as well! That helps in this market :)