Roblox OA 코딩 테스트 출제 유형과 합격 전략 (2026)

Roblox 온라인 코딩 테스트를 통과하면 리크루터에게서 연락이 옵니다. 통과하지 못하면 대개 지원은 거기서 끝납니다. OA는 시간 제한이 있고 자동으로 채점되는 코딩 스크리닝이며, 최근 지원자 후기에서는 소프트웨어 엔지니어와 신입 직군에 CodeSignal 방식의 평가가 가장 많이 언급되지만, 플랫폼과 형식은 채용 시즌마다 달라집니다. 이 가이드는 OA 단계만 다룹니다. 저희 기출 문제 모음에 있는 실제 Roblox 평가의 문제 유형, 채점기가 걸러내는 것, 샘플을 통과한 코드가 그래도 실패하는 이유, 제출 이후에 일어나는 일을 설명합니다. 전체 면접 과정은 Roblox Software Engineer Interview Guide와 Roblox Data Scientist Interview Guide를 참고하세요.

핵심 요약

• 저희 기출 문제 모음의 Roblox OA 문제는 구현 비중이 높은 시뮬레이션 쪽으로 치우쳐 있습니다. 무너지는 격자, 걸어 다니는 로봇, 파싱해야 하는 로그가 그 예입니다. 드문 알고리즘을 아는 것보다 40~80줄의 정확한 코드를 빠르게 작성하는 것이 더 중요합니다.
• 점수는 히든 테스트가 결정합니다. 공개된 샘플은 통과하지만 히든 대형 입력에서 O(n²)로 동작하거나 경계 타임스탬프에서 깨지는 풀이는 아무 설명 없이 실패로 채점됩니다.
• 저희 기출 문제 모음에서 Roblox SWE와 ML 스크리닝 전반에 반복되는 패턴은 두 가지입니다. 윈도우 카운팅(히트 카운터, 레이트 리미터)과 업데이트가 계속 들어오는 상황에서의 집계입니다. deque 제거 경계가 몸에 밸 때까지 둘 다 반복해서 연습하세요.
• 입력 제한에 명령 문자열이 10^9번 반복된다고 나와 있다면, 채점기는 시뮬레이션하지 말고 불변식을 증명하라고 알려주는 것입니다. 이 신호를 알아보는 능력은 어떤 외운 템플릿보다 가치가 큽니다.
• 플랫폼, 시간, 문제 수는 시즌마다 바뀝니다. 많은 직군에서 과거에는 CodeSignal 방식이었지만, 이 가이드를 포함한 어떤 글보다도 초대 이메일을 믿으세요.

Roblox OA는 어떤 모습인가 (그리고 그 설명을 얼마나 믿어야 하는가)

먼저 단서를 달아 둡니다. 이 부분이 중요하기 때문입니다. 온라인 테스트의 운영 방식은 어느 회사의 채용 과정에서든 가장 안정적이지 않은 부분입니다. 아래 내용은 최근 지원자 후기와 저희 기출 문제 모음에 제출된 문제를 반영한 것이며, 여러분의 초대에 대한 보장은 아닙니다.

그럼에도 최근 후기의 패턴은 이렇습니다. Roblox는 과거에 소프트웨어 엔지니어와 신입 직군에 CodeSignal 방식의 평가를 보내 왔습니다. 저희 기출 문제 모음에 있는 한 데이터 사이언티스트 평가는 지원자가 Python 또는 R을 선택할 수 있는 CodeSignal 방식 환경이라고 명시적으로 설명했습니다. CodeSignal의 General Coding Assessment 형식은 과거에 약 70분 동안 난이도가 올라가는 네 문제로 진행되었으며, 저희 CodeSignal OA guide에서는 회사 쪽에서 그 점수 리포트를 어떻게 읽는지 분석합니다. 초대장에 다른 플랫폼이 적혀 있다면, 지원자 입장에서 무엇이 달라지는지는 Codility vs HackerRank vs CodeSignal comparison에서 다룹니다.

실용적인 참고 사항이 두 가지 있습니다. 첫째, CodeSignal 평가에는 화면 및 카메라 감독이 흔히 적용됩니다. 규칙이 구체적이라 별도의 글로 정리해 두었으니 Does CodeSignal Record Your Screen?를 경고를 받은 뒤가 아니라 시작하기 전에 읽어 보세요. 둘째, 이 페이지는 의도적으로 OA만 다룹니다. Amazon에 대해 Amazon OA guide로 나눈 것과 같은 구분입니다. 전화 스크리닝 이후의 모든 과정은 위에 링크한 Roblox 전체 가이드에 있습니다.

이제 변하지 않는 부분입니다. 어떤 플랫폼으로 출제되든, 저희 기출 문제 모음에 있는 Roblox OA 문제의 내용은 놀라울 정도로 일관됩니다. 이 가이드의 나머지가 그것을 가르칩니다.

시뮬레이션이 Roblox의 주특기입니다

Asked at Roblox — Detect runs and collapse a numeric grid 숫자로 이루어진 m×n 격자가 주어집니다. 먼저 같은 숫자가 3개 이상 이어진 가로 또는 세로 연속 구간을 모두 찾아, 각 구간의 시작 칸과 길이를 행 우선, 그다음 열 순서로 보고합니다. 그런 다음 어떤 구간에든 속한 모든 칸을 제거하고, 남은 숫자를 각 열 안에서 아래로 떨어뜨린 뒤 위에서부터 다시 채웁니다.

이것은 축소판 match-3 게임 엔진이며, 게임 플랫폼에 지원하는 사람에게는 놀라운 일이 아닙니다. 알고리즘적으로 깊은 부분은 없습니다. 자기 상태를 망가뜨리지 않고 두 단계의 변경을 실행할 수 있는지를 보는 테스트입니다.

대부분의 지원자를 탈락시키는 실수는 연속 구간을 찾는 도중에 칸을 제거하는 것입니다. 한 칸이 가로 구간과 세로 구간에 동시에 속할 수 있으므로, 스캔 중에 삭제하면 두 번째 구간을 감지할 수 없게 됩니다. 올바른 형태는 표시 후 변경(mark-then-mutate)입니다. 한 번의 전체 순회로 모든 구간의 칸을 집합에 모으고, 두 번째 순회에서 삭제하고 중력을 적용합니다. 중력 자체는 열마다 쓰기 포인터가 아래에서부터 이동하며 남은 숫자를 아래로 복사한 뒤 나머지를 채우는 방식입니다.

두 단계 모두 시간은 O(mn)이고, 표시한 집합에 O(mn)의 공간이 듭니다. 더 영리한 방법을 찾고 있다면 멈추세요. 채점기가 원하는 것은 깔끔한 상태 관리이고, 추상화를 하나 더할 때마다 off-by-one을 심을 자리가 하나 늘어납니다.

같은 계열의 더 쉬운 문제도 저희 Roblox 기출 문제 모음에 있습니다. Can the character reach the destination?는 장애물이 있는 격자에서 네 방향, 시작점 하나, 목표 하나로 하는 평범한 BFS입니다. OA에서는 워밍업 문제이며, 여기서 점수를 잃는 유일한 방법은 칸을 큐에서 꺼낼 때가 아니라 큐에 넣을 때 방문 표시를 하는 것을 잊는 것입니다. 꺼낼 때 표시하면서 이미 방문한 칸을 큐에서 나올 때 건너뛰는 보호 장치가 없으면, 중복이 한 단계에서 다음 단계로 계속 불어나고, 히든 대형 격자에서는 알고리즘이 "맞더라도" 시간 제한을 넘깁니다.

입력이 10^9라고 하면 불변식을 증명하세요

Asked at Roblox — Simulate robot path and detect boundedness 로봇이 원점에서 북쪽을 향해 출발하여 G(앞으로 한 칸), L, R(90° 회전)로 이루어진 명령 문자열을 실행합니다. 문자열을 끝까지 실행한 뒤 이를 최대 10^9번 반복합니다. 한 번 실행한 뒤의 위치와 방향을 반환하고, 문자열이 영원히 반복될 때 궤적이 어떤 유한한 영역 안에 머무는지 판정하세요.

(a)는 10줄짜리 시뮬레이션입니다. (b)가 진짜 문제이며, 제약 조건의 10^9는 반복을 시뮬레이션해서는 끝나지 않는다고 채점기가 알려주는 것입니다.

찾아내야 하는 논증은 이렇습니다. 문자열을 한 번 실행하여 두 가지를 봅니다. 순 변위 d와 최종 방향입니다. d가 (0, 0)이면 로봇은 출발점으로 돌아와 있으므로 이후의 모든 반복이 같은 루프를 되풀이합니다. d가 0이 아니지만 방향이 바뀌었다면, 두 번 또는 네 번 반복한 뒤에는 회전이 합쳐져 다시 북쪽이 되고, 이전 반복에서 90°, 180°, 270° 회전된 변위들이 서로 상쇄되어 0이 됩니다. d가 0이 아니고 동시에 방향이 여전히 북쪽일 때만 로봇은 영원히 직선으로 멀어집니다.

def is_bounded(s: str) -> bool:
    x = y = 0
    dx, dy = 0, 1              # facing north
    for c in s:
        if c == 'G':
            x, y = x + dx, y + dy
        elif c == 'L':
            dx, dy = -dy, dx   # rotate left 90°
        else:                  # 'R'
            dx, dy = dy, -dx   # rotate right 90°
    return (x, y) == (0, 0) or (dx, dy) != (0, 1)

입력이 요구하는 반복 횟수와 상관없이 시간 O(|s|), 공간 O(1)입니다. "GL"로 추적해 보세요. 한 번 실행하면 (0, 1)에서 서쪽을 향해 끝나고, 네 번 실행하면 정사각형을 그리며 원점으로 돌아옵니다. 유한하며, 함수도 그렇게 답합니다.

Roblox는 저희 기출 문제 모음에서 더 까다로운 변형인 Design robot path boundedness with repeats도 출제합니다. 이 문제는 장애물과, 직전 명령을 반복하는 숫자 명령을 추가합니다. 무엇이 달라지는지 스스로에게 솔직해야 합니다. 장애물은 깔끔한 회전 논증을 깨뜨립니다. 첫 번째 반복에서 막힌 걸음이 두 번째 반복에서는 막히지 않은 지형일 수 있기 때문입니다. 구제책은 상태 반복입니다. 로봇의 방향은 늦어도 네 번의 반복마다 원래 방향으로 돌아오므로, 매 전체 반복 뒤의 (위치, 방향) 상태를 기록하고, 어떤 상태가 반복되면 궤적은 순환하므로 유한합니다. 이 논증에는 짚어야 할 허점이 있습니다. 몇 번의 반복까지 확인해야 하는지 상한을 정할 수 없다면 반복이 한 번도 나타나지 않는다는 사실은 아무것도 증명하지 못하므로, 종료 논증이 여전히 필요합니다. 이 허점을 소리 내어 인정하는 것이야말로 이 문제가 찾으려는 시니어 신호입니다.

윈도우 카운팅은 모든 직군에 나옵니다

Asked at Roblox — Implement recent-requests counter 웹 서비스를 위한 인메모리 히트 카운터를 만드세요. hit(timestamp)는 요청을 기록하고 getHits(timestamp)는 지난 5분 동안 들어온 히트 수를 반환합니다. 타임스탬프는 감소하지 않는 순서로 들어오며, 여러 히트가 같은 타임스탬프를 가질 수 있습니다.

이 문제는 머신러닝 엔지니어 스크리닝에서 보고되었고, 거의 같은 구조가 소프트웨어 엔지니어에게서도 보고되었는데, 이는 Roblox가 직군을 가로질러 윈도우 카운팅을 재사용한다는 뜻입니다. 모든 게임 경험에 요청 추적과 남용 제한이 필요한 Roblox 서비스와 직결됩니다.

깔끔한 풀이는 (타임스탬프, 개수) 쌍의 deque와 누적 합계를 쓰는 것입니다. getHits에서는 맨 앞의 타임스탬프가 timestamp - 300 이하인 동안 앞에서부터 제거합니다.

from collections import deque

class HitCounter:
    def __init__(self):
        self.q = deque()       # [timestamp, count] pairs
        self.total = 0

    def hit(self, ts: int) -> None:
        if self.q and self.q[-1][0] == ts:
            self.q[-1][1] += 1
        else:
            self.q.append([ts, 1])
        self.total += 1

    def getHits(self, ts: int) -> int:
        while self.q and self.q[0][0] <= ts - 300:
            self.total -= self.q.popleft()[1]
        return self.total

각 타임스탬프는 deque에 한 번 들어가고 한 번 나가므로 두 연산 모두 분할 상환 O(1)입니다. 공간은 마지막 쿼리 이후의 서로 다른 타임스탬프 수에 비례하며(제거는 지연 방식이라 getHits가 실행될 때만 deque가 정리됩니다), 쿼리가 들어올 때마다 윈도우 안의 타임스탬프로 줄어듭니다. 히든 테스트의 함정은 제거 경계입니다. 여기서 "지난 5분"은 반개구간 (ts − 300, ts]를 뜻하므로 정확히 ts - 300에 있는 히트는 윈도우 밖입니다. <=를 틀리면 보이지도 않는 테스트에서 실패합니다.

Asked at Roblox — Implement a sliding-window rate limiter 같은 아이디어를 더 빡빡하게 적용한 문제입니다. allow(userId, timestampMs)는 사용자당 최근 W밀리초 안에 최대 N개의 요청만 허용해야 하며, 각 요청이 승인되었는지 여부를 반환합니다. 후속 질문에서는 제한을 사용자별 그리고 게임별로 확장합니다.

히트 카운터에서 두 가지가 달라집니다. 첫째, 상태가 사용자별 deque의 dict가 되고, 후속 질문은 dict 키를 (userId, gameId) 쌍으로 바꾸기만 하면 되므로 키가 함수 인자 하나가 되도록 코드를 구성하세요. 둘째, 흔한 실수가 있습니다. 거부된 요청은 기록하지 않습니다. 사용자가 한도를 넘었을 때 거부된 시도가 슬롯을 차지하면, 계속 요청을 보내는 클라이언트는 영원히 스스로를 막아 버립니다. 제거하고, len(dq) < N을 확인한 뒤에야 추가하세요.

정확한 슬라이딩 윈도우는 활성 키마다 O(N)의 메모리가 듭니다. 후속 논의에서 말해 볼 만한 내용은 이렇습니다. Roblox 규모에서는 고정 윈도우 카운터나 토큰 버킷으로 옮기고 약간의 경계 부정확성을 받아들이겠지만, OA 채점기는 정확한 버전을 원합니다. 지금 어느 쪽을 요구받고 있는지 아는 것도 평가의 일부입니다.

업데이트가 계속 들어오는 집계: 쿼리 구성에 따라 구조를 고르세요

Asked at Roblox — Track Highest-Earning Experience 게임 경험(experience)에 대한 일련의 연산을 처리합니다. 'U'는 이름이 있는 경험에 수익 변동분을 적용하고, 'Q'는 현재 가장 많이 버는 경험을 묻습니다. 모든 쿼리의 답을 반환하세요.

함정은 뻔한 풀이입니다. 수익 dict와 누적 (best_name, best_value) 쌍을 유지하고, 모든 'U'마다 갱신하고, 쿼리는 O(1)에 답합니다. 변동분이 양수인 모든 샘플은 통과합니다. 그러다 히든 테스트가 현재 1위에게 음수 변동분을 주면 캐시된 최댓값이 낡은 값이 되고, 2위를 O(1)로 찾을 방법이 없습니다. 프롬프트 어디에도 변동분이 양수여야 한다는 제한이 없고 공개 샘플은 무난한 경향이 있으므로, 히든 세트가 적어도 한 번은 1위를 끌어내릴 것이라고 가정하세요.

현실적인 선택지는 세 가지이며, 맞는 것은 연산 구성에 달려 있습니다.

손에 익혀 두어야 할 것은 지연 힙입니다. 업데이트마다 새 (−profit, name) 항목을 push하고 삭제는 하지 않으며, 쿼리 때는 기록된 수익이 dict와 다른 항목을 맨 위가 최신이 될 때까지 pop합니다.

import heapq
from collections import defaultdict

profit = defaultdict(int)
heap = []                       # (-profit, name), possibly stale

def update(name: str, delta: int) -> None:
    profit[name] += delta
    heapq.heappush(heap, (-profit[name], name))

def query() -> tuple[str, int]:
    while True:
        p, name = heap[0]
        if -p == profit[name]:
            return name, -p
        heapq.heappop(heap)     # stale, discard

낡은 항목은 각각 최대 한 번만 pop되므로, m개의 연산 전체에서 총 작업량은 O(m log m)으로 유지됩니다. 면접관 스타일의 후속 질문이 동점을 물으면 규칙을 명시적으로 정하고(예를 들어 사전순으로 가장 작은 이름) 이를 힙 키 (−profit, name)에 반영하세요. 그러면 Python의 튜플 순서가 알아서 처리해 줍니다.

로그 문제: 정확하게 파싱한 다음 세세요

Asked at Roblox — Find most frequent call stack from logs 단일 스레드 프로그램의 로그에는 함수 진입과 종료가 기록되어 있습니다. 변화하는 호출 스택을 복원하여 매 진입 직후 스택을 문자열로 스냅샷으로 남기고, 가장 자주 나타나는 스냅샷과 그 횟수를 반환하세요.

인프라 색채가 있는 파싱은 Roblox 스크리닝에 반복해서 나오는데, 게임 서버 텔레메트리에 실제로 많은 시간을 쓰는 엔지니어가 있는 회사답습니다. 알고리즘은 스택과 Counter이지만 점수는 정확성에서 갈립니다. 스냅샷은 진입 뒤에만 찍고 종료 뒤에는 절대 찍지 않으며, 종료 시에는 pop하되 입력이 올바른 형식이라는 가정은 프롬프트가 보장하는 범위까지만 믿으세요.

소리 내어 짚어 둘 만한 세부 사항이 하나 있습니다. 스택을 문자열로 이어 붙이는 데 진입마다 O(depth)가 들기 때문에, n개의 이벤트와 최대 깊이 d에 대해 전체 순회는 O(n·d)입니다. OA에는 충분합니다. 후속 질문이 규모를 압박한다면, 답은 스택 상태의 증분 해싱으로 각 스냅샷을 O(1)에 만드는 것이고, 대신 해시 충돌을 처리해야 합니다. 또한 함수 이름에 나올 수 없는 구분자를 고르거나, 이어 붙인 문자열 대신 스택의 튜플을 Counter의 키로 쓰세요. 튜플을 쓰면 구분자 모호성 문제가 아예 생기지 않습니다.

더 단순한 문제도 저희 Roblox 기출 문제 모음에 있습니다. Find the Most Frequent Log Call은 단순한 빈도 세기이며, 동점, top-k(힙을 쓰면 O(n log k)), 스트리밍에 대한 후속 질문이 붙습니다. OA에서 문제가 이렇게 쉬워 보일 때, 눈에 보이는 과제는 입장료이고 후속 제약 조건이 진짜 문제입니다.

히든 테스트가 점수를 결정하고, 후속 질문이 그 위치를 알려줍니다

Asked at Roblox — Find largest digit-sum bucket size [low, high]의 모든 정수에 대해 각 자릿수의 합을 계산하고, 그 합으로 수를 묶습니다. 가장 큰 그룹의 크기를 반환하세요. 명시된 후속 질문은 범위가 매우 클 때 모든 수를 건드리지 않고 풀 수 있는가입니다.

단순한 반복문은 O((high − low) · digits)이고 공간은 아주 작습니다. 10^10 미만 수의 자릿수 합은 모두 1..90에 들어가기 때문입니다. 공개 샘플은 작은 범위를 쓰므로 모든 공개 샘플을 통과합니다. 후속 질문 문장은 히든 테스트가 어디에 있는지 채점기가 알려주는 것입니다. 하나씩 세면 시간 초과가 날 만큼 넓은 범위입니다.

규모가 커져도 통하는 답은 자릿수 동적 계획법입니다. f(N, s)를 [0, N]에서 자릿수 합이 s인 정수의 개수로 정의하고, N의 자릿수를 따라가며 각 위치에서 접두사보다 작아지는 수를 세어 계산합니다. 그러면 각 버킷은 f(high, s) − f(low − 1, s)이고, 전체 비용은 O(digits × 90 × 10)으로 사실상 상수입니다. OA 자체에서 완전한 자릿수 DP를 작성해야 하는 경우는 드뭅니다. 자동 채점기는 코드가 통과한 것만 점수로 매기지만, 확장 방식을 간략히 적은 주석은 1분이면 쓰고, 나중에 사람이 리포트를 읽을 때마다 도움이 됩니다.

이 패턴은 다른 문제에도 적용되며, Roblox OA에서 가장 유용한 사고 전환입니다. 지금까지 이 글에서 다룬 모든 실패 유형은 히든 테스트 실패입니다. 꺼낼 때 방문 표시를 해서 생기는 O(n²) BFS, 히트 카운터의 <= 제거 경계, 캐시된 최댓값을 무효로 만드는 음수 변동분, 10^9번의 로봇 반복 시뮬레이션이 그렇습니다. 이 중 어느 것도 샘플에서는 실패하지 않습니다. 체계적인 체크리스트는 why solutions fail hidden test cases and how to debug them 심층 분석에서 다룹니다. 요약하면 제출하기 전에 세 가지를 따져 보는 것입니다. 제약 조건이 허용하는 가장 큰 입력, 프롬프트의 윈도우나 범위 정의에 있는 모든 경계값, 그리고 샘플이 우연히 만족하는 모든 암묵적 가정(정렬되어 있는가? 양수인가? 유일한가?)입니다.

데이터 사이언티스트 OA는 코딩에 통계가 더해집니다

Asked at Roblox — Implement four DS coding tasks Python 또는 R을 선택할 수 있는 CodeSignal 방식의 평가로, 서로 독립적인 네 가지 과제가 있습니다. 그중 하나는 양측 2-표본 z-검정에 필요한 표본 크기를 구하는 것입니다. 과거 데이터 배열에서 지표의 표준편차를 추정한 뒤, 이를 유의수준, 목표 검정력, 최소 검출 효과와 결합합니다.

데이터 사이언스 직군으로 면접을 본다면, OA는 LeetCode 문제 네 개가 아닙니다. 동작하는 코드로 표현해야 하는 통계입니다. 검정력 분석 과제에서 그룹당 표본 크기 공식은 n = 2σ²(z₁₋α/2 + z_power)² / Δ²이며, σ는 과거 관측값에서 추정하고 결과는 올림합니다. 코딩 내용은 사소합니다. 이 스크리닝이 보는 것은 "alpha = 0.05, power = 0.8"에서 공식 시트 없이 올바른 z 분위수(1.96과 0.84)까지 갈 수 있느냐입니다.

DS 기출 문제 모음에는 그래프 유형의 문제도 있습니다. Find maximum follow depth using recursion은 소셜 그래프의 팔로우 간선을 주고, DFS로 시작 사용자에서 도달할 수 있는 가장 긴 팔로우 사슬을 구하게 합니다. 코드를 쓰기 전에 먼저 사이클이 있으면 어떻게 되는지 물어보세요. A가 B를 팔로우하고 B가 A를 팔로우하면 재귀가 영원히 돌기 때문이며, 방문 집합으로 막느냐 프롬프트가 사이클을 배제하느냐에 따라 풀이 전체가 달라집니다. 묻지 않아도 먼저 이 점을 꺼내는 것이 단순히 코드만 짜는 사람과 실제 프로덕션 데이터를 다뤄 본 데이터 사이언티스트의 차이입니다. OA 이후의 애널리틱스 케이스 라운드를 포함한 전체 DS 면접 과정은 맨 위에 링크한 Roblox Data Scientist Interview Guide에 있습니다.

10일 준비 계획

이 OA를 위해 석 달이 필요하지는 않습니다. 위의 패턴을 시간 압박 속에서, 실제로 사용할 언어로 목표를 정해 반복하는 것이 필요합니다.

1~2일차: 시뮬레이션 숙련. 위 섹션의 격자 붕괴 문제와 로봇 유한성 문제를 시간 제한 없이 풉니다. 목표는 상태 손상 버그가 0건이 되는 것입니다. 표시 후 변경, 무차별 대입보다 불변식입니다.

3~4일차: 윈도우 카운팅. 히트 카운터를 푼 다음, 게임별 확장이 있는 레이트 리미터를 풉니다. 둘 다 빈 편집기에서 두 번씩 작성하세요. 두 번째 시도는 각각 15분 이내여야 합니다.

5~6일차: 집계와 로그. 지연 힙을 쓴 최고 수익 트래커를 푼 다음, 호출 스택 카운터를 풉니다. 진행하면서 주석으로 트레이드오프를 설명하는 연습을 하세요. 일부 플랫폼은 코드를 사람 리뷰어에게 보여 주기 때문이며, 이는 저희 technical interview rubric breakdown에서 다룹니다.

7~8일차: 시간을 재는 전체 리허설. 문제 네 개, 70분, 실제 평가가 감독형이라면 카메라를 켠 상태로 진행합니다. 제약 조건을 그대로 재현하는 것이 중요합니다. 지식 부족보다 시간 배분이 더 많은 OA 시도를 망치고, 시간 배분은 시계를 켜고 하는 리허설로만 고칠 수 있습니다.

9~10일차: 자기 코드를 깨 보고, 그다음 쉬기. 리허설 풀이를 가져와 채점기가 하듯이 실패시켜 보세요. 가장 큰 입력, 경계 타임스탬프, 음수 값, 원소가 하나인 경우입니다. 그런 다음 멈추세요. 초대 이메일을 다시 읽고, 감독 규칙을 확인하고, 카메라와 연결을 테스트합니다.

OA 이후

일반적인 OA 이후의 흐름은 다음과 같습니다.

응답 시점은 코호트에 따라 크게 다르며, 경계선의 점수는 어느 결과보다도 오래 검토 중에 머물 수 있습니다. 첫 주의 무소식을 불합격으로 읽지 마세요. 초대장에 일정이 적혀 있지 않았다면 리크루터에게 일정을 물어보세요.

점수가 어떻게 쓰이는지 알아 둘 점이 두 가지 있습니다. 첫째, CodeSignal 같은 플랫폼은 회사에 합격/불합격 값만이 아니라 문제별 리포트를 전달합니다. 어려운 문제의 부분 점수가 빈 답안보다 더 클 수 있으므로, 테스트 도중에 시간을 어떻게 배분할지가 달라집니다. 둘째, OA를 잘 봐도 온사이트에 이어지지 않습니다. 전화 스크리닝과 화상 온사이트 라운드는 실시간 문제 해결, 소통, 그리고 (시니어 직군의 경우) 시스템 디자인을 평가하는데, OA는 그중 어느 것도 측정하지 않았습니다. 통과하면 바로 준비 방향을 바꾸세요. 처음에 링크한 Roblox Software Engineer Interview Guide가 전화 스크리닝 이후의 과정을 다룹니다.

PracHub에서 연습하기

각 문제가 단련하는 기술 순서대로 이 실제 Roblox 문제들을 풀어 보세요.

• 변경이 일어나는 격자 시뮬레이션 — Detect runs and collapse a numeric grid: 상태를 망가뜨리지 않는 두 단계의 표시 후 변경.
• 무차별 대입보다 불변식 추론 — Simulate robot path and detect boundedness: 10^9번 반복이라는 제약을 두 줄짜리 증명으로 바꾸기.
• 슬라이딩 윈도우 상태 — Implement a sliding-window rate limiter: 키별 deque, 제거 경계, 거부된 요청의 함정.
• 업데이트가 계속 들어오는 집계 — Track Highest-Earning Experience: 쿼리 구성에 따라 재스캔과 지연 힙 중 고르고, 음수 변동분에서도 깨지지 않기.
• 정확한 로그 파싱 — Find most frequent call stack from logs: 점수가 세부 사항에 달린 스택 복원.
• 확률적 추론 — Detect shuffle-mode sequence: 관찰된 노래 순서가 반복 없는 셔플과 일치하는지 판정하는, 코딩보다 추론이 중심인 드문 Roblox 문제.

회사별로 태그된 전체 기출 문제 모음은 PracHub questions에 있고, 알고리즘 문제 세트는 Coding & Algorithms 아래에, 플랫폼별 가이드는 resources에 더 있습니다.

실제 Roblox 문제를 학습 루프로 바꾸기

위에서 보고된 Roblox 문제들은 읽을거리 목록이 아니라 하나의 순서로 풀 때 가장 유용합니다. 연습 결과가 실제로 활용할 수 있는 근거로 남도록 모든 문제에 같은 네 단계 루프를 사용하세요.

링크된 문제를 한 번은 정확성을 위해, 또 한 번은 중단 없는 단일 타이머 아래에서 풀어 보세요. 두 번째 풀이에서는 첫 번째 구현을 외우지 말고 제약 조건이나 엣지 케이스를 적어도 하나 바꾸세요.