Code Execution & DSA Engine: DSA Question Design & Structure

Part 3 of 5 in the Code Execution & DSA Engine series.

Test Case Generation & Verification covered how a question's test cases earn their way into the shipped file. This page covers the shape of that file itself — the format both qgen and the website's content pipeline agree on, using a real, currently-shipped question (baby-ninja.md) as the walkthrough rather than a hypothetical one.

Frontmatter: the metadata the bank filters on

---
title: Baby Ninja
difficulty: Medium
topic: Dynamic Programming
companies: [D. E. Shaw]
tags: [dp, kadane, array]
languages: [cpp17, python, java]
order: 1
timeLimit: 1
memoryLimit: 256
---

topic doubles as a signal for qgen's preset auto-detection (covered in the next page): a draft's topic: line is matched against keyword lists to pick a difficulty-appropriate case budget without a human specifying --preset by hand. companies and tags are what Question Bank & Content Runtime filters on in the browsing UI — the same metadata authors write is the metadata students search by.

The judge is stdin/stdout, not a function signature

This matters enough to state plainly: Ediky's judge is Codeforces/AtCoder-style — a submitted program reads from stdin and writes to stdout — not a LeetCode-style harness that calls a function and inspects its return value. A fresh editor gets a one-line placeholder comment by default, and writing your own input parsing is part of the exercise. A question can opt into showing an authored starter snippet via functionSignature: true in frontmatter, but that only changes what the editor pre-fills on open; it does not add function-call judging. The submitted program still has to read stdin and print stdout either way.

Body structure: four section markers

diagram100%

rendering diagram…

drag to pan · ctrl / ⌘ + scroll to zoom

The statement is ordinary markdown with inline LaTeX ($n$, $a_i$) for constraints and variables, followed by an Input/Output spec described in plain prose, a Constraints list, and one or more worked Examples as literal stdin/stdout text blocks. <!--HINTS--> is a flat bullet list; the reader-facing UI reveals it progressively, one nudge at a time, rather than dumping every hint at once. <!--SOLUTION--> carries a written explanation, a stated Time: / Space: complexity, and then one ### C++, ### Python, ### Java heading per reference language — the same heading text langs.py (from Test Case Generation) parses to know which compile/run recipe applies.

## DP / Modified Kadane's Algorithm

Because Maku can only jump from index i to i+k, banks partition into
independent chains based on index mod k...

- Time: O(n)  Space: O(n)

### C++
[full C++ solution]

### Python
[full Python solution]

### Java
[full Java solution]

Test cases: one JSON block, visible and hidden together

{
  "cases": [
    { "stdin": "3\n10\n-5\n20\n2\n0\n", "expected": "30" },
    { "stdin": "5\n1\n-2\n3\n-4\n5\n1\n6\n", "expected": "11" },
    { "stdin": "73\n-1000\n...\n4\n0\n", "expected": "0", "hidden": true }
  ]
}

Cases without hidden: true are the samples shown on the problem page and run by "Run All"; hidden: true cases are held back and only exercised on Submit — the split Judge0 & Code Execution covered as visible-cases-always-report vs. fail-fast-on-submit. Nothing about a case's structure differs between the two; hidden is the only flag that changes its treatment.

Reading the algorithm off the format

Because <!--SOLUTION--> states complexity explicitly rather than leaving a reader to infer it, the format itself teaches complexity analysis by example. Baby Ninja's own stated solution is a clean illustration:

# Simplified shape of the stated O(n) / O(n) approach
def max_candies(a, k, c):
    dp = [None] * len(a)
    best = c
    for i in range(len(a)):
        prior = dp[i - k] if i >= k and dp[i - k] is not None else c
        candies = max(c, prior) + a[i]
        if candies >= 0:
            dp[i] = candies
            best = max(best, candies)
    return best

Because jumps are fixed at length k, banks split into k independent chains by index-mod-k, and each chain reduces to a Kadane's-algorithm variant with a fixed restart value c instead of restarting at zero — one pass, O(n) time, O(n) space for the dp array (reducible to O(k) if only the running maxima per chain are kept, though the shipped solution keeps the full array for clarity).

Company tags reflect real sourcing, not a fixed taxonomy

A meaningful share of the 70-question bank was transcribed from real online-assessment screenshots (D. E. Shaw, Flipkart, Okta, Cisco, HackerRank among them) rather than authored from scratch, which is why companies: values are the company that actually asked a given question rather than a curated mapping from company to topic area. There is no fixed rule like "Amazon problems are always graph problems" baked into the format — the tag records provenance, and the topic/tags fields (not the company) are what drive filtering and preset selection.

Self-assessment

Word count for this page: 869 words.

---

← Previous: Test Case Generation & Verification→ Next: Multi-Language Support & SQL Runner