Introduction​

OKX is a large-ish crypto exchange that is hiring in Singapore. However, they do not have presence in SG and US.

TLDR​

Overall Experience: Okay
Difficulty: Hard
Received Offer: No

First Round (Senior)​

• Talk about hash map implementation
• Hash function, probing, collisions
• If a hashmap only has a few buckets populated, what can we optimize
• Error handling
• How is error handling being done
• Benefits of catching exceptions
• Coding
• 🔴 420. Strong Password Checker

Introduction​

Matrixport is a very promosing SG company with a fresh $100M funding from Series-C last year. And they also have plans to go public in the next few years. The exchange under MatrixPort is called bit.com. However, note that all interviews were conducted in Chinese.

TLDR​

Overall Experience: Good
Difficulty: Medium -> Medium-Hard
Received Offer: No

First Round​

• Previous Experiences
• Concurrency related: -- Function spawns several goroutines, wait groups implemented.
• How should we implement it if we want to abort all threads whenever one of it fails.
• Ans: Implement channels. In each goroutines, check for channel status. When it fails, close the channel.

Second Round​

• How does database transactions work under the hood
• When to use transactions
• Considerations during DB / Cache interactions

Third Round​

• Docker file
• How to perform deadlock using goroutines
• Regular expressions
• Shell command to check process
• Memory stacks of process
• Kernel vs core
• Debugging tool

Introduction​

TikTok has been the most popular choice among ex-colleagues that left Shopee. A quick check on LinkedIn Jobs also shows that they are hiring very aggressively (STILL). The role isn't that bad too, so why not give it a try.

TLDR​

Overall Experience: Very Good, very friendly interviewers
Difficulty: Easy
Received Offer: Yes

First Round (Senior)​

• Previous experiences in automation
• How to structure automation cases

2 fairly easy coding questions:

• 🟢 387. First Unique Character in a String
• 🟡 98. Validate Binary Search Tree

Second Round (Senior)​

• Previous experiences in automation
• How to perform backend API test (via REST / RPC)
• Tools used for manual backend testing
• Tools used for automated backend testing
• How to handle race condition during automation testing

1 fairly easy coding question:

• 🟢 Two Strings

Third Round (Hiring Manager)​

• There are 100 rocks of the same weight, except one. Most efficient way to find the different weighted rock. Time complexity & further optimisation.
• Pros and Cons between testing in live / test environment.
• Workflow of building automation cases.
• The most challenging feature you have tested before

Fourth Round (HR)​

• Reason for leaving
• How to resolve internal / external conflicts
• Proudest achievement in the current role
• Future plans

Fifth Round (HR)​

• Offer & package

Introduction​

As another unicorn in Singapore, although Grab isn't the company with the best prospects ($GRAB LUL), but the engineering aspects seem to be pretty decent.

TLDR​

Overall Experience: Good, some interviewers can be very uptight
Difficulty: Easy -> Medium-ish
Received Offer: No

First Round (HR)​

• What do you look at when you choose a company to join
• Why did you choose Grab
• Expected Salary

Second Round (Codility Test)​

2 Questions, similar to:

• 🟡 1404. Number of Steps to Reduce a Number in Binary Representation to One
• 🟢 Number of movements for light bulbs to shine where the bulbs in front needs to be powered up first to light up

Third Round (Coding)​

• 🟢 242. Valid Anagram
• 🟡 Implement a data structure that has Add(), Remove(), Search(), RandomRemove() in O(1). Similar to 380. Insert Delete GetRandom O(1)

Fourth Round (System Design)​

• Top level design
• DB schema design
• API schema design

1. Design an online movie ticketing system

• Big cinema with multiple locations across the country
• Each location has multiple screening halls
• Site has to display movie information, showtimes, bookings, payment
• Not neccesary to implement payment system (via 3rd party gateway)
• Handle race condition

2. Design a meeting room booking system

• Big MNC with many offices across the globe
• Should support create / update / delete of meeting rooms
• Ability to book a meeting room with specified duration, and cancel booking
• Block booked slots to avoid duplicated bookings

What the hell am I talking about? You might say. Well yea it sounded crazy but how long is a second exactly?!

What Happened​

As I was writing some unit tests for my shiny Redis Set implementation, somethign weird caught my attention.

TestSendPotentialUsers | Successful | Written 80687641:-18230398344540846 to potential_user set

Excuse me?

For context, the Redis key was constructed using:

toWrite := fmt.Sprint(u, ":", time.Now().Unix()-common.ONE_MONTH-common.ONE_DAY)

After some digging around, I realised that in my common.ONE_HOUR:

Why didn't I think of that, it is in milliseconds! And my common.ONE_MONTH-common.ONE_DAY will effectively become 18144000000000000 - 6048000000000000 🤣

One quick fix is:

    ONE_HOUR  = int64(60*time.Minute) / int64(1*time.Second)

And noice, it finally makese sense now.

TestSendPotentialUsers | Successful | Written 93737927:1637229666 to potential_user set

So I was working on SeaHungerGamesBot, and one major pain point was: when a certain user started the conversation, but did not proceed from there. (probably due to the hassle of copy-pasting the API key?)

Since my current goal is to have as many active users as possible, that was a wasted opportunity. So my objective was to keep track of the users that started pressing some commands, but backed off and disappear afterwards. I call them the potential users.

What's the Plan​

The initial plan is:

Remind users to use the Bot if:
- They have chatted with it before 
- It happened in the past month
- They still did not provide their key in the past month

• For such users, store their user_id and the time they call the commands. This can be achieved easily since all anonymous users (aka. those that did not provide their keys) will get routed through a CheckKey function, and if it does not exist in DB, they will be urged to provide their key in the next step in order to proceed with other features.

• The reason we store the time is because we want to have a "cool down" period before we annoy them again. E.g. A user chatted on 1st Jan, we will not send him the cold message until at least 1st Feb.

• If we did send him on 1st Feb, we reset the time to 1st Feb and the next message will be sent on 1st March. So on and so forth.

• And if the user provide their key between 1st Feb and 1st March, we remove them from the pool and they will not receive this anymore.

Cool, Now What?​

Technical Implementation​

1. Naive​

The naive solution is to have a cache key, something like potential_user:<user_id> with the value as time. Since it is pretty straight forward, and we can GET or SET the value easily.

Pros

• Easy peasy

Cons

• Kinda messy

2. Slightly more elegant?​

Then I thought of Redis Sets, and it is kinda what I prefer it to be. We can have a set called potential_user, and inside the set, we have list of keys <user_id>:<time>.

Pros

• Very organized, i love it

Cons

• Need to store all the information in the key, hence delimiter is needed.
• Have to parse the key to get the relevant information.
• Since they are not key-value pairs, in order to update the time, we have to SREM the old key and SADD new one afterwards.

3. Most recommended?​

I read up on HASH, and it seems pretty decent (overkill maybe?) for this use case. And probably a refactor is neede to make it clean.

The key can be just <user_id>, and contains field such as <user_key> (since we cache the keys to minimize DB calls), <time> etc.

Pros

• Treat it as an object, and we do not need any extra keys anymore

Cons

• When we need to find user that has time (not everyone will have this field), we have to probably check one by one.

So..​

I went with option 2, and implement a set. Only thing that I don't really like is the update part. Need to remove first -> then re-write the updated time.

//Remove the old key and update with the new time in Set
//As long as users do not give us the key, they will always be in the pool
//We continuously update the time after each cold message to avoid annoyance
if err := processors.RedisClient.SRem(common.POTENTIAL_USER_SET, pair).Err(); err != nil {
    log.Error(ctx, "SendPotentialUsers | Error while writing to redis: %v", err.Error())
} else {
    log.Info(ctx, "SendPotentialUsers | Successful | Removed %v from potential_user set", pair)
}

toWrite := fmt.Sprint(userID, ":", time.Now().Unix())
if err := processors.RedisClient.SAdd(common.POTENTIAL_USER_SET, toWrite).Err(); err != nil {
    log.Error(ctx, "SendPotentialUsers | Error while writing to redis: %v", err.Error())
} else {
    log.Info(ctx, "SendPotentialUsers | Successful | Written %v to potential_user set", toWrite)
}

I guess I will leave it as it is for now, until I can think of a better solution.