
The Riot OA lasted 120 minutes and included four consecutive questions, so the timing was quite tight overall. My question was about managing a garden. The tricky parts were mainly: first, handling the input and output correctly; second, dealing with all the corner cases, which took quite a bit of time; and third, the fact that the input coordinates were arranged from left to right and from top to bottom.
I am really grateful for the tool Linkjob.ai, and that's also why I'm sharing my entire interview experience here. Having an invisible AI assistant during the interview is indeed very convenient.
The first step was to represent the garden structure using an appropriate data structure. I started by reading the width and height, then initialized a 2D array where every position was set to 'B' by default. After that, I processed each plot type and updated the corresponding positions to 'F' or 'W' as needed. Finally, I printed the 2D array row by row as the output.
It’s important to pay attention to the coordinate handling: the x and y values in the problem start from 0, so you need to make sure the mapping between rows and columns is correct. For example, if the garden’s height is h, the row range is 0 to h–1, and each row has a length of w, with columns ranging from 0 to w–1. The output must be printed row by row, from top to bottom and left to right, concatenating the characters in each row. In Python, I used a list of lists initialized with 'B', then modified each position as required, and finally looped through the rows to print them as strings.
This one was more interesting. The goal was to find, for every blank plot, how many flowers were visible in the four directions, and then mark all positions with the highest count as '*'.
I started by building the garden map just like in Challenge I. Then, I iterated through every blank position (where the character was 'B'). For each blank position (x, y), I checked in all four directions — north, south, east, and west. For example, looking north means decreasing y until hitting a wall or boundary. During this process, I counted any 'F' I encountered and stopped when reaching a 'W' or the edge of the grid. The same logic applied for the other three directions: south (increasing y), east (increasing x), and west (decreasing x).
After summing the number of flowers visible in all directions for each blank plot, I recorded the total for each. Then I found the maximum total and marked all blank plots with that number as '*'. If there were no flowers in the garden at all, I marked all blank plots.

This challenge involved validating the correctness of garden operations and managing a stack for flower carts. The key rules were:
When performing a pick up operation, the target position must contain the correct flower type. Then, that position becomes 'B', and the flower is pushed onto the stack.
When performing a plant operation, the target position must be 'B', and the top flower on the stack must match the planting type. Then, the top flower is popped and placed at that position.
At the end of all operations, the stack must be empty.
So, the steps were: first, build the initial garden map as before. Then, maintain a stack (initially empty) and process each operation in sequence:
If it’s a “Pick up,” check that the position contains the correct flower and isn’t 'B'. If valid, change it to 'B' and push the flower type onto the stack. If not, mark it as invalid, output the current garden state, and print 'false'.
If it’s a “Plant,” check that the stack isn’t empty, the top of the stack matches the flower type, and the target position is 'B'. If valid, pop the stack and place the flower. If invalid, mark it as invalid and output 'false' with the current garden state.
After all operations, verify that the stack is empty. If it is, output 'true' and the final garden state; otherwise, output 'false'. (According to the problem statement, the given input plan should always end with an empty stack, so the main goal is to validate the intermediate operations.)
The key point here was handling the stack correctly: it’s a Last-In-First-Out structure. Each “Plant” can only use the flower currently on top of the stack. I processed the operations one by one, validating each step carefully. If any operation turned out invalid, I immediately stopped and output the current garden state.
This one dealt with the growth of ivy, which spreads in four directions each day until it reaches a flower, wall, or boundary. The task was to determine the first day when it touched a flower and output the garden state from the previous day.
First, I identified all the initial ivy positions and stored them in a queue or set, since ivy growth each day depends on the previous day’s ivy positions.
Then, I simulated the growth day by day. For every ivy position, I attempted to spread in all four directions. If an adjacent position contained an 'F', that meant the ivy reached a flower on that day, so the current day count was the answer. If the adjacent position was 'B', I marked it as 'I' and added it to the next day’s growth list. If it was 'W' or already 'I', I skipped it.
Since ivy growth happens simultaneously in all directions, I used a temporary queue or set to store the new ivy positions for each day. After processing all positions for the day, I updated the main ivy set and moved to the next day.
The day count started from 0, and with each iteration, I increased it by 1. During each expansion step, I checked whether any 'F' was reached. If yes, I recorded the current day and printed the garden state from the previous day. If not, I continued expanding.
I used a breadth-first search (BFS) approach to implement this — processing all current ivy positions layer by layer, generating new ones each day until a flower was found. This method ensured accurate day counting and easy tracking of the previous state.
I started my prep for the Riot HackerRank with a clear plan. Instead of cramming everything at once, I broke my study time into small, focused sessions. Each week, I set realistic goals for what I wanted to learn and practice.
Here’s how I kept myself on track:
I dedicated about an hour a day just for coding practice.
Every weekend, I went over my mistakes to see what patterns I could fix.
I kept a simple progress log in my notebook to track what I’d improved and what still needed work.
I didn’t just rely on one resource. I used a mix of online platforms and community sites to get ready for the riot hackerrank. HackerRank was my main tool for coding practice. The platform has tons of problems, and the community discussions helped me learn new tricks. I noticed my Python skills improved a lot after consistent practice there. I also checked Glassdoor and TeamBlind to read about other candidates’ experiences. These sites gave me insight into the types of questions Riot might ask.
Here’s a quick look at the resources I used:
Resource | Purpose | How It Helped |
|---|---|---|
HackerRank | Coding practice | Improved problem-solving and Python skills |
Glassdoor | Interview insights | Learned about question formats |
TeamBlind | Community advice | Got tips from past candidates |
LeetCode | Medium-level problems | Practiced structured problem-solving |
Balancing prep with school and other activities was definitely a challenge. To stay on track, I created a schedule and tried to stick to it as much as possible. I used a timer when practicing coding problems to get a feel for working under pressure. On especially busy days, I made sure to squeeze in at least 30 minutes of focused practice. Short, focused practice sessions ended up being much more productive than long, exhausting ones. I also set reminders on my phone so I wouldn’t skip any study time.
Here’s how I managed my time:
I scheduled my study sessions at roughly the same time every day to build a routine.
I used timers to mimic the real test environment and keep myself accountable.
If I ever missed a session, I adjusted my plan instead of skipping entirely, so I could stay on track without falling behind.
I finished my OA in the morning, and by the afternoon I already had an HR call scheduled. It was super fast.
Most of the test cases will pass as long as you handle the input and output according to the problem requirements. One thing to note is that for the third challenge, if there’s no planting action, you can return success immediately.
Another point to watch is keeping your comments consistent with your code. Also, since each challenge builds on the previous ones, writing good helper functions is very important.