In this story, I’ll show how I vibe-coded a Python tool to backtest FL0WG0D whale alerts on X, measure the % In The money (ITM) at expiry, and see whether copying big call-option buys is actually worth it.

Market Whales

A market whale is a large investor, institution, or entity holding a significant amount of a particular asset (like stocks or cryptocurrency), giving them the power to drastically influence prices and market trends with their large trades. Because they possess huge holdings, their buying or selling activity can trigger sharp price movements, creating opportunities or risks for smaller traders, and can affect overall market liquidity and stability.

A few X accounts track big “whale” options flows like @unusual_whales, @CheddarFlow and @FLOWG0D. The logic is simple: if institutions are throwing huge money into calls, maybe they know something you don’t… so why not tail them?

Disclaimer: This is not financial advice. Nothing here is a recommendation to buy, sell, or hold any asset, and it’s shared for educational/informational purposes only. I’m using FLOWG0D purely as an example because their tweets are easy to parse for the dataset/tooling not because of any view on performance, credibility, or investment quality.

FL0WG0D regularly posts on X about unusually large call-option buys. The tweets follow a consistent template so from one post you can pull the ticker (NBIS), the expiry (16 Jan 2026), and the strike ($112). Then, at the close on 16 Jan 2026, you simply check NBIS: above $112 = ITM (In the money), below $112 = OTM (Out of the money).

Hey chatGPT vibe code the ITM rate tool in python

The requirements were simple, and ChatGPT generated the full script: call the X API, parse the tweet text, run OCR on the attached image to grab expiry + strike, then if the option had already expired, pull the ticker’s closing price on that date from Yahoo Finance.

All I did was create an X API token and copy paste the code. It worked on the first run and exported everything into a clean CSV (built with ChatGPT plus subscription on GPT 5.2 Thinking model).

Issue with Twitter API rate limit

For this solution I’m using the free tier of the twitter API but I can only fetch 100 tweets per month which is not enough data. The second tier allows 15 000 read tweets but costs 200 USD per month !!!!!

I paid for it and immediately after I realised I could have just tried to scrap the website page for free. 🥴.

Another problem is the script always starts from the earliest tweet but those options are in the future so you need to wait for the expiry so I (chatGPT) updated (the script to only fetch tweets older than X days.

Results: Are the whale alerts actually worth following? (NO)

RAW DATA

The script extracted 747 tweets with Ticker, strike price and expiry date. Since I pulled the most recent tweet, most of the posts (55%) didn’t reach the expiry date yet. Some calls are leap years and will expire in more than 1 year.

Result: The call options being in the money (ITM) at the expiry date is 29%

Longer Day to expiry (DTE): more change to expire ITM ? NO

From the 335 options that had already expired (so we could actually score them), the median DTE was 15 days, with a range from 0DTE to 60DTE. Since I only pulled tweets from the last 3 months, I don’t have much data for very long-dated expiries.

Next, I broke down ITM rate by DTE to see whether longer time-to-expiry actually improves the odds.

Since each DTE had a different number of samples, I asked ChatGPT to run a weighted linear regression (WLS) to account for that imbalance.

Result: +10 DTE would change ITM rate by about 10 × 0.078% = 0.78% (less than 1%). Basically following a 0DTE or 60DTE will still give you around 30% ITM rate.

Limitation and possible next step

Even if ~70% of these calls expire worthless, it doesn’t automatically mean the whales lost money they most likely have exited earlier for a profit. A better next step would be to track the stock’s return from the tweet date to the option’s expiry, then compare it against a benchmark like the S&P 500 to see whether these picks actually outperform over that window.

Following charts compare the stock variation between the timewhale open the position and the call expiry.

Conclusion

• Expired calls were ITM ~29%
• Longer DTE barely improved ITM rate

My journey with Grab started in 2018 when I was looking for new challenges after almost 3 years as an Android (and iOS) engineer in my company. I looked at several tech companies in Singapore since I was already based here. The big names in Singapore with fast growing mobile (IOS / Android) teams at that time were Shopee and Grab. I directly thought that Grab would be a great place to work given how fast they are growing their tech team in Singapore. So I decided … not to apply (yet).

Interviewing

When you are offered a chance to be interviewed, you definitely don’t want to mess up your chances and come across as unprepared. I sought and found different information about the interview process and what I should focus on in order to maximise my chances at the interview. After 2 months of doing interviews for other companies and learning from their feedback, I decided to apply to Grab even though I didn’t feel fully ready. After 3 rounds, I received an offer and I accepted it.

Although I don’t recommend doing mock interviews since it’s time consuming and you are wasting interviewer time as well. If you want to prepare for an interview at Grab I wrote an article about it.

Onboarding: 1st day at Grab

There we go, Monday 7th May 2018. 10 am, hangover from the weekend, Marina One tower level 23rd at the Grab’s headquarter with 50 new “Grabbers” (The name given to Grab’s employees) onboarding the same day as me. Yup at that time Grab was onboarding new joiners every Monday by batches of not less than 50 new joiners. Fast growing you said ?

The onboarding took the entire day. We got an introduction to the company, the business and different verticals in the morning and a “GrabCar’’ immersion in the afternoon. The onboarding involves all full time Grabbers and is not specific to Software Engineers. In the afternoon we went to the office car park where our assigned Grab driver partners were waiting for us. We got to spend 1 hour in a GrabCar with a driver, picking up customers. This experience is essential to get familiar with our Ride-hailing core business and collecting feedback from customers.

Note: This onboarding was in 2018 and has, since then, been updated to include other core verticals like GrabFood.

During the onboarding, I should have normally got contacted by my “GrabBuddy”. A person from your future team who is helping you to get onboarding in the team). Unfortunately my GrabBuddy was attending a conference on the other side of the world in the US. So I had to meet the team and introduce myself. Fortunately the team was very welcoming and I wasn’t the only person joining this team on that day.

My focus area at Grab

I joined a team called CX (Consumer eXperience) responsible for transforming Grab with multiple services into a “SuperApp”. I stayed in the CX team during my entire journey with Grab, but we had a lot of internal changes and different projects.

Over 3 years I had to work on several projects. From the new home page to the global search functionality. I also worked on different user centric features to help grab in becoming south-east Asia leading SuperApp.

I also worked on Engineering driven projects which include the “App performance project” where we focused on app startup time, memory consumption ,network usage optimization and overall crash rate.

Learnings and Takeaways

• Go bold and learn from your mistakes. Two bold changes I made caused issues and were not caught before release despite all our safeguard and process in place. This led to releasing hotfix 🥴. I wrote and presented a post-mortem with root cause, learning and action items. This helped in closing gaps in our workflow and the same issue will now be caught before landing on production.
• You need to set goals and learn from feedback to grow. At Grab, you will get to work with your manager to set up personal Objective & Key Results (OKRs) which include growth areas. When you start as a Software engineer, you have mostly 2 career choices: Individual contributor (Engineering branch) or Engineering manager (Management branch). I was unsure on which branch I wanted to grow. By not knowing and deciding on which area I want to grow, I missed some opportunities to learn and grow on different aspects of both branches. In my opinion, it’s better to focus and set goals for a branch. For example: if you’re on the Engineering manager side and later realise that it may not be exactly the career path that you want, the takeaway is that you understand the scope better, and then take action. This is better than never deciding and not growing into your desired career route.
• Feedback is the key to grow for yourself and others. Grab has a bi-annual performance review. While critics have found this to be time consuming and unproductive, those milestones offer more opportunities for you to provide and receive feedback. It’s important to keep the feedback specific with examples rather than general and meaningless just for the sake of giving feedback. The feedback I have received helps me to improve on my work and collaboration with my peers. While my hard skills were recognised, I had weaknesses in soft skills like communication. I have focused on this area by attending workshops and collecting more feedback for different situations. I have then improved a lot on this area but it’s always a work in progress.
• Interviewing is harder than being interviewed. I got the opportunity to conduct technical interviews. During my turn at Grab, I made more than 50+ interviews and several candidates received job offers. Assessing candidate technical skills is not something straightforward. I have worked with other interviewers on improving our interview process, simultaneously improving our expectations and having a more fair assessment from an interviewer.
• Learn how to adapt. When you join a company who onboards 50+ persons every week, you can expect a lot of internal reorg. The first 2 years, our team and projects were changing frequently. However, for the past year (2020–2021), things are more stable (At least for our team) with less frequent internal changes. Things are moving fast at Grab, I learnt how to be less impacted by workflow changes and how to adapt to new projects and new teams.
• Focus on what matters. A lot of things are happening at the same time at Grab. However, not everything is equally important. I learn how to focus on what matters to me and where I can make the most impact. You can clearly make a huge impact at Grab! All the managers I worked with are very open and supportive of engineering initiatives. I proposed and drove some initiatives (E.g: Dropping support for Jelly Bean and Kitkat) and closed some gaps in our process.
• Process is everything. Grab has a process for almost everything like making a new release, reacting to production incidents or proposing new ideas through RFC. Those processes are what make the company stable and robust. These processes also provide stability and the ability to go bold. I was never scared of making bold changes because I knew that we have many safeguards in place. And eventually if I’m causing some issues that land in production, this creates more opportunity for us to learn from our mistakes with our process related to production incidents. Over 3 years I have identified some gaps in our process and defined new ones that improve our workflow.

What’s next

Over the last 3 years I got contacted by many different companies. Lately, one company approached me with an opportunity to work on a fast growing and large scale project. I decided to proceed and I cleared all the interviews. I have then resigned from my position at Grab.

Conclusion

Overall I will keep a positive record from my journey at Grab. I got the opportunity to work on a large scale system with hundreds of other talented developers. I have built strong relationships with some of them and will never forget them. I learned a lot from my peers and was able to make (positive) impact on millions of users and on overall Grab’s process and workflow. I also have a better visibility of my career path and area I have to focus on in order to reach my goal.

In this article I’ll share my experience of working, time-to-time, remotely. From 1 day (Work from Home) to 1 full month remote in different timezone (7 hours time difference). Working remotely is the new trend in tech companies. however it’s not scaling well for all team process.

Synchronous vs Asynchronous team

We can split team process into 2 categories: The one with Synchronous and asynchronous process. I’ll go through both with advantage, tradeoff and how is it scaling to enable seamless remote working.

Synchronous team process

Having a synchronous process is the default standard in most of the companies. This can be defined by:

• Everyone has to join a meeting at the same time
• Use Slack as instant message service

However, this process will not be scalable for seamless remote work. Having a scrum meeting every morning at 10am SGT regardless where you are in the world. It can become a nightmare if you are working from with 7 hours time difference.

Synchronous company process can only have employees working remotely in the same region / timezone

Asynchronous team process

This process is the most suitable to enable seamless remote working, wherever you are in the world. It can be defined by

• Asynchronous meeting (Using tools like https://carrot.io)
• Communicate with emails

Asynchronous meeting will scale better for remote employees (No timezone required). However, making alignment can become more complex or take more time. It can add extra idle time and delay to all communications.

When sending an email you don’t expect to receive a response within the minute unlike when you are sending an instant message (E.g: On slack). Having email as a backbone of communication can scale better and create less frustration during idle time.

Which process for which team

Having an asynchronous process will be more suitable if your team has a full time remote member. If you don’t have any, or if it is partial remote, you can probably accommodate with the synchronous process and skip a few of the meetings that are not critical. If your team only has 1 remote member, you can also accommodate and find a middle ground to avoid the tradeoff of being 100% async team.

Working at Grab for 2 years on the Android Passenger App, I had the opportunity to take interviews very quickly. The company is growing insanely fast (We still have a lot of open positions). I took more than 50 interviews and hired a few of the candidates. Today I’ll share about the interview process at Grab, for mobile engineers, and how to maximise your chances.

This is a personal thought based on my experience and may not reflect your interview experience. Opinions expressed are solely my own and do not express the views or opinions of my employer.

Interview process

Grab’s interview process (For mobile engineers, Android or iOS) is composed of a screening process plus 3 interviews rounds with a total of 5 interviews. This includes 2 back-to-back rounds with engineers, and a final round with an engineering manager.

Codility Test (1 hour)

Upon submitting your candidature, a Codility test will be sent to you. It’s mostly some simple algorithm question. Grab receives thousands of candidates and this round will help, in my opinion, filter all non-motivated candidates. Don’t feel offended if you receive this test even for a senior position. If you are willing to spend 1 hour solving some algorithm questions we can proceed forward.

HR Screening (30 minutes)

Similar to the Codility Test, this screening session is a face-to-face (often via Zoom, a web-based video conferencing tool) conversation, designed to help us understand if you match our skill requirements and possess our cultural principles.

Engineering round (2 hours)

During these 2 hours you will meet 2 engineers (1 hour each). They are selected based on availability and experience. It may not reflect the team you will be joining. The 2 rounds should include live coding.

1. Engineer A (1 hour) : Data Structures, Algorithms, Android, OOP
2. Engineer B (1 hour) : OOD, Solid principles, Architecture & Design

I typically get involved at this point, sometimes taking the first part (Data Structure) or the second part (Architecture & Design). This is how I generally structure the interview:

• 5 minutes candidate introduction: Past project and problems solved
• 15 minutes for general question (Based on topic mentioned above). I can’t disclose the questions 🙊
• 30 minutes of problem solving including live coding. This is the most important part of the interview. (I give you some tips below)
• 5 minutes of Q&A: Candidate can ask any question and we will answer.

Final round with Engineering manager (1 hour)

The last round focuses on technical skills and cultural fit. Final decision is made by the engineering manager.

Hiring committee

Grab does not have a hiring committee for each candidate. However, if we have opposite feedback about the candidate (e.g. “Strong yes” and “Strong no” given by engineers), everyone involved during the process will join a 30 minute meeting where we discuss and determine the final outcome (“debrief”). We will also decide on the grade issued to the successful candidate (e.g. Junior vs. Senior).

Tips for the interview

Understand the problem. During the live coding of the engineering round, make sure you analyse the problem properly. Don’t jump into a solution directly. Every software engineering problem has multiple solutions. Discuss the high level ideas and assumptions of your solutions before working on the implementation. Justify all the choices you are making. And most importantly: Do not make assumptions. Clarify with your interviewer if you are unsure of his/her asks. Think about the Grab scale with millions of users. Make sure your solution will scale for the company.

Don’t cheat. If you are doing the interview remotely, do not google the question to answer. I saw this a few times and it’s obvious. If you don’t know the answer just say it. For the Codility round, there are a set of algorithms in place to detect if the candidate is cheating and copy pasted a solution online. More importantly, Grab values Honor as one of its main principles in an employee. So don’t cheat!

Learn about the company and the business. Try to ask questions in the Q&A session that can reflect your interest in the company.

Prepare for the interview. Before jumping into the 2 hours of rounds. You know the main topic. So spend some time to review the basic and make sure it’s fresh in your mind.

Be in a quiet environment. Interviews can be done remotely via teleconferencing. However please make sure that you are in a quiet environment, have a decent mic and a stable connection. When the communication is choppy it is hard to get your message across and will reduce your chance of receiving a positive feedback.

Have a strong reason to join Grab. My last question is always “Why do you want to leave your current company and why do you want to join Grab?”. DO NOT REPLY:

“Because you offer a good package”

“I saw your office on the internet and it looks nice”

“I don’t want to, actually”

Believe it or not, but I really got those answers during an interview.

Join Us !

Interested in joining the Grab family? Check out http://grab.careers for available roles today!

If you are about to start your journey with Grab, I wish you all the best!

Thanks for reading this article. Be sure to click 👏 below to recommend this article if you found it helpful. It would let others get this article in feed and spread the knowledge.

This article will explain the journey of an image from a developer point of view. Starting when you receive an image from the designer until it’s display in the most optimised way.

This article is following the talk I made during a Singapore Kotlin User group meetup at Google Singapore. Slides and video are available bellow.

Before adding an image to your app

Before adding your image to your application you can apply some optimisations. There are a bunch of tools available online that can do that. However in most cases it’s a lossy compression. Feel free to use any of those:

PNGQuant, ImageMagick , PNGGauntlet, PNGOut, PNGCrush, OptiPNG, CryoPNG, PNG Compressor, Yahoo Smush.it, PNGOptimizer, PunyPNG, TinyPNG, PNGWolf, Advpng, DeflOpt, Defluff, Huffmix, TruePNG, PNGnq-s9, Median Cut Posterizer, scriptpng, pngslim, zopfliPNG

How it works

All those services are pretty much applying the same algorithm which are doing as follows.

• Reducing Colors: Reducing the number of unique colors in your image
• Filtering: Reduce dynamic by how variant adjacent pixel colors are to each other.
• Deflate: Remove redundant information
• Indexed images: Chooses the best 256 colors to use, and replaces all your pixels with an index into that color palette.

After optimisation, your image can be reduce from few Mb to few Kb. This will reduce the impact of your image on your APK size.

Memory footprint for a full screen image

Bitmap can be seen as a 2 dimensional array of bit. If we take the case of a full screen image on a Full HD device.The footprint can be calculated this way:

• Screen width = 1920px
• Screen height = 1080px
• Total = 2,073,600px

If we are drawing a black and white image. We only need 1 bit per pixel. So the memory footprint will be 2,073,600 bit (0.26MB)

Sadly not all our images are black and white so we need more data to represent the color of each pixel. On Android. We can choose the precision we would like to have.

Here is a summary table from Android documentation. For each precision. I added the total memory footprint for a full HD image.

I didn’t add the memory footprint when using Hardware. However, it will only use half of the memory compared to RGG_8888 for the exact same result. The system is storing pixel data in graphics memory instead of Java heap. It’s default settings when loading images with Glide.

However, hardware bitmap has some tradeoff. It’s only available starting Android O so it won’t benefit to old / low end devices. Each image will also consume a file descriptor (FD) which can lead to crash.

Different caching mechanisms

2 different caching mechanism can be used for solving 2 different problems. LRUCache and Bitmap Pool.

LRU cache (Least Recently Used)

LRU cache is useful for images that are still used. We can keep a final image and avoid redundant computation in case of resizing for example.

Bitmap Pool

Bitmap Pool is for images that are no longer in use. The memory space allocated by the previous image can be reuse. The system will draw the new image on top of the old image. Starting SDK 19, Bitmap pool support different images dimensions.

This two mechanism will help reducing the pressure on the memory. It will reduce the number of garbage collection (GC) or can even help reducing Out Of Memory crash (OOM).

In short: Keep it simple and use a library

Library like Glide and Fresco implement all those optimisation and that’s the main reason they are so good at it.

Fresco: #1 choice (Created by Facebook)

• Most advanced but complex APIs

Glide: Best compromise (Recommended by Google)

• LRU cache
• Bitmap pool
• Hardware bitmap / Pixel Color configuration
• Gif support

Android Vector Drawable: Differences with SVG and tradeoff

SVG support complex capabilities like Blur, filter effects, Embedding other images, Animated gifs and possibility to executing arbitrary javascript. Supporting everything on Android was not suitable for Android.

Android runs on constrained mobile devices so supporting the entirety of the SVG spec wasn’t a realistic goal. (from: Understanding Android’s vector image format: VectorDrawable) [ Nick Butcher: Android developer at Google]

Android Vector Drawable can be seen as a simpler version of SVG standard. Only basic operation are supported to draw the images. Here is an example of how Android will interpret those information create the render.

• M move to
• L line to
• C (cubic bezier) curve to
• Z close (line to first point)

Parsing and rendering Android Vector Drawable

1. Inflation: Parse your AVD file into VectorDrawable modeling the the paths, groups etc you declare
2. Drawing: These model objects then have to be drawn by executing Canvas drawing commands.

Steps are proportional to the complexity of the vector and the type of operations you perform. Drawing stage only needs to be performed once and can then be cached to a Bitmap

Vectors provide the aforementioned benefits but at the cost of being more expensive to render.

Optimising SVG and Android Vector Drawable

Before importing SVG to Android to you use Svgo. It can help reduce complexity and remove unnecessary meta information added by editor like photoshop.

After importing the image, you can use Avocado to optimise the Android Vector Drawable.

Note that both library are lossy compression. However from my experience the difference is not noticeable.

Common issues with Android Vector Drawable

AVD are constraints by 3 rules. On Android, Lint warning are implemented and Android Studio will highlight in the following cases. I strongly suggest to follow and fix those warning otherwise you will increase the memory pressure and it can even lead to crash.

• “android:width” : cannot be larger 200dp
• “android:height” : cannot be higher 200dp
• “android:path”: cannot exceed 1000 chars

Learn more about this topic

Here I some great resources you can find to want to dig deeper.

• https://medium.com/@duhroach/reducing-png-file-size-8473480d0476
• https://medium.com/appnroll-publication/what-is-new-in-android-p-imagedecoder-animatedimagedrawable-a65744bec7c1
• https://medium.com/androiddevelopers/understanding-androids-vector-image-format-vectordrawable-ab09e41d5c68
• https://medium.com/androiddevelopers/using-vector-assets-in-android-apps-4318fd662eb9
• https://medium.com/androiddevelopers/draw-a-path-rendering-android-vectordrawables-89a33b5e5ebf

Thanks for reading this article. Be sure to click 👏 below to recommend this article if you found it helpful. It would let others get this article in feed and spread the knowledge.

Working on Android App Start optimisation for the past 6 month at Grab (We are hiring), We did a lot of profiling and we immediately saw a lot of operations are done by the system just before you see the first frame.

This document will explain the 7 main steps requires to launch any Android App. We will also measure each steps to get the actual cost. We will use MonoClock from Kotlin to measure time delta.

This will also help you in monitoring our application start performance and detecting performance regression.

All pieces of code of the article are summarise on a github sample project (Hello world app). https://github.com/lucas34/Android-AppStart-Breakdown

We will only talk about the Cold App Start flow (app is not in memory). Also, we only focus on the app icon as entry point and not when the application is triggered by a deeplink or a push notification.

The 7 steps of the Android App Launch

1. createAppContext: Loading the application binary into memory
2. makeApplication : Create Application class and init class attributes
3. installContentProvider: Instantiate and call onCreate for content providers
4. callApplicationOnCreate: call Application onCreate method
5. newActivity: Create activity class and init class attributes
6. attach: Attach context to the activity
7. performOnCreate: call activity.onCreate method

Let’s now see in detail all 7 components and how we can measure them.

1. createAppContext

The very first thing the android system is doing when you tap on the icon is creating Application process and the main thread.

The main operation involved is DexFile.openDexFileNative which will load the application binary (The DEX file to simplify) into memory. This operation is pretty costly ~350ms According to Google

At this point our application is not even created yet so we don’t have control to measure it. However since everything is done in main thread, on the first line of code that will be executed by the system we will get the time since the main thread is alive. This will count all the operations happening before we had control and DEX loading is the main contributor according to the call stack.

2. makeApplication

Once our application binary is loaded into memory, the system will instantiate the application class and init all the class attributes from top down (Class attributes defined at the top of the class are init before the one at the bottom)

So if we want to measure all the attributes definition we do as follow

In this case we are measuring the time it takes for MyDatabase and MyNetwork to init. If anyone is adding a new class attribute or create an expensive object (Open the database in the constructor) we will be able to measure automatically.

3. installContentProvider

Content providers gets initialised after Application class but before Application.onCreate is called. To measure this we can do as follow

The delta between the end of the Application class attribute instantiation and the call of onCreate is measuring all content provider creation plus the onCreate call (For content provider).

Some libraries like Facebook SDK or Firebase use content provider to automatically init their library. This is pretty sneaky since adding a dependency to your project can increase your app start dramatically.

4. callApplicationOnCreate

This is the method you should be familiar with. In kotlin we can do this wrapping around the method to measure everything.

Code that will be added or modified inside the method will always be tracked and can prevent other dev to accidentally messing up with the measurement. Like for example adding code after we get the time (It happened 😥)

5. newActivity, 6. attach and 7. performOnCreate

Last 3 method measurement are pretty similar to the samples I gave before so I won’t explain more. If you want more detail please check the sample github project. (https://github.com/lucas34/Android-AppStart-Breakdown)

Here we go, we have our breakdown for each of the 7 steps with a relatively accurate metric for each of it. We can wrap all the metric under one data class. If we sum-up everything we very pretty close to the Process elapsed time which is the absolute app startup time

Thanks for reading this article. Be sure to click 👏 below to recommend this article if you found it helpful. It would let others get this article in feed and spread the knowledge.