---

Most Important Interview Questions Asked :
+++++++++++++++++++++++++++++++++++

1. Describe major Challanges faced in your Projects. ( Production-Issues / Challanges / Complex technical problem )

   • Universal-Wallet: Resolving scalability issues. Scaling bridge-wallet (uWallet) stateful services. Making it stateless by moving local data (LRU) to Redis, so requests are not bounded to server avoid sticky sessions. Also rebuilding Cache in case of disaster for most recent requests only.

   • Bid-Server: Resolving scalability issues. Scaling stateful service like bid-server which was wss-server. Using Consistent Hashing for load distribution for stateful services (bid-server aka wss-server), to ensure that a request for a particular state is always routed to the same instance. ( Alternate is using Load Balancer with round robin w/ Sticky sessions). Sessions State Replication for stateful services aka using replication and fault tolerance techniques to avoid data loss in case of instance failures.

   • Fiat OnRamp: Handling prod issues for Binance transaction failures during peak trading hours. Sudden surge overwhelmed backened - applied Rate-limiting, Added Redis for caching. Adjusted auto-scaling policies. Added reCaptcha for ensuring legitimate requests.

   • Ledger Service: Performace Issues on production ( seen on Grafana) -

     • a.) Slowness in DB, transaction deadlocks (sorting of public key to help prevent deadlocks during balance update of payer/recipient ) ,
     • b.) Removed unnecessary transaction blocks.
     • c.) Offloading CPU-intensive tasks to seperte threads ( calculating pub_addr, send emails),
     • d.) Optimising sql queries by adding indexing, removing select * , removing Joins,
     • e.) Offloading reads to seperate replica (master-slave) for better write performances. Also archiving data to S3 kept DB lean and performant. Reducing replication-lag b/w master-slave via optimising n/w and enabling multi-threaded replication.
     • f.) Removing the thread lock used to ensure the counter is incremented and used atomically. asycnio and inherently grpclib are not multithreaded so this lock not needed and is a potential performance issue. All improved performance and provided scalable and efficient solutions reducing server loads & minimize energy consumption.
     • g.) Resuing DB connections from connection pool to improve performance. Basically, instead of opening and closing db connections for every database operation, a pool of reusable connections is maintained.
     • h.) Better exception handling.

   • Exchange DOoS Attack: Handling DDoS for Withdrawals via Scripts: Implementing Rate-limiting, Introducing reCaptcha to prevent Bots.

   • Delivering token offchian for Bianace-integration. Build exchange.

2. Most Impactful Project :

   • Binance Integration as it helped 20M DAU users to ease In-app purchase.
   • uWallet Integration because it was standalone wallet for integration w/ Speed, BTFS, Dlive, TronTV.

3. Improvemts:

   • Webhooks implementation for binance-watcher, instead of polling for events. Webhooks, on the other hand, are event-driven. When event occurs, server notifies the client by sending an HTTP POST request to a pre-configured endpoint, eliminating the need for constant checking. Used in Mailgun email-status fetching and Binance payment-status. Disadvantages : client endpoint is unreliable or temporarily down. Also Webhooks require careful security measures, such as verifying request authenticity, which adds complexity.

4. Scalability: How did you scale your system ?

   • Load Balancing:: Adopting Load balancer which would redirect incoming traffic on round robin fashion to internal services. Load balancers can use various algorithms, such as round-robin or least connections, to distribute traffic.. We used Ngnix for SSL termination and rate limiting and routing requests to endpoints.
   • Auto-scaling:: Services use to auto-scale during peak hours by kubernetes.
   • Increased Availability: Multiple AZ in same Region - provided more redundancy and fault tolerence.
   • Database Sharding: Well we thought on using Vetess for sharding for our mysql, but then we started with RDS - Master-slave that helped to segregate read / Write traffic. (FYI - In reality we only used master DB and archived tabled periodically to S3 for Read/Data-analysis purposes. )
   • Asynchronous Processing: Adopting asynchronous communication/processing for exchange and simplex transitions. Via watcher in exchange and simplex watcher which would wait for events and make further processing. This allows the system to quickly respond to user requests while processing intensive tasks separately.
   • Caching: Adopted Caching via Redis for faster reterival of frequent data instead of reterivals from database .
   • Containerization and Orchestration: Use containerization (e.g., Docker) and orchestration tools (e.g., Kubernetes) to deploy and manage scalable and resilient applications. Containers provide consistency across different environments and simplify the scaling process.
   • Database Optimization: Optimize database queries, use appropriate indexing, and consider database caching to improve database performance. Choose the right database architecture for your workload, whether it’s relational, NoSQL, or a combination.
   • Monitoring and Optimization: Implement robust monitoring to identify performance bottlenecks and areas for improvement.
   • Making uWallet stateless by moving state to external (LRU to Redis).

5. Accomplishments:

   • Build ledge/airdrop serivce, which accounts for 450 M Speed wallets till date, 20M DAU, 60M Channels/day. Successful launch of Fiat-OnRamp, uWallet integration w/ Speed, Dlive, TronTV, BTFS. Performance Improvements for exisitng services (ledger/ DB indexing).
   • Increased the trading volume upto $50K/month and helping 20M users to ease out token purchase directly In-app via Fiat-onramp.
   • Successfully Build uwallet which integrated with multiple product lines within company ( Dlive, BTFS, TronTV, Speed)

6. Trade-Offs ( choices made): Look into below sections.

   • Choice: Database sharding versus RDS Master-Slave architecture. Trade-off: Sharding would have offered better scalability for write-heavy loads but would introduce significant complexity in terms of database management and query optimization. The master-slave architecture was simpler but not as scalable for write operations. Furthermore Master-slave improves read scalability BUT introduces the need for handling replication lag and complexities of maintaining synchronization between master and slave nodes.
     Decision Rationale: You chose the master-slave approach initially, considering that read-heavy workloads were the priority, and you preferred the simplicity and cost-effectiveness it provided at that time. Sharding could be introduced later as the system scales further.

   • Choice: Redis caching for frequently accessed data. Trade-off: Redis reduces database load and improves read speeds but introduces eventual consistency issues where the cached data may not immediately reflect changes in the database.
     Decision Rationale: The trade-off was justified because high throughput and low-latency responses were crucial for user experience, and eventual consistency was acceptable for most use cases (e.g., transaction history or user session data).

   • Choice: Use of ECDSA for signing messages and mTLS for service-to-service communication. Trade-off: While ECDSA ensures a high level of security for identity and data integrity, it comes with computational overhead, especially when verifying signatures at scale. mTLS provides enhanced security but requires certificate management, which can introduce operational complexity.
     Decision Rationale: You opted for the additional computational cost to ensure data integrity and secure internal communications in a distributed microservices architecture, thus minimizing attack vectors.

   • Choice: Rate-limiting (leaky bucket algorithm) and DDoS protection via CDN. Trade-off: Rate limiting ensures protection from abuse, but it can potentially block legitimate users during traffic spikes or false positive DDoS detection.
     Decision Rationale: This strategy was chosen to protect system resources from being overwhelmed, prioritizing system availability over the risk of blocking a few legitimate users.

7. Advantages/Disadvantages of Microservices.

8. How did you handle a.) Performance b.) Security c.) Consistency d.) High Availibility (Mater-salve, Multi-Region replications)

---

---

1. Handling Incidents and Outages:
   Question: Describe a time when you were responsible for handling a major production incident. How did you approach the situation, and what was the outcome?

Response-1: "During my time at Rainberry, we faced a critical issue with our BitTorrent Speed service where users experienced transaction failures during peak trading hours. I led the investigation, utilizing our monitoring system built with Prometheus and Grafana to trace the root cause. We discovered that a sudden surge in Binance transaction volumes overwhelmed the backend, leading to system delays. I quickly implemented rate-limiting measures, adjusted Kubernetes auto-scaling policies, and optimized our Redis caching strategy. As a result, we reduced downtime, improved transaction success rates, and minimized impact on users​(ADITYA KUMAR VERMA)."

Response-2: Multiple deployment of monitor-service (single-cluster service), during cluster upgrade/switching from Prod-1 cluster to Prod-2 cluster. Causing deadlocks as both serives were trying to access and close same transactions casuing double refunds (in case of race consitions). Users saw weird change in their balances as leechers were double paying to seeder. We also saw discrepencies in Hot wallet. But luckly we were able to fix this ASAP since we have robust monitoring and alerting system and we got notified and immediately took service down. Later we fixed couple of transactions manually.

Response-3: Multiple deployment of archivertoS3 (single-cluster service), during cluster upgrade/switching from Prod-1 cluster to Prod-2 cluster. It caused race condition in accessing tables and locking columns and degrading performance of whole database as tables were locked and both services were trying to access same rows simultanelosyly.

---

2. Problem Solving and Ownership:
   Question: Can you give an example of a complex technical problem you’ve encountered? How did you solve it?

Response-1: Universal-Wallet: Resolving scalability issues. Scaling bridge-wallet (uWallet) stateful services. Making it stateless by moving local data (LRU) to Redis, so requests are not bounded to server avoid sticky sessions. Also rebuilding Cache in case of disaster for most recent requests only.

Response-2: "At Oracle, I was the technical lead for implementing a high-availability feature for Oracle’s Flash Storage System, which required designing a failover and failback (FOFB) module using Python and C++. One of the biggest challenges was ensuring data integrity during failover while maintaining low latency in our iSCSI traffic. I designed a path selection and recovery mechanism using a gossip protocol that dynamically rerouted data during failures, improving system resilience and reducing downtime. This solution was later adopted as a standard feature across several Oracle storage systems​(ADITYA KUMAR VERMA)."

---

3. Collaboration and Communication:
   Question: Tell me about a time when you had to work with a team of engineers to implement a large-scale project. How did you ensure successful collaboration?

Response: "At Rainberry, I led a cross-functional team to integrate Binance’s Fiat On-Ramp with our BitTorrent Speed service. The project involved multiple modules—backend microservices developed in Python and Golang, and front-end payment gateways. I coordinated daily stand-ups to track progress, set clear deliverables, and used tools like Jira for project management. We also held regular knowledge-sharing sessions to ensure the entire team understood the intricacies of Binance integration. As a result, the integration was completed on time, increasing the trading volume to $50K per month and improving user satisfaction​(ADITYA KUMAR VERMA)."

---

4. Dealing with High-Stakes Environments:
   Question: How do you prioritize tasks when you have multiple critical issues happening simultaneously?

Response: "When multiple critical issues arise, I first assess the potential impact on the system and end users. For example, during peak trading hours at Rainberry, we encountered simultaneous issues with our Binance integration and Redis caching. I prioritized addressing the Binance-related issue first, as it directly affected financial transactions, while delegating the caching problem to another engineer. By triaging issues based on user impact and involving the team effectively, we managed to restore full service quickly without major disruptions​(ADITYA KUMAR VERMA)."

---

5. Continuous Improvement:
   Question: What processes or tools have you implemented to improve system reliability and reduce downtime?

Response: "Almost every project, I implemented a robust monitoring and alerting system for the BitTorrent Speed backend using Prometheus, Graphite, and Grafana. This setup allowed us to proactively detect issues like high memory consumption or API latency before they escalated. Additionally, I configured Slack alerts to notify the team instantly when key metrics crossed defined thresholds. By leveraging these tools, we improved system reliability and drastically reduced downtime, enhancing user experience​(ADITYA KUMAR VERMA)."

---

6. Failure and Learning:
   Question: Describe a time when something you implemented didn’t go as planned. How did you respond, and what did you learn from it?

Response-1: At Rainberry, I implemented and deployed a mining project for blockchain users ( gain airdrop based on the mining rewards) with new release, which caused downtime and degradation of exisitng services becuase it cased havey loads from all exisitng-users (50 Million active users) at SAME time ( unlike new users onboarding ~ 30K Users). This went wrong as we didn't evaluate the impact on our infrasctures. Infact that was also true testing of load we could handle. We had to rollback the feature and Imposed rules like only new accounts to experiement with mining. Imposed some rate-limiting etc. Learning was to compaletly evaluate the impact on new release on uses and load handled and proper monitoring / alerting services. FYI : Proof of work (PoW) is a cryptographic method used to verify the accuracy of transactions on a blockchain network. A miner calculates a valid alphanumeric code, or hash, to add a block to the blockchain

Response-2: Another proejct we can talk about monitor-service (single-cluster service) which accidently deployed in two cluster during time of switch from existing-cluster to new-cluster and caused issues with transactions getting close twice ( aka double refunding ). Causing issue with User's balance and discrepency in Hot wallet. However since we immediatly got notified about this issue via slack alerts, we immediately stopeed and reverted bad trasactions manually.

Response-3: "At Oracle, I worked on the Fabric Manager module to improve iSCSI traffic routing. Initially, I implemented a static path selection algorithm, but during high traffic loads, this caused bottlenecks and increased latency. After reviewing the logs and running performance tests, I realized that dynamic path selection was required. I redesigned the module to include adaptive routing based on real-time traffic metrics. This experience taught me the importance of thoroughly testing under peak load conditions and being open to iterating on solutions​(ADITYA KUMAR VERMA)."

---

7. Leadership and Mentorship:
   Question: Have you mentored junior engineers? How do you balance mentorship with your technical responsibilities?

Response-1: On a recent project, I led the development of a Fiat On-Ramp integration with Binance via BitTorrent Speed, using FastAPI to facilitate token purchases with credit cards. This project involved a complex microservices architecture with components like watcher, horus-gw, reconciler, and ledger. As the technical lead, I defined the system architecture, aligned the services for seamless interaction, and guided the team to build a reliable, scalable solution that increased trading volume to $50K/month, significantly boosting our revenue.

Throughout the project, I made key architectural decisions, such as choosing FastAPI for performance gains and designing our reconciliation and ledger processes to handle high transaction volumes efficiently. I also focused on mentorship, helping junior engineers understand the complexities of microservices and encouraging them to take ownership of critical components. By promoting collaboration and providing guidance, I ensured that our team grew stronger, both technically and professionally, which was key to our project’s success."

Response-2: "At Oracle, I mentored several junior engineers as they joined the team. I set up regular one-on-one sessions to guide them through the codebase, encouraged them to take ownership of small features, and provided feedback during code reviews. Balancing mentorship with my technical responsibilities required careful time management, so I often scheduled mentorship sessions around low-priority periods, ensuring I could focus on critical tasks without compromising their learning experience​(ADITYA KUMAR VERMA)."

---

8. Adaptability and Innovation:
   Question: Tell me about a time when you had to adapt quickly to a new technology or process. How did you handle it?

Response 1: At Rainberry, I was responsible for improving how our customer support team queried and summarized historic customer issues. Initially, the process was manual, and delays were common. I quickly adapted to new technology by learning the OPL stack—OpenAI for natural language processing, Pinecone for vector searches, and LangChain for chaining queries and responses.

I introduced an innovative solution where our team could use a language model to not only query past customer issues but also automatically summarize root cause analyses. This improved response times by over 50%. Leading this project, I coordinated across teams, designed the architecture, and trained users. I ensured the solution was scalable, meeting the team's needs while fostering a culture of embracing cutting-edge technology."

Response-2: "At Rainberry, we needed to upgrade our data pipeline to handle increased data volumes from BitTorrent Speed. The existing solution based on Python’s MRJobs couldn’t scale efficiently, so I quickly had to learn and implement Kafka, Flink, and Cassandra. I adapted by studying documentation, attending online workshops, and collaborating with other engineers experienced in those technologies. Within weeks, I successfully upgraded the pipeline, significantly improving data processing speed and efficiency​(ADITYA KUMAR VERMA)."

---

a) Question: Can you describe a situation where you had to balance security with system performance? How did you approach making trade-offs?
Example Answer: While implementing OAuth JWT tokens for authentication, we had to balance the performance impact of larger payloads against the benefit of stateless authentication. After considering the microservices architecture and the need for scalability, we chose JWTs despite their size because their stateless nature simplified scaling, and the performance overhead was manageable with optimized payloads.

b) Question: Tell me about a time when you had to improve system performance without compromising security. How did you achieve both?
Example Answer: When we introduced Redis caching to improve read performance, we faced a challenge with sensitive user data being cached. To address this, we implemented encryption for cached data in Redis and ensured that sensitive information had stricter TTL policies, maintaining both performance and security.

c) Question: How did you ensure fault tolerance in your system, and what were the trade-offs involved in your approach?
Example Answer: We relied on Kubernetes for auto-rescheduling pods, which provided fault tolerance at the microservice level. However, we didn’t have cross-region redundancy initially, which meant a region-wide failure could lead to downtime. We accepted this trade-off because Kubernetes handled most pod-level failures gracefully, and cross-region architecture would be added later as the system scaled.

d) Question: Can you describe a time when you had to design a system that could scale under heavy load? What challenges did you face, and how did you address them?
Example Answer: When designing our microservices to handle fluctuating loads, we implemented auto-scaling with Kubernetes, allowing services to scale during peak hours. One challenge was ensuring that our database could handle increased traffic, so we adopted a master-slave architecture to offload read traffic to the slave nodes. This solution allowed us to scale without introducing significant complexity into our database management strategy.

---

---

Other References :

https://github.com/adityakrvermatron/Leap.ai-Rock-the-Behavioral-Interview

https://www.levels.fyi/blog/amazon-leadership-principles.html

https://leetcode.com/explore/interview/card/leapai/

https://leetcode.com/discuss/interview-experience/1532708/tips-for-answering-few-tricky-behavioural-interview-questions

https://leetcode.com/discuss/interview-question/462901/behavioralleadership-questions-for-interviews

---

---

III.) BEHAVIORAL QUESTIONS BASED ON MY PROJECTS : 10/23/24: [ MUST READ ]
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

1. Handling Technical Challenges:

Question: Can you tell me about a time when you had to make a service stateless? How did you handle data migration, and what strategies did you use to ensure system scalability during peak hours?

Answer: We had a bridge-wallet REST server (uWallet) that cached data like exchange-hash and transaction metadata locally, which made it stateful. This posed challenges in scaling, especially during peak traffic hours. To address this, I designed a solution that leveraged Redis as a centralized cache store. We moved local caches into Redis, decoupling the state from the server itself, thus making the service stateless. The migration required careful planning to ensure zero downtime. We implemented a rolling deployment strategy where each node would serialize its local cache and push it to Redis before being drained.

Once the stateless transition was complete, we adopted a round-robin strategy at the load balancer (Nginx) to distribute requests across our services, ensuring that no single pod would be overwhelmed. Redis’ built-in replication ensured high availability, while its TTL feature helped purge stale data, keeping the cache lean. This allowed us to handle peak loads more effectively and easily scale horizontally by adding more pods without worrying about session affinity or local state.

Question: Describe a challenge you faced while preventing DDOS or bot attacks. What mitigation strategies did you implement, and how did you assess their effectiveness?

Answer: We faced a massive bot attack that exploited our withdrawal endpoints. The first step we took was rate-limiting using the token bucket algorithm within Nginx to limit the number of requests each IP could make over a specified interval. We then integrated reCAPTCHA on critical paths like login and withdrawal requests to differentiate between bots and legitimate users. Additionally, we set up per-user withdrawal limits on a rolling 24-hour basis, tracked through Redis, to prevent malicious users from withdrawing excessive amounts within a short time frame.

To manage the blocking, we used Redis’ atomic increment feature to keep track of user actions, so users who exceeded their limits were blocked for 24 hours. For monitoring effectiveness, we utilized Prometheus metrics and Grafana dashboards to observe traffic patterns before and after the implementation. Our SLOs showed a sharp decline in suspicious traffic, with legitimate user engagement unaffected. This multi-layered approach effectively mitigated DDOS and bot activities without compromising performance.

2. Dealing with Performance Improvements:

Question: What was a significant performance bottleneck you encountered in a production environment, and how did you optimize it?

Answer: In our ledger service, transaction handling became a bottleneck as the number of simultaneous operations increased. The root cause was traced to unnecessary transaction blocks and inefficient serialization within the service. The transactions were serialized based on unrelated fields, causing lock contention. After analyzing the data flow, I restructured the transaction serialization to be keyed by the public keys of the sender and receiver, which drastically reduced contention and deadlock issues.

Furthermore, we realized that certain non-critical transaction checks could be decoupled from the main flow and moved to asynchronous processes. By implementing a queue-based system using Celery for background tasks, we offloaded heavy processing tasks, reducing the response time of the critical API. Post-optimization, our P99 latency dropped by around 30%, and the system could handle more concurrent requests without performance degradation.

Question: Could you explain a situation where database optimization improved overall system performance? How did you balance between read and write traffic?

Answer: We initially planned to shard our MySQL database due to increasing load using Vitess, but opted for a master-slave setup using AWS RDS. The challenge was balancing read-heavy and write-heavy workloads. To optimize performance, we used read replicas (slaves) to offload read traffic, while writes went directly to the master. I introduced query optimization techniques, such as indexing frequently accessed columns and leveraging Redis for caching hot data, reducing database load.

One specific optimization involved archiving old, infrequently accessed records to AWS S3. This was managed through automated cron jobs, which periodically moved older transactions to cold storage. By keeping only the most recent data in the master DB, we were able to maintain high throughput for both read and write operations. Additionally, we leveraged MySQL’s built-in replication to maintain consistency between the master and slave nodes. Monitoring was done through CloudWatch and Prometheus to ensure the replication lag stayed minimal.

3. Addressing Scaling Issues:

Question: Can you share an example of how you managed auto-scaling in a Kubernetes environment to handle peak traffic?

Answer: In one of our services, traffic during peak hours surged to levels that the initial deployment wasn’t designed to handle. We employed Kubernetes’ Horizontal Pod Autoscaler (HPA), which scaled pods based on CPU and memory usage metrics. However, as the application became stateless using Redis, we decoupled session data from the individual pods, making it possible to scale without data loss or session persistence issues.

For auto-scaling, I configured Prometheus to monitor CPU usage, request count, and pod resource utilization. Based on the collected metrics, HPA would scale out new pods dynamically as the load increased. To avoid over-provisioning, we also set upper and lower bounds for scaling. The use of Redis as a distributed cache allowed us to scale seamlessly since no single pod was responsible for holding critical state data.

By monitoring traffic trends, we fine-tuned the thresholds for scaling, which helped us avoid throttling during peak hours. The system achieved better resource utilization and performance efficiency by only allocating resources when needed.

Question: What steps did you take to implement load balancing in your services? How did you decide between different algorithms?

Answer: For our stateless services, we utilized Nginx as the load balancer, primarily employing a round-robin approach to distribute traffic evenly across pods. Given that we used Redis to centralize session and state management, there was no need for sticky sessions, making round-robin an ideal choice for its simplicity and effectiveness.

However, we also considered other algorithms like least connections, but the traffic patterns we were experiencing were fairly balanced, and round-robin provided sufficient distribution without adding complexity. SSL termination was also handled at Nginx to offload encryption/decryption from the application layer, improving request throughput. To ensure high availability, we deployed the load balancer across multiple AZs, with automatic failover in case of a node failure.

4. Collaboration and Product-related Challenges:

Question: Describe a time when a product-related issue led to technical changes. How did you work with product managers and engineers to resolve the issue?

Answer: A significant product-related issue arose when we observed that user engagement was dropping due to wallets running out of balance, causing channels to go down. After discussions with the product team, we identified the need for better user incentives and wallet refilling mechanisms. We implemented a Golden Wallet campaign, airdrops, and integrated Fiat on Ramp to allow users to refill their wallets directly.

From a technical standpoint, this required integration with third-party payment gateways, which involved handling asynchronous payment status updates via webhooks. I collaborated with the backend engineers to ensure seamless handling of webhook events from gateways like Simplex. This change not only improved user engagement but also increased our service’s uptime by reducing wallet-related channel outages.

Question: Tell me about a time when fraud detection or prevention became a priority for your team. What strategies did you implement?

Answer: We encountered a fraud scenario where users exploited free onboarding bonuses by creating multiple wallets and accumulating bonuses into a single wallet. To combat this, we implemented a machine learning model that flagged suspicious transaction patterns, such as rapid wallet creation and transfers to a single wallet. The model was trained using both supervised and unsupervised learning on transaction data, and we integrated it with our backend system to block fraudulent activities in real-time.

We also placed constraints on the transaction amounts, imposing both minimum and maximum transaction limits to further mitigate fraud. Additionally, we created audit logs that traced transactions across multiple wallets, which allowed us to identify fraudulent patterns retrospectively. The model’s precision improved significantly after multiple iterations, and fraud instances decreased by over 70%.

5. Improving System Reliability:

Question: How have you worked towards increasing system reliability across different availability zones?

Answer: To increase reliability, we deployed our services across multiple availability zones (AZs) within the same AWS region, ensuring redundancy. In case of an AZ failure, traffic was automatically routed to healthy instances in other AZs. For database redundancy, we set up multi-AZ deployments with automatic failover in RDS, ensuring that if the primary node went down, the secondary node could take over seamlessly.

For further resilience, I implemented health checks at both the application and load balancer levels. Nginx was configured to monitor the health of each pod and remove unhealthy instances from the rotation. These strategies allowed us to meet our uptime SLAs and maintain a high level of fault tolerance.

Question: What measures did you put in place to prevent issues like duplicate transactions during scaling?

Answer: We encountered a problem where double refunds were processed when services were deployed in multiple clusters. To resolve this, we enforced a single-cluster policy for critical services to avoid duplication. For other cases, we implemented a mechanism that locked the transaction based on the public key of the sender or receiver until processing was complete. This serialization of transactions prevented deadlocks and double-spending issues.

6. Planning Future Improvements:

Question: Can you talk about a time when you identified a need for future technical improvements?

Answer: As traffic increased, we realized our existing event polling system for payment gateways like Simplex was becoming a bottleneck. I proposed moving from a polling-based system to a webhook-driven architecture, where payment gateways would notify us in real-time of transaction status changes (e.g., approved, declined). This shift significantly reduced latency and load on our servers, as we no longer had to constantly query the gateway for updates.

Additionally, I proposed introducing Kafka for message queuing between our transaction watcher and exchange services to handle high traffic spikes during peak hours. Kafka’s distributed nature made it an ideal fit for scaling as it decouples the services, ensuring

---

---

Generic Behavioral Question (STAR format)

1. Tell me about a time you faced a challenging technical problem. How did you solve it?
   Situation: At Rainberry, we were facing performance issues with Redis caching during peak traffic, causing system-wide latency issues. Task: My task was to identify the bottlenecks and optimize the caching mechanism. Action: I analyzed the Redis performance metrics using Prometheus and Graphite, identified key bottlenecks, and implemented cache sharding strategies to distribute the load across multiple instances. I also optimized cache invalidation policies. Result: These changes improved system performance by reducing response times by 30%, significantly increasing the system’s reliability during high traffic​(ADITYA KUMAR VERMA TESLA).

2. Describe a situation where you had to work under a tight deadline. How did you manage it?
   Situation: During the integration of Binance's Fiat On-Ramp for BitTorrent Speed, we had to complete the project within a strict deadline to meet a critical business milestone. Task: My responsibility was to integrate the system using FastAPI for token purchases, ensuring smooth microservices communication and real-time processing. Action: I broke down the project into smaller tasks, prioritized critical components, and collaborated with cross-functional teams to streamline dependencies. I also implemented automated testing to catch issues early and ensure the system met quality standards. Result: We successfully launched on time, increasing trading volume by up to $50K/month, which boosted overall revenue​(ADITYA KUMAR VERMA TESLA).

3. Give me an example of a time you worked in a team and faced a conflict. How did you handle it?
   Situation: While working on the decentralization of BitTorrent's wallet, there was a disagreement between two engineers on the choice of interfacing technology (Redis vs. Cassandra). Task: As the lead on the project, I needed to mediate the conflict and help the team decide on the best solution. Action: I facilitated a meeting where both engineers presented their solutions backed by performance data and scalability concerns. After evaluating both perspectives, we agreed on using Redis due to its lower latency and better fit for our use case. Result: This decision improved team collaboration and led to a more scalable and efficient wallet system, with Redis interfacing smoothly with our Aurora RDS backend​(ADITYA KUMAR VERMA TESLA).

4. How do you prioritize tasks when handling multiple projects at once?
   Situation: At Rainberry, I was simultaneously working on upgrading the data pipeline and implementing fraud detection in the ledger services. Task: My task was to prioritize these critical initiatives while ensuring progress on both fronts. Action: I prioritized tasks based on business impact and deadlines. For example, I tackled fraud detection first due to its immediate importance for security and then focused on optimizing the data pipeline. I also delegated less critical tasks to other team members and used automation where possible. Result: Both projects were completed on time. The upgraded pipeline now handles larger data volumes more efficiently, and the fraud detection system flagged suspicious transactions in real-time​(ADITYA KUMAR VERMA TESLA).

5. Tell me about a time when you made a mistake. How did you handle it?
   Situation: During a BitTorrent Speed deployment, I accidentally deployed a buggy version of a microservice that caused intermittent transaction failures. Task: My responsibility was to resolve the issue quickly and minimize the impact on users. Action: I immediately rolled back the deployment, identified the root cause using Grafana and Prometheus for debugging, and patched the bug. I also updated our deployment checklist to avoid similar issues in the future. Result: The rollback prevented further impact, and the patched service was deployed within hours, maintaining system uptime. The improved checklist has since reduced deployment errors by 20%​(ADITYA KUMAR VERMA TESLA).

6. Can you describe a time when you implemented a process improvement?
   Situation: The monitoring system for BitTorrent Speed services was reactive, with many issues only being identified after they caused significant downtime. Task: I needed to improve the monitoring system to make it more proactive and prevent downtime. Action: I implemented a robust monitoring and alerting system using Prometheus, Graphite, and Grafana. I set up custom alerts and dashboards for critical system metrics, allowing for early detection of performance degradation. Result: This led to a 40% reduction in system downtime as we were able to address issues proactively, leading to improved system reliability and faster issue resolution​(ADITYA KUMAR VERMA TESLA).

7. How do you handle feedback or criticism from a manager or peer?
   Situation: During a code review, a senior engineer suggested that my microservice code for BitTorrent’s token management system could be more modular to enhance scalability. Example common modules and protobufs can made as submodule and imported seprately to keep consistency accross microservice. Task: I had to refactor my code based on this feedback. Action: I accepted the feedback,refactored the code to create more modular and reusable components, and documented the changes for future use. I also took the opportunity to learn more about modular design patterns. Result: The refactored service was not only more scalable but also easier to maintain and extend. This change led to faster development cycles for future features​(ADITYA KUMAR VERMA TESLA).

8. Tell me about a time when you had to quickly learn a new technology for a project.
   Situation: I needed to integrate machine learning models (SVM, RIF) into the ledger services for real-time fraud detection, a domain where I had limited experience. Task: I had to quickly ramp up on machine learning techniques and their integration into backend services. Action: I studied relevant documentation, completed tutorials on scikit-learn, and worked closely with data scientists to understand the requirements. I also experimented with small datasets to validate my understanding before the final integration. Result: I successfully integrated the models, which enhanced fraud detection capabilities, reducing suspicious transactions by 15% in the first few weeks of deployment​(ADITYA KUMAR VERMA TESLA). .. Instaed give LLM example.