I hadn’t touched any serious LeetCode-style prep until a recruiter reached out about 3 weeks ago with the Amazon OA. The last time I studied Data Structures and Algorithms seriously was back in 2016, during my CS undergrad — second year, some foggy lectures, and probably a lot of “this’ll never be useful in real life” vibes. Fast-forward to 2025, and boom — time to rekindle that long-lost romance with Recursion, DFS, and their chaotic friends.

Once I got the OA invite, I did what any rational human would do:
Panic slightly. Then full send into LeetCode.

For two straight weeks, I went full try-hard mode. Woke up early, brewed an aggressively large coffee, and started knocking out the Blind-75 list. Covered all the hot topics: Priority Queues, BFS/DFS, Trees, Graphs, Greedy, HashMaps, DP, Sliding Window. It was like boot camp, but for brain cells.

I even started seeing LeetCode problems in real life.
“Find the optimal seat in this bus” — classic greedy problem.
“Why is this checkout line moving faster?” — sliding window optimization.
“Why is my brain melting?” — probably recursion with no base case.

I felt… prepared-ish.
But deep down, I knew — this is Amazon. This isn’t a chill walk through a tree traversal. This is LeetCode Extreme Edition

The Online Assessment

**Q1. Search-style Optimization Problem
**It looked familiar — classic Min-Max search range thing, just like Koko Eating Bananas… Except this Koko was armed and hostile.

**Q2. Binary Search + Sliding Window
**You know the kind of problem that looks medium, maybe even friendly at first… Then turns around and **roundhouse kicks you in the face?
**It turned out to be a hard-level combo of Binary Search + Sliding Window — the kind of tag team you’d usually expect to see deep in a LeetCode Hard dungeon, not casually tossed into an OA.

**System Design, Working Style Survey & LPs Section
**A much-needed breather. No code, just multiple-choice questions about system design, collaboration, ownership, and leadership.
Honestly? Felt like I crushed this part. I mean, I do work well with others… especially if they bring snacks.

The Aftermath

The assessment didn’t go well.
Was it humbling? Yep.
Was it also super educational? Absolutely.
Amazon’s OA isn’t just about solving problems — it’s about solving them fast, accurately, and without any fluff. No IDE-level debugging, no mercy; just you, a blinking cursor, and a clock ticking down.

Brutal

But here’s the thing:
I learned a ton.
My DSA instincts have improved dramatically.
Time pressure turns even simple problems into psychological warfare.
The OA isn’t the goal. It’s just a checkpoint in a longer journey.
And surprisingly, I’ve started to genuinely enjoy the process.

This wasn’t a loss — it was a training arc.
(Okay, maybe a loss, but one with XP gain.)

This isn’t a failure story. It’s just a progress checkpoint.
We move.

Amazon, let’s reconnect after 6 months.

Subsequently, you execute the following command in a terminal to compile and generate a production build .apk file; the generated file will be located under android/app/build/outputs/apk/release/app-release.apk.

cd android
./gradlew assembleRelease

After generating the .apk file, you install it on your Android device, and as soon as you open the app, it crashes.

You don’t know what went wrong; you start rechecking to see if you missed any steps mentioned in the React-Native documentation; you start searching for solutions on StackOverflow and Github and try out all the random solutions you discovered. You feel frustrated, stressed out, and filled with self-doubt. Imposter syndrome kicks in, and you regret choosing React-Native over other mobile development frameworks.

TL;DR: I had a similar feeling after going through a lot of answers and comments on StackOverflow and GitHub issues. Here are the steps I followed to find and fix the issues with the release build.

Using Logcat CLI to determine the issue

Connect your device to your machine (ensure USB debugging is ON) and run the following command on your terminal.

adb logcat '*:E'

Find out more about Logcat CLI syntax here.

After running the logcat tool to log system logs, I had two issues that were causing the application to crash.

1. couldn’t find DSO to load: libjsexecutor.so

I solved libjsexecutor.so error by adding enableVmCleanup: false in build.gradle file inside project.ext.react array as mentioned in the GitHub comment here.

project.ext.react = [
    enableHermes: true,     // clean and rebuild if changing
    enableVmCleanup: false, //this
]

2. java.lang.RuntimeException: Unable to load script.

To solve this issue follow the steps below

• Remove index.android.bundle from android/app/src/main/assets if the file already exists or just run the following command (ensure you’re on your project’s root directory).

rm android/app/src/main/assets/index.android.bundle

• For generating your android bundle run the command given below, this will generate index.android.bundle file inside android/app/src/main/assets

npx react-native bundle \
--platform android \
--dev false \
--entry-file index.js \
--bundle-output android/app/src/main/assets/index.android.bundle

• Now run the following command to generate a release build

cd android
./gradlew clean
./gradlew assembleRelease

Hopefully, this will fix your app's crashing problem, and your app should be ready for deployment.

Feel free to provide any feedback and improvements, happy coding…