Prepare for a TikTok software engineer interview by producing three things you can defend: working code, a design tied to explicit requirements and project stories with clear personal contributions. The right balance depends on your team and experience. A graduate assessment, a backend design discussion and a mobile performance interview need different practice.

Use TikTok Software Engineer questions on PracHub to choose drills, then check the language, tools and stages in your own invitation. Company tags are practice context, not a prediction of your interview.

The coding and feed exercises below are original teaching examples. They are not leaked questions, TikTok's internal architecture or a private hiring rubric.

05What is known about the TikTok interview process?

TikTok's How We Hire page describes interviews with recruiters and potential colleagues by phone, video or onsite. Its interview tips say to expect several conversations and prepare relevant experience and knowledge of the role. They do not establish one engineering loop for every applicant.

The Early Careers FAQ describes resume screening, an assessment when applicable and hiring-team interviews. It says assessment use depends on location and that passing an assessment does not guarantee a particular time to the next interview. Avoid turning a gap between messages into a definite pass or rejection.

This is a preparation map. A supposed universal seven-stage sequence, fixed question count or guaranteed plain editor without a compiler needs evidence from your recruiter. Keep practicing between stages without assuming every team unlocks rounds in the same way.

06Choose a route for your level and engineering team

Early-career candidates should prioritize executable coding, fundamentals and a project they understand. Experienced candidates should add architecture decisions, failure handling and evidence of ownership across a wider scope. These are preparation choices, not published leveling thresholds.

DSA drills should cover arrays, hashing, trees, graphs, heaps, intervals and dynamic programming. Select topics from your gaps rather than attempting every company-tagged problem. For a domain role, reserve time for the actual stack and job responsibilities.

07Complete coding mock: longest segment with at most k creators

Given a sequence of hashable creator IDs, return the half-open index pair [start, end) for its longest contiguous segment containing at most k distinct IDs. Prefer the earliest start when lengths tie. An empty result is (0, 0). Require a nonnegative integer k; a boolean is not accepted as an integer for this contract.

This exercises sliding-window reasoning, not recommendation quality. A production feed should not use “fewest distinct creators” as a diversity objective.

For ['a', 'b', 'a', 'c', 'c', 'c'] and k = 2, the answer is (2, 6), covering ['a', 'c', 'c', 'c']. A straightforward baseline enumerates segments and counts distinct IDs. It is useful as a small-input oracle but repeats work unnecessarily.

Maintain counts for the current window. Add the next ID; while there are too many distinct IDs, remove occurrences from the left. Delete a count when it reaches zero. The window is valid again before comparing its length with the best answer.

def longest_creator_window(creators, k):
    if type(k) is not int or k < 0:
        raise ValueError('k must be a nonnegative integer')
    if k == 0:
        return (0, 0)
    counts, left, best = {}, 0, (0, 0)
    for right, creator in enumerate(creators):
        counts[creator] = counts.get(creator, 0) + 1
        while len(counts) > k:
            old = creators[left]
            counts[old] -= 1
            if counts[old] == 0:
                del counts[old]
            left += 1
        end = right + 1
        if end - left > best[1] - best[0]:
            best = (left, end)
    return best

Each position is added once and removed at most once. Under ordinary constant-time hashing assumptions, work is O(n), with O(min(n, k+1)) additional count storage. The input itself is already supplied; this bound excludes storing it. Expensive hash or equality operations change the cost.

The strict > comparison preserves the first longest window. Because the left boundary only moves forward, a later equal-length window cannot have an earlier start. Leaving zero-count IDs in the map would falsely inflate the distinct count and can shrink a valid window.

The displayed implementation passed those five fixtures, six invalid-k cases and 13,120 exhaustive comparisons: all arrays of length zero through seven over three IDs, with k from zero through three, checked against independent segment enumeration.

Follow-up: the sequence becomes an iterator

The code indexes creators[left], so it cannot accept a one-pass iterator unchanged. Keep the active IDs in a deque and pop from its front when shrinking. Track the left index separately and still return indices. Counts use O(k) distinct-ID storage, but the deque can hold O(n) occurrences when the longest window spans the stream. Do not claim O(k) total memory for that version.

If only the answer length and indices are required, investigate tracking each distinct ID's most recent position instead. Evict the least recent ID when there are more than k. Maintaining that minimum efficiently needs another deliberate data-structure choice. Explain and test it rather than promising a constant-memory streaming solution.

08Complete feed-design mock: delivery around a ranking boundary

Design a fictional short-video discovery feed. TikTok's public 2020 product explanation discusses interaction signals, varied recommendations and eligibility. It provides useful product context, not a specification of today's storage, services or interview expectations.

For this mock, choose ten million daily active users, twenty page requests per user per day, twenty items per page, a 200 ms server-response target and a 30-second target for newly eligible content to enter retrieval indexes. All figures are teaching assumptions. The response target excludes downloading and playing the video bytes.

Two hundred million page requests per day average about 2,314.81 requests/s. A tenfold peak is about 23,148.15 requests/s; provisionally design around 25,000. Retrieving at most 500 candidates per request means up to 12.5 million candidate evaluations/s before caching or batching. Twenty 2 KB metadata items per response imply roughly 1 GB/s at that design peak, excluding protocol overhead and media delivery. These are arithmetic bounds, not measured serving throughput.

APIs, stored data and the request path

GET /feed?cursor=... returns item IDs, playback metadata and an opaque next cursor. Derive the viewer from authenticated context. Bind cursors to that viewer, a short-lived session, candidate snapshot and model version; reject another viewer's cursor and expired sessions. Keep ranking scores and sensitive feature data out of the public response.

Store video metadata with creator ID, publish time, availability and policy version. Keep media in object storage behind a CDN. Publish metadata and an outbox event together so an acknowledged eligible item can eventually reach retrieval indexes even if a worker crashes. Consumers deduplicate event IDs and apply newer video versions before older ones.

The read path is authentication → parallel candidate retrieval → eligibility filtering → ranking → diversity/deduplication → metadata hydration → final eligibility check. Retrieval sources can include interests, recent eligible uploads and followed creators. Cap each source and the combined pool. A ranker cannot recover a good item that retrieval never supplies.

Model training is outside this exercise. The ranking service receives bounded eligible candidates and versioned features, returns finite scores tied to a model version, and has a deadline. Tie-break deterministically, then apply the mock's diversity rule: no adjacent items from the same creator when another eligible choice exists. If that rule leaves fewer than twenty items, return a shorter page instead of inserting an unsafe item.

Keep a short-lived served-ID set for the session to suppress repeat pages. Freeze candidate ordering within that session so score changes do not reshuffle pagination underneath a cursor. Refresh starts a new snapshot; this is the explicit trade-off between stable scrolling and continuously fresh ranking.

Freshness and fan-out are different decisions

Use incremental index updates plus bounded caches to meet the assumed freshness target. Measure eligibility-to-index and index-to-first-opportunity delays separately. A snapshot created before a new upload may omit it until refresh; do not describe that session as instantly fresh.

For a followed-creator retrieval source, ordinary creators can push IDs to active followers' candidate inboxes. High-fan-out creators can be fetched at read time. With fictional 100,000 active followers and 200 bytes per inbox record, one upload creates about 20 MB of logical writes before replication or index overhead. The threshold depends on measured write budget and reader activity; do not invent one universal follower cutoff.

This hybrid supplies candidates. It does not mean every discovery recommendation is pushed to every follower, or that chronological following order is equivalent to personalized discovery ranking.

Failure choices that belong in the answer

A final metadata check alone cannot guarantee that a removal arriving immediately afterward never reaches a client. Define the revocation propagation target and make the playback path enforce current access. Previously downloaded bytes have their own limits. Say where the guarantee ends.

A nominal budget might allocate 30 ms for authentication/routing, 60 for retrieval, 60 for ranking, 35 for hydration/policy and 15 for assembly: 200 ms total. Adding stage budgets is planning, not proof of end-to-end p95. Benchmark complete requests, correlated stalls and fallback paths under load.

09ByteStyle preparation: decisions, evidence and collaboration

TikTok's philosophy page names ByteStyle themes including candor, pragmatic investigation and growth together. Prepare real examples of changing a decision with evidence, communicating a problem early and helping a teammate succeed. Values are public context; this guide does not claim private scoring weights.

A useful project answer identifies the user problem, your responsibility, an alternative, the evidence you checked and the resulting change. “We optimized the feed” gives little to examine. Explain which part you owned, what the measurements included and what still failed. Credit teammates' work separately.

For disagreement, describe the other person's reasoning fairly. A story becomes more credible when you can explain evidence that changed your own view. For “why TikTok,” connect your actual experience to a problem in the specific role rather than repeating the brand mission.

10Timed practice with reviewable outputs

These are suggested practice durations, not TikTok interview timers.

Run a baseline, spend the next week repairing the weakest artifact, then repeat under the same conditions. Experienced candidates should deepen the design and ownership exercise; early-career candidates should first finish working code and a defensible project explanation.

11Frequently asked questions

How many rounds should I expect?

TikTok describes several interviews, with variation by position and team. Ask your recruiter for the current sequence. The guide's skill map is not a fixed round count.

Is the online assessment required everywhere?

The Early Careers FAQ scopes assessment use by location and technical role. Use your own invitation for settings and rules; do not assume another candidate's test applies.

Should I prepare system design as a new graduate?

Practice scoped API and data-model reasoning, then confirm the expected depth. Experienced backend roles warrant more capacity, failure and rollout practice. Neither route establishes a universal stage.

How long will the process take after an assessment?

The public early-careers guidance gives no guaranteed time to interview after passing. Keep practice current and communicate real scheduling constraints to your recruiter.

Is the feed design TikTok's actual architecture?

No. It is an original mock with fictional traffic, deadlines and service choices. Public product descriptions support the context, not the implementation.

12Sources and further reading

Checked October 8, 2026. Coding fixtures, sizing assumptions, design decisions and practice durations are original PracHub material.

• TikTok: How We Hire — public recruitment baseline.
• TikTok: Interview Tips — role and experience preparation.
• TikTok: Early Careers FAQ — assessment variation and timeline limits.
• TikTok: Our Philosophy — public ByteStyle context.
• TikTok Newsroom: How TikTok recommends videos, June 2020 — dated product explanation, not a current systems blueprint.