DEV Community: AI Hater

My dog won't let me stay inside

AI Hater — Mon, 12 Oct 2026 06:46:13 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 1: Touch Grass

Usually when I look at a challenge, I don't react much. Most of them have exactly the vibe I expected. This one was different. I kept giggling the whole time I read it. They actually want us, the devs, to build something that gets people to touch grass.

It reminded me of every uni holiday, when my friends would say:

CompSci finally touches grass

What I Built

There are thousands of reasons to get out the door. The problem is, people just don't want to.

We make excuses, or our body simply decides it's done for the day. Doomscrolling and bedrotting start to sound like better choices.

A hike or a day of planting trees sounds fun in theory, but I can come up with a hundred excuses to put it off:

Going alone feels kind of sad

I'd need to buy gear first

We can just do it tomorrow

I'm working this weekend, I'll sort it out later

Boooooo!

People don't go outside because they don't feel like it, and nobody is there to drag them out. So instead of trying to motivate people all the time, why not go with an easier solution?

Give them someone who will force them to go outside.

And I mean it. They'll have to go outside, because they need to walk their dog.

Let me introduce you to GRASS DAWG.

Grass Dawg is a mobile app where you raise your own virtual pet. (I love dogs, so it's a dog.) Once you adopt your pup, you're responsible for its happiness.

Skip going outside for too many days and your dog gets miserable. Eventually, it runs away. Every day it's gone adds more distance to the search, and you have to walk all of it to bring your dog home.

When it comes to dogs, we don't play.

If dog walking sounds boring, don't worry. Grass Dawg keeps every walk interesting, whether you want to explore your city or just get your body moving:

Complete side quests to feed your dog
Visit a lookout because your dog has never seen one
Snap a photo after each activity

At the end of the walk, you get a recap of your day, just like the stories you'd post anyway, so you can see how good your day actually was.

About screen time

I'll be honest: Grass Dawg can't get your screen time to zero. The whole app is built around you and your dog, and that relationship lives on your phone.

What it does is keep the screen part short. During a side quest, your dog sulks with its back turned and won't come out until the quest is done. And let's be real: given the choice between staring at a dog that refuses to look at me, or looking at the street and the view, I'm putting my phone away until I find something worth photographing.

I took Grass Dawg out for a proper test run, and the screen time numbers told the whole story.

At 9am, I had barely rolled out of bed and my phone already showed 50 minutes of screen time. Half of that was TikTok (I didn't mean that I swear...). Honestly, seeing it laid out like that was a bit depressing.

Then I headed out with Pickle. By 1pm, my total was only 1 hour and 3 minutes. That means across four hours outside, I spent just 13 minutes on my screen, and most of those were the 10 quick unlocks to check my next quest.

Who it's for

Everyone!

People who know they should get out more. People who have a free day and no idea what to do with it. Or anyone who just wants a pet and a little sense of progress in their life.

And here's my favourite part of building it: The app actually kept me outside, because I had to test whether it worked.

Honestly, if it can get a developer in the middle of a build to touch grass, it can get anyone.

So, what do you think?

Demo

This app is designed to be a mobile app so open the URL with your phone to have the best experience.

grass-dawg.onrender.com

Code

Have a look at my code in here.

hong-nhung-nguyen / grass-dawg

Fetch Quest

A virtual pet dog that refuses to come out until you go outside. All AI runs on your phone using open-weight models, so it works offline after the first load and your photos never leave the device.

Entry for the DEV Hacktoberfest Open-Source AI Challenge, Week 1: Touch Grass.

What works so far (step 1 and 2)

Home screen with the pet sulking, facing the wall
Camera snapshot checked by CLIP (Transformers.js) to decide indoor vs outdoor
Pet wakes up and celebrates when you're outside
System check panel: WebGPU support, on-device language model download (Gemma 3 1B by default, with Qwen2.5 alternatives), and a test line from the pet
Pet stats saved between sessions

Run it

npm install
npm run dev

The dev server prints a Network URL like https://192.168.x.x:5173. Open that on your phone (same Wi-Fi). It uses a self-signed certificate, so accept the browser warning…

View on GitHub

How I built it

The idea was simple: make a walk around the neighbourhood feel like a little adventure, with a dog that actually cares whether you go outside.

The brain behind Pickle is Gemma 3 1B, an open-weight model that runs entirely in the browser through WebLLM. The first launch downloads the model, and after that everything happens on your phone. When Pickle comes up with a quest for you, it’s generated right there on your device, with no cloud AI call involved. I loved that part, because it means your walks and photos stay with you.

Quests only matter if they happen in the real world, so the rest of the app is about getting you out the door. When you snap a photo for a quest, CLIP ViT-B/32 running through Transformers.js checks whether you actually found what Pickle asked for. No sneaky photos of your bedroom wall. To give Pickle somewhere worth sending you, OpenStreetMap and SerpApi pull in interesting spots nearby, like parks, cafés and lookouts you might never have noticed.

The whole thing is built with React and Vite and ties together on-device AI, your camera and a map of your city. Underneath all the tech, it’s really just one very good boy giving you a reason to get some fresh air.

Why Does Open Innovation Matter?

Grass Dawg only works the way it does because the AI runs on the phone itself. The dog's eyes are CLIP ViT-B/32 running through Transformers.js, and its voice and quest ideas come from Gemma 3 1B running through WebLLM. Both download once, then run entirely in the browser. That one decision shaped everything else about the app.

It keeps working where people actually walk. Parks, bush tracks, tunnels and the far end of a beach are exactly where signal drops out. With a closed API, every photo check and every dog reaction would be a network request, and the dog would freeze the moment the walk got interesting. Because the models live on the device, tap-to-look, quest photo matching and the dog's lines all keep working with no connection.

Your walks stay yours. A walking app that uses the camera builds a detailed picture of someone's life: where they live, when they leave the house, which routes they take, and photos of the streets around them. Sending that to a third-party server for every check was something I didn't want to ask anyone to accept. In Grass Dawg, quest photos are matched on the device, the route and recap are stored locally, and nothing is shared unless the user chooses to share their walk recap.

It costs nothing per walk. A single active walk can involve dozens of model calls: checking whether you're outside, reacting to what you show the dog, verifying quest photos and writing quest suggestions. With a paid API, the more someone walks, the more the app costs to run, which is the opposite of what an app about getting outside should reward. Running locally, the hundredth walk costs the same as the first: nothing.

I could control and change the model. Owning the model meant I could constrain it tightly. Quests are limited to categories CLIP can actually verify, so the language model can't invent a mission the app can't check. It also meant I could swap models freely during development. I started with Qwen2.5 and moved to Gemma 3 1B when it suited the quest writing better, without changing providers, keys or pricing plans.

The trade-offs, honestly. Running on-device means a large first download, so the app shows a one-time setup screen and works best on Wi-Fi the first time. Phone browser support for WebGPU also varies. And not everything is local: finding Explore destinations uses OpenStreetMap and SerpApi, which need a connection, so the app pre-downloads destination data for the user's city while they're online. The core loop of going outside, showing the dog the world and completing quests runs entirely on open models on the phone.

On my own test walk, [4 hours outside, 12 minutes of screen time]. That's the point of the whole build: the open models do their work quietly in the pocket, so the walk can be the main event.

My Agent Session

I found out about DevRelay too late to record my agent session properly. Instead, I worked with my agent to put together a structured summary of the whole development process: every phase, from understanding the challenge and shaping the idea to the final build, along with the key decisions made along the way.

It isn't a verbatim transcript of my prompts and messages, but it should give you a clear picture of how Grass Dawg came together.

{
  "title": "Grass Dawg development session",
  "format": "session-summary",
  "coverage": "From the first request to explain the Touch Grass challenge, through ideation, design, the first code and the fixed dog interactions, then from the later Tap-to-look and outdoor camera work through the project discussion immediately before the first request to push the project to GitHub.",
  "transcript_note": "This is a structured summary, not a verbatim transcript. It combines two parts of development: the early ideation and setup conversation, and the later build session. The full turn-by-turn transcript was not available for export, so missing replies have not been reconstructed.",
  "project": "Grass Dawg, a mobile-first dog companion app that encourages outdoor walks with quests.",
  "timeline": [
    {
      "phase": "Understanding the challenge",
      "items": [
        "Reviewed the DEV Hacktoberfest Open-Source AI Challenge, Week 1: Touch Grass, including the requirement that open-source AI must be what makes the project work.",
        "Identified the key judging hint: the screen should be the shortest part of the experience, with bonus points for testing the build outside.",
        "Clarified the difference between open AI (open-weight models and open-source frameworks that can be downloaded and run locally) and closed AI (models only reachable through a provider's API).",
        "Listed the open advantages to highlight in the post: offline use, on-device privacy, zero cost per use, and the freedom to swap, constrain or fine-tune models."
      ]
    },
    {
      "phase": "Choosing the idea",
      "items": [
        "Started from the user's idea of a virtual pet that must be walked outside.",
        "Identified the main weakness: a step-counter pet does not need AI, so the open model had to become essential to the experience.",
        "Compared alternatives (a Side Quest app and an offline coastal explorer) and ruled out edible plant identification for safety reasons.",
        "The user proposed combining the pet with side quests: the pet gets people outside, and quests reduce screen time.",
        "Replaced the planned coin shop with rewards tied to what was found, since browsing a shop would add screen time."
      ]
    },
    {
      "phase": "Refining the concept",
      "items": [
        "Defined the core mechanic: the pet sulks facing the wall until the user goes outside, then comes alive.",
        "The pet sets a side quest and hides until it is completed, turning reduced screen time into part of the game rather than a rule.",
        "Target users: people exploring their city on a free day.",
        "Replaced continuous real-time camera analysis with tap-to-look snapshots to save battery and keep screen time short.",
        "Planned outdoor detection with a CLIP indoor/outdoor check, with GPS distance from home as an optional second signal.",
        "Added a growing pet diary with daily entries written by the local language model, plus pet stats."
      ]
    },
    {
      "phase": "Design document",
      "items": [
        "Wrote a design document covering the overview, core loop diagram, game mechanics, interaction table, architecture diagram, why open innovation matters, scope and risks, a 7-day build plan, a field test plan, a coding agent starter prompt and a submission checklist.",
        "Planned the field test headline metric: total time outside compared with total screen-on time."
      ]
    },
    {
      "phase": "UI direction and naming",
      "items": [
        "Wrote a Stitch AI prompt for six screens: breed selection, indoor sulking home, AR camera view, hidden side quest screen, quest complete and diary.",
        "Kept the art style original rather than copying an existing game's characters.",
        "Noted that Stitch produces static screens, so smooth dog movement must come from the implementation.",
        "Explored app names, using Fetch Quest as the working name during early development."
      ]
    },
    {
      "phase": "Tech stack and models",
      "items": [
        "Chose a browser-based PWA (React and Vite) so judges can open a link and all AI runs on the phone after a one-time download.",
        "Selected CLIP ViT-B/32 through Transformers.js for zero-shot image matching, and a small open-weight language model through WebLLM (initially Qwen2.5 1.5B with a 0.5B fallback) for quests, reactions and diary entries.",
        "Discussed the user's request to use MongoDB: recommended a local-first design (RxDB on top of IndexedDB) with optional MongoDB Atlas sync, so photos and locations never leave the device.",
        "Flagged the roughly 1 GB first download and WebGPU support on phones as the main risks."
      ]
    },
    {
      "phase": "Dog movement and 3D assets",
      "items": [
        "Explained that smooth dog movement comes from animation clips built into a rigged 3D model, played and cross-faded in three.js through React Three Fiber.",
        "Compared sources: the free CC0 Quaternius Animal Pack Vol.2 dog, the Quaternius Farm Animal Pack, a paid 15-breed animated dog pack, and Sketchfab models with varying licenses.",
        "Chose the free Quaternius dog for its CC0 license and small file size, with breed choice handled by recolouring one rigged model.",
        "Noted that Mixamo only animates humanoid characters and that retargeting four-legged animations by hand is too slow for a one-week build."
      ]
    },
    {
      "phase": "First code: outdoor wake-up",
      "items": [
        "Built the first version: a sulking home screen with an animated placeholder SVG dog, stat bars, and a camera snapshot checked by CLIP for indoor versus outdoor.",
        "Added a System check panel to confirm WebGPU support, download the language model and time a test reply on the phone.",
        "Ran WebLLM in a web worker so animations stay smooth, and served the dev server over HTTPS on the local network so phones allow camera access.",
        "Walked through running the project locally and accepting the self-signed certificate warning."
      ]
    },
    {
      "phase": "Fixed dog interactions",
      "items": [
        "Defined a fixed interaction table: water bowl, fountain or pond, grass, bench, tree, dog, bird, flowers, street art, cafe, statue and bridge, each with an action, stat effect and fallback lines.",
        "Added background labels (roads, cars, footpaths, walls, sky) so CLIP does not force ordinary scenery into an object.",
        "Added a confidence threshold, half rewards for repeated objects, and a limit of three looks per round so the camera does not become the main activity.",
        "Added interactions for a person, chair, table and jumpable shapes (low walls, steps, rocks, logs, crates), supporting several wordings per object.",
        "Mapped each action to an animation clip name, to be updated once the real 3D dog clips were known."
      ]
    },
    {
      "phase": "Platform decision",
      "items": [
        "Discussed building a native mobile app: native would allow real AR ground tracking, better notifications and faster on-device inference.",
        "Decided to stay with the PWA for the submission, because judges can open a link instantly and a native rewrite would not fit the deadline.",
        "Noted Capacitor as a way to wrap the web app later, and a native React Native version with real AR as a post-challenge next step."
      ]
    },
    {
      "phase": "Outdoor camera and dog behavior",
      "items": [
        "Implemented Tap-to-look and indoor/outdoor mode behavior.",
        "For outdoor mode, keep the dog in the live camera view and let it perform actions for a short interval.",
        "Added dog movement concepts such as running, drinking, sitting, and sunbathing."
      ]
    },
    {
      "phase": "Walk modes and quests",
      "items": [
        "Added relaxed and active walk concepts, with side quests available during active walks and occasional suggestions during relaxed walks.",
        "Created daily item/activity quests and city-bounded Explore quests.",
        "Explore destinations should favor specific, relaxing outdoor places and hikes, with commercial venues minimized.",
        "Quest recommendations should refresh and completed quests should be recorded in history."
      ]
    },
    {
      "phase": "Camera, proof, and walk recap",
      "items": [
        "Quest completion uses a camera photo rather than an uploaded image, with photo matching for validation.",
        "Walk recap tracks elapsed time and route shape, includes photos, and supports sharing/downloading.",
        "Active walk recaps include quest photos and quest totals; the final cover photo is separate from the quest-photo collage.",
        "Route tracking should represent meaningful position changes rather than stationary phone movement."
      ]
    },
    {
      "phase": "Dog profile and wellbeing",
      "items": [
        "Added a dog profile with editable name, happiness, weight, and an outside/home calendar.",
        "Initial weight is 2 kg; the user proposed daily weight changes based on happiness and missed outdoor days, including a find-the-dog mechanic if weight reaches the minimum.",
        "Completed quests automatically mark the day as an outside day.",
        "Removed energy after discussing what happens when it reaches zero; retained happiness."
      ]
    },
    {
      "phase": "Offline AI and app behavior",
      "items": [
        "Discussed running open-weight AI locally in the browser after an initial model download.",
        "Gemma 3 1B is used through WebLLM for local quest assistance; CLIP through Transformers.js is used for image matching.",
        "Discussed offline capability and pre-downloading city destination data, while noting that some integrations need network access."
      ]
    },
    {
      "phase": "Camera and development settings",
      "items": [
        "Added camera switching and zoom controls, including pinch zoom capped at 5x.",
        "Worked through camera access and startup responsiveness issues.",
        "Adjusted indoor/outdoor detection and relaxed-walk quest reminder timing during development."
      ]
    },
    {
      "phase": "Hosting discussion",
      "items": [
        "Discussed deploying the web app on Render and how to open it on a phone.",
        "Troubleshot local network connection and certificate issues.",
        "Discussed that deployment does not automatically preserve browser-local data."
      ]
    }
  ],
  "technologiesMentioned": [
    "React",
    "Vite",
    "Tailwind CSS",
    "WebLLM",
    "Qwen2.5 1.5B / 0.5B",
    "Gemma 3 1B",
    "Transformers.js",
    "CLIP ViT-B/32",
    "three.js / React Three Fiber",
    "Quaternius Animal Pack Vol.2 (CC0)",
    "RxDB",
    "MongoDB Atlas",
    "Web Speech API",
    "Stitch AI",
    "OpenStreetMap",
    "SerpApi",
    "Render"
  ]
}

Prize Categories

Gemma - Uses the open-weight Gemma 3 1B model with WebLLM for on-device quest generation.
Render - Deployed on Render, with a static web app and a places API service.
SerpApi - Uses Google Local results to help rank named places for Explore quests.

I think me and LeetCode are getting along now

AI Hater — Thu, 08 Oct 2026 10:04:23 +0000

Yeah I'm still doing LeetCode, and this post will be updated with all new tricks that I know.

What's up everybody

Have you done any LeetCode this week? If not, I'm hoping that by the end of this post you'll want to jump straight into a problem.

LeetCode is infamous. Pretty much everyone who starts learning DSA is scared of it, even people who've never touched a data structure or algorithm in their life.

Same for me.

I used to have a mentor who was guiding me on how to realistically land a dev job. Before he could even get a word in, I warned him three times:

I have never done any LeetCode or DSA before.

Those days were BADDDD. But slowly things changed, from BADDD to baddd, to bad, to "not great," to "fine", to "oh wait, I think I actually get something now."

Let me be straightforward:

We only start to like something once we know how it works.

What do I mean by that?

I mean you'll never enjoy LeetCode if you keep solving problems blindly. You open a question, try to figure out what it's asking, then spend minutes (or hours) convincing yourself that if you just keep staring at the screen, the right approach will eventually pop into your head.

Nope. That's not how it works.

LeetCode isn't something you can brute-force with willpower. The only way through is taking the time to actually understand it.

Okay, enough yapping. Welcome to Finding the Beauty of LeetCode 101.

1. LeetCode problems have patterns

I know you already know this, but I'm saying it again because it's the most obvious thing and people still ignore it.

Once you've solved enough problems, you start noticing:

Tons of them are worded differently but share the same pattern, the same data structure, the same algorithm, and almost the same solution.

Turns out LeetCode isn't that "creative" after all.

So how many problems is "enough" before you start recognising patterns?

It depends on you and how consistent you are, but my recommendation is to follow along with videos where people solve the most iconic, interview-focused questions.

Somewhere around halfway through (these videos are usually hours long), you'll notice something clicking. That's your intuition starting to kick in.

2. The Big-O Pattern cheat sheet

This is honestly one of the most impressive things I've ever come across.

Huge shout out to Bitflip, who made a cheat sheet that helps you narrow down the pattern in under ONE minute, just by looking at the input size constraint.

Just figuring out the minimum time complexity your solution needs already does you a massive favour, because it rules out a bunch of patterns straight away.

This is my FAVOURITE trick ngl.

3. Normalise admitting you can't solve it

That was me a few months ago, sitting there for hours because I was sure my naive brain would crack it eventually.

Back then, solving four questions in a day felt like a huge win, when realistically, four questions should take two hours max.

The problem is we think we'll figure it out, and then the solution turns out to use something we've never even heard of.

LeetCode is ruthless about failing your solution for all sorts of reasons: time complexity not good enough, hidden edge cases you never thought of, or your code runs but it's not the approach the problem is looking for.

Knowing all of that just takes experience.

Pro tip: Give it a real go for the first 15 minutes. If you're still stuck, look at hints for another 10 to 15 minutes. After that, read the full solution.

I did this while rushing to prep for an interview, and it worked really well.

Just because something kinda makes sense in your head doesn't mean it's actually correct.

4. Consistency (and a little bit of fun)

Super cliché, I know, but sadly it works every single time.

Where I used to live, TikTok streaks were so common they were basically a must-have in most relationships.

If you haven't seen it, it's a little fire icon that counts how many days in a row two people have messaged each other. Both of you have to interact within 24 hours, otherwise it resets to zero.

That's honestly how a lot of friendships die.

LeetCode has the same streak thing, and it might be one of their smartest moves.

Yes, I definitely do LeetCode everyday if you promise me this after a year

Sometimes people solve problems not because they want to practise, but because they don't want to lose their streak, and that ends up making them practise anyway. Wow.

So if you can stay consistent for a few days, you'll want to keep that streak going. You'll even go to bed feeling like your day isn't complete if you haven't solved anything. And voilà, LeetCode just got another person hooked. Honestly though, it's a win-win after all.

5. Brute force first, optimise later

A lot of people chase the optimal Big-O straight away and forget the most important thing: getting a solution that actually works, even if it's brute force.

Never forget the #1 rule of developers:

If it runs, don't touch it.

Yeah, I know, DSA cares about more than that. But a win is a win, and starting with something that works makes the whole problem way less scary.

Pro tip: Go with whatever solution comes to mind first. If it's clearly brute force and you know there's a better way, write the brute force anyway, then work on improving it. Not sure if it can be optimised? Check the input constraints against the Big-O cheat sheet from earlier, or ask your AI agent whether there's a better time complexity. If the answer is yes, keep going.

Before you can optimise anything, you've got to make it work first.

6. Keep an error log

You'd be surprised how much longer you remember things when you write them down.

Maybe not forever, but definitely longer than just assuming you'll remember.

I keep an error log for every question I solve:

What pattern was it?
How long did it take me before I gave up?
Where did I get stuck?
What did I assume?
What was wrong, and what was right?

When I look back at it, the memory of struggling through each problem comes flooding back. I might not remember the exact solution, but I remember my process and which approach made more sense. That's a great starting point.

7. Re-solve old problems

I don't think this one needs much explaining, so I'll keep it short and leave the rest to your own self-reflection.

Ask yourself this:

Wouldn't it feel annoying and unsettling to keep grinding new questions while secretly wondering if you could still solve the old ones?

It would for me. So I re-solve them.

Honestly, if you can't re-solve a question, it doesn't count.

8. Read the discussion

I bet a lot of people care so much about getting the green "Accepted" that they skip the process completely. But the process matters way more than you'd think.

Reading the discussion shows you how other people actually came up with their approaches:

What sparked the idea in their head?
Which detail put them on the right track?
Any personal tips or tricks?

A lot of these people will never be YouTubers, but they've got the kind of experience and tips you'd happily click on a video to watch.

Plus, people complain in the discussion too. Sometimes I go there just for a bit of emotional support...

9. Never leave a question half-understood

Say you couldn't solve a problem, so you check the solution. You copy it into your notes, and it kinda makes sense. But you don't really get why recursion is called here and not there, or why it's even needed at all.

Don't. Leave. It.

Stick with it. Dry run it until you understand it inside out.

Otherwise, next time you come back, not only will you have forgotten how to solve it, you'll also have no clue why the solution was written that way.

Pro tip: It's fine to forget the exact code, but never forget the core logic behind it. Something you've already studied should never feel like a blank sheet of paper again.

This one is important (and dangerous if you ignore it), so let me say it one more time:

Never leave a question half-understood!

Anyways...

This is just my journey. Yours might look different, but suggestions cost nothing, so if any of this sounds like it could work for you, open LeetCode right now and give it a shot.

Don't feel discouraged if you don't pass on your first few tries.

To be fair, it's nearly impossible to master something after a handful of attempts when other people have been grinding it for months or even years.

LeetCode is there to help you, not something to fear and avoid at all costs. If you're a developer, questions like these are going to show up sooner or later anyway.

So why wait until you're rushing for an interview? Start today.

Pick a LeetCode interview questions video, follow along, and slowly turn it into a habit. Trust me, one day you'll look back and realise you and LeetCode are getting along too.

You won't regret it!

TikTok Backend Intern Interview

AI Hater — Tue, 06 Oct 2026 05:59:30 +0000

Hey guys, how's your internship season going?

Mine? Not too promising. But I still have something to tell.

This year, I got my first internship interview ever, and honestly, I didn't expect it to come from a company as big as TikTok.

I sent out quite a few applications and only got two replies. One of them I don't really count, but the other one was TikTok.

I didn't get the offer in the end, but I thought I'd share my experience anyway. Hopefully, it can help someone who's currently going through the TikTok interview process - or at least someone who's interested in applying.

I had two interviews with TikTok, both for a Backend Developer Intern role. One was for the LIVE team, and the other was with Data Trust & Safety, although both interviews had a strong focus on LIVE.

Some Q&As

1. Did LeetCode actually help?

Yes. Absolutely. Totally. 100%.

From my experience, TikTok's coding questions are quite similar to the usual LeetCode format. This is slightly different from some other companies, where the coding question might be modified to fit the team's specific work, which can sometimes make the problem harder to recognise, especially for the young candidates.

TikTok's coding questions can range from medium-hard to hard. However, I only got one coding question across my two interviews, and it was around medium difficulty.

I actually got the general approach pretty quickly after reading the problem. However, the problem itself wasn't clear enough that I only realized when I missed an edge case. I had to clarify it with the interviewer, and unfortunately, I didn't have enough time left to fix everything.

My personal tip: If your interview is only a week away, use your AI agent to generate coding questions based on the job description.

Not just for TikTok, but for pretty much any company.

Companies often choose problems that are somewhat related to the type of work their team is doing. So instead of randomly grinding hundreds of LeetCode questions, you can use the JD to narrow down what you should practise.

I tried this myself, and it actually worked pretty well.

Of course, I can't guarantee that you'll get the exact same type of question. But if you only have one week to prepare, I think it's a pretty useful shortcut.

2. What was the interview structure?

The email said it would be a technical interview with an opportunity to explain your work.

So naturally, I thought: "Okay, probably just some coding."

NOPE!!!

TikTok is really the trendsetter of

"Don't let anyone guess your next move."

The first interview

My first interview covered:

Introduction
Project deep dive
CS fundamentals
Behavioural questions
System design
Coding

And all of that happened within 55 minutes, with the last five minutes reserved for my questions.

Now you can probably understand why I didn't have enough time to fix my last coding edge case 💀

Everything moved incredibly fast.

The positive side? I barely had time to feel nervous.

The second interview

The second interview was quite different.

It was only around 35 minutes, and there was:

Introduction
Project deep dive
CS fundamentals
A little system design connected to my project

There was no coding question.

Honestly, I enjoyed the second interview much more.

It felt more like a proper technical conversation where the interviewer was trying to understand how deeply I actually understood what I had built, rather than checking whether I could answer a bunch of different questions in a short amount of time.

And yes, the project discussion was VERY deep.

3. Does TikTok prioritise Chinese speakers?

Honestly, I have no idea.

What I do know is that after reading hundreds of TikTok interview reviews, I noticed that the interviewers were very often Chinese.

In my second interview, one of the first questions I was asked when the interviewer joined the call was:

“Mandarin or English?”

That honestly confused me a little.

I don't speak Chinese, but the interviewer's English was very good, and we still had a really good technical discussion. Personally, I don't think not speaking Chinese had anything to do with my rejection.

I've also seen people mention having communication difficulties with some TikTok interviewers. But realistically, that's not something we can control.

Just focus on what you can control: your technical knowledge, your projects, your communication, and your preparation.

My personal thoughts and experience with TikTok's Backend Interview

1. Practise LeetCode — seriously.

This is basically non-negotiable.

But don't just practise randomly. Practise with a timer.

For my first interview, I had roughly 15 minutes from reading the problem, understanding it, discussing the approach, building test cases, and submitting the solution.

That's not a lot of time.

So when you practise, don't just ask:

"Can I solve this problem?"

Also ask:

"Can I solve and explain this problem under interview pressure?"

There's a big difference.

Also, if you interview for a developer role, I would recommend you to discuss the performance scaling and system design with your agent after each question. We all know interviewers love to make things difficult for the candidates. And besides, you will learn so many, trust me.

And if you don't have much time before the interview, I'd rather practise 10 relevant problems properly than blindly grind 100 random ones.

2. Know your projects inside out

This one is probably even more important than I expected.

If you put a project on your resume, be prepared to defend every single thing you wrote about it.

And I don't just mean:

"What technologies did you use?"

You should also be ready for questions like:

Why did you choose this architecture?
What happens when multiple requests arrive at the same time?
How does your system handle concurrency?
What happens when the traffic increases?
Where could the bottleneck be?
How would you scale it?
What happens if a service fails?
How much load can your system handle?
What would you change if you had to deploy this in production?

Basically, if you built it, understand why it works—not just how to make it work.

3. Don't underestimate your university subjects

I definitely did.

The CS fundamentals questions actually came from things I had studied at university.

The funny part?

I remember being asked something that I had literally studied two or three months before the interview.

And somehow, when the interviewer asked me about it, my brain decided:

"Sorry, this information is no longer available."

So yeah.

Don't completely ignore your uni subjects just because they don't feel immediately useful.

Data structures, algorithms, operating systems, databases, networking, AI, etc. can absolutely come back during an interview.

4. There are (at least) two types of interviewers

This is obviously just my personal observation, but I felt like I experienced two very different interviewer styles.

Type 1: The prepared interviewer

They have a list of questions prepared beforehand and work through them.

If you get this type of interviewer, you might be slightly luckier because they tend to stick to their questions and don't necessarily go too far into follow-ups.

Type 2: The senior engineer

This one is scary.

They don't even need to look at the questions.

You introduce yourself.

You talk about your project.

And then they start asking questions based on literally everything you just said.

Your own words then become your death certificate.

So my advice is:

Don't lie. Don't exaggerate.

If you say you "designed the architecture", be prepared to explain the architecture.

If you say you "implemented a scalable backend", be prepared to explain why it's scalable.

If you say you "handled concurrency", be prepared to explain exactly how.

At the same time, don't undersell yourself either.

You should be confident about what you genuinely know. Yes, your interviewers are probably very good at what they do, and that can be intimidating. But confidence goes both ways, human instinct will let the interviewer naturally perceive you as someone who knows what they're talking about.

5. Write down your interview reflections

This is something I wish I'd started doing earlier.

After an interview, write down:

What questions were asked?
What did I answer well?
Where did I get stuck?
What did I forget?
What would I answer differently next time?
What technical topics do I need to review?

You'd be surprised how much you can improve just by recalling the interview while it's still fresh.

And if you're not particularly good at self-reflection or don't know how to organise it, just write down your raw thoughts and ask your AI agent to turn them into a reflection for a better upcoming interview.

I did this after my first interview.

Looking back, my first interview was honestly kind of a mess.

But my second one was way more organised, partly because I had already reflected on what went wrong the first time.

6. Read the interview reviews

Have a look at Glassdoor before your interview.

There are thousands of interview reviews there, and while you obviously shouldn't assume you'll get exactly the same questions, they can give you a pretty good idea of what the process looks like.

What I shared here is just one person's experience.

Your interview could be completely different.

7. Do mock interviews and practice your speaking

Yeah, again - if you don't have anyone to practise with, you can just do it with your AI agent.

Prompt it carefully, make it behave like a real interviewer, and be strict with the timing, especially for the coding section. Don't give yourself 30 minutes to solve a problem when you know you'll only get 15 minutes in the actual interview.

If you want to see the prompt I used (which was actually pretty useful), comment below and I'll send it to you.

Now, about speaking skills.

I would strongly recommend preparing stories around your projects so that whenever a project-related question comes up, you already know what you want to talk about.

The project discussion shouldn't be something completely unexpected. You know your own projects, you know what's on your resume, and you should be prepared to explain them. If you can't talk about your own work smoothly, there's a pretty high chance the interviewer will think you're not ready for the interview.

And... that's not good, you know that right? :(

Also, don't just read, write, and convince yourself that you know everything.

Speak. Out. Loud.

You'll quickly realise that what you think you understand in your head isn't always what comes out when you actually have to explain it.

You want to be able to answer questions clearly, simply, and as concisely as possible. And honestly, that takes practice.

One more thing: you can't really fake what you don't know when you're speaking.

Once you start explaining something out loud, the gaps in your knowledge become much more obvious. You'll notice where you hesitate, where your explanation gets messy, and where you actually don't understand something as well as you thought you did.

And that's exactly why speaking practice is so useful.

You find the weaknesses before the interviewer does.

Final thoughts

Honestly, I wasn't particularly surprised or sad when I got rejected.

I knew I hadn't prepared enough.

And that's probably the biggest thing I took away from this experience.

Getting rejected after my first-ever internship interview with a company like TikTok isn't really a bad result in my eyes. I got to experience what a real technical interview feels like, I know what I need to improve, and my second interview was already much better than my first.

Also, TikTok seems to be opening quite a lot of internship positions right now, so give it a shot.

You might think you're not ready.

Apply anyway.

You never know.

Anyway, that's it from me.

Good luck y'all!