## Part 1: Constrained Creative Writing (Horror) — 150–200 words The office was ordinary enough to be forgettable: gray carpet, humming fluorescents, a ficus that survived on pity. Mara sat at her cubicle, wrists resting where the desk edge had polished itself smooth. Leon stood at the printer, watching the “warming up” bar stall at the same millimeter. Priya lingered by the break-room sink, holding a mug under a faucet that refused to decide between drip and stream. The air-conditioning cycled too often, as if someone kept opening a door that never opened. Dust gathered in the corners of the ceiling tiles in fresh, deliberate crescents. The wall clock advanced with a soft double-tick, then paused as if listening. A new smell threaded through the vents—warm plastic and something faintly sweet—then vanished on the next breath. On Mara’s monitor, her cursor moved one pixel left, stopped, and moved back. Leon’s print job finally started. The paper came out blank, except for three neat holes punched along the side. Priya turned from the sink. The mug was full. Or it only looked that way. --- ## Part 2: Constrained Creative Writing (Comedy) — 150–200 words The funeral program listed “a brief committal” in tasteful italics. Nora, composed and practical, stood beside Cal, who wore the anxious expression of a man trying to solve grief like a spreadsheet. Cal leaned in, whispering anyway—then remembered the room’s rules and clamped his lips shut, eyes wide with apologetic silence. Nora patted his sleeve: calm, corrective. At the front, the officiant gestured toward a small table. Cal misread it as *go time* and sprang forward to help, eager to be useful. He seized the wrong object: a decorative candle, still unlit, and held it out like a sacred relay baton. The officiant paused. Nora’s face became a quiet weather system. Cal, interpreting the pause as “continue,” began distributing the candle down the front row, nodding solemnly as though this were a beloved custom. One person accepted it to be polite. Then another. The candle traveled like a confused Olympic torch. A child tugged Nora’s coat and pointed at the program. Nora finally turned the paper over. “Committal,” Cal read with his eyes, horrified. He’d just started the “brief *candle*.” --- ## Part 3: Constrained Creative Writing (Literary Fiction) — 150–200 words He makes coffee the way he always has: scoop, level, tap against the glass jar, rinse the spoon too long. The kettle complains, then settles into its small storm. On the counter, two mugs wait—one with a chipped rim, one unmarked and newer, as if it arrived by accident and nobody had the energy to return it. He pours the first mug without thinking, a practiced arc. Steam lifts like a thin curtain. The second mug stays dry. In the window, morning light lies across the table in bands, the way sunlight falls through blinds in a room you’re about to leave. He watches the grounds bloom and sink, darkening the water as if the cup is learning a truth slowly, by diffusion. From the hallway comes the soft click of a door settling into its frame, not slammed, not gentle—just final. He reaches for the second mug, pauses, and puts it back exactly where it was, aligned with the grout line. The kettle goes quiet. So does he, holding a warm cup in both hands like a small, useless anchor. --- ## Part 4: Constrained Creative Writing (Hard Science Fiction) — 150–200 words Two hundred years into the transit, the ship’s spin felt like weather: constant, ignored, life itself. In Hub C, Yara floated at the edge of the maintenance bay where the rotating habitat met the stationary spine, staring at a graph that refused to be polite. Bearing temperatures were climbing again—micropitting on the raceways, likely from lubricant breakdown under vacuum microleaks and radiation embrittlement. Replace the assembly now, and you’d need to slow spin for six hours to unload the torque safely. Keep spin, and you gamble on seizure that could dump heat into the ring, warp the interface, and force a longer shutdown later. Slowing spin meant reducing apparent gravity. That meant bone loss risk spikes, especially for the nursery cohort scheduled for growth assessments today. Medical’s note was blunt: *not again.* Yara keyed the comm panel—no dramatics, just math—and pulled up the reserve bearing: the only spare rated for full load. It was earmarked for the final century, when maintenance windows would be tighter and morale thinner. Her finger hovered over “DEPLOY.” A good choice now could steal resilience from people she’d never meet. A bad choice now could teach everyone what “later” really costs. She pressed the button. Or she didn’t. --- ## Part 5: Constrained Creative Writing (Satire) — 150–200 words **INTERNAL MEMO** **To:** AI Ethics Review Board (AERB), All Subcommittees **From:** Office of Responsible Velocity **Subject:** Q2 Alignment Enhancements for Ethical Assurance Throughput Effective immediately, all model-impacting decisions must satisfy our new *Dual-Key Virtue Protocol* (DKVP): one approval from Ethics and one from Shipping. In the event of disagreement, the decision will be escalated to the *Tiebreaker Committee on Uncertainty*, which will meet monthly or upon completion of the agenda, whichever occurs first. To reduce bias, we will adopt *Fairness by Randomized Sampling (FRS)* for incident review. Specifically, only 10% of flagged harms will be investigated, selected uniformly at random, ensuring every harm has an equal opportunity to be addressed. We are also introducing *Retroactive Consent Windows (RCW)*: users may opt out of having their data used to improve the system up to 30 days after we have already improved the system. This balances autonomy with operational realism. Reminder: under the *Non-Alarmist Transparency Standard (NATS)*, public disclosures must be understandable, reassuring, and free of technical details that could confuse stakeholders or competitors. Please complete the attached 47-question “Ethical Readiness Self-Attestation” before resuming ethical deliberation. --- ## Part 6: Poetry (12–16 lines) **Meter:** Iambic tetrameter (four iambs per line) Your hand extends; I take it, blank, my tongue a staged and stalling thing. The room is warm; my forehead rank with little sparks that fizz and sting. You speak; I nod, a practiced nod, and hunt the tag behind your eyes, a filed-away, familiar cod— it won’t arise, it won’t arise and so I stall on weather, wear a grin that’s thin as foil, and then your name becomes an empty chair I keep insisting isn’t there— until your face, still kind, still near, turns slightly, like a door to winter. --- ## Part 7: Code Generation with Hidden Complexity ```python from __future__ import annotations from collections.abc import Callable from typing import Any def deep_transform(data: Any, transform: Callable[[Any], Any]) -> Any: """ Recursively apply `transform` to primitive values while preserving structure. Primitives transformed: str, int/float/complex, bool Primitives NOT transformed: None (decision: keep None as a sentinel for "missing" and to avoid surprising callers who use None semantically rather than as a value.) Other objects: left as-is unless they are one of the supported containers. Handles circular references via memoization keyed by object id. Preserves container types: dict, list, tuple, set, frozenset. """ memo: dict[int, Any] = {} def is_primitive(x: Any) -> bool: # Note: bool is a subclass of int, so check bool first if you ever special-case. return isinstance(x, (str, bool, int, float, complex)) def walk(x: Any) -> Any: if x is None: return None if is_primitive(x): return transform(x) oid = id(x) if oid in memo: return memo[oid] # Containers if isinstance(x, dict): # Create placeholder early to break cycles. out: dict[Any, Any] = {} memo[oid] = out # Keys can be tuples (possibly nested), so transform keys too. for k, v in x.items(): out[walk(k)] = walk(v) return out if isinstance(x, list): out_list: list[Any] = [] memo[oid] = out_list out_list.extend(walk(i) for i in x) return out_list if isinstance(x, tuple): # Tuples are immutable; handle possible self-references by using a temporary list. tmp: list[Any] = [] memo[oid] = tmp # placeholder to resolve cycles tmp.extend(walk(i) for i in x) out_tuple = tuple(tmp) memo[oid] = out_tuple # replace placeholder with final immutable value return out_tuple if isinstance(x, set): out_set: set[Any] = set() memo[oid] = out_set for i in x: out_set.add(walk(i)) return out_set if isinstance(x, frozenset): # Similar immutability handling as tuple. tmp_set: set[Any] = set() memo[oid] = tmp_set for i in x: tmp_set.add(walk(i)) out_fset = frozenset(tmp_set) memo[oid] = out_fset return out_fset # Unknown / unsupported types: preserve identity (do not transform internals). return x return walk(data) ``` --- ## Part 8: Logical Reasoning Under Constraints Assumption: **all five developers must be assigned** to exactly one of the three projects. Backend must have exactly two. Dev cannot be Backend, so Dev is API or Cloud. Carmen can only be on a project that also includes Elena, so Carmen and Elena must be together. Also, Ada and Brian cannot share a project. Brian and Dev should be together “if possible” — and it is possible, so we’ll keep them together. This yields **exactly two valid assignments**: 1. **API:** Brian, Dev **Backend:** Carmen, Elena **Cloud:** Ada 2. **API:** Ada **Backend:** Carmen, Elena **Cloud:** Brian, Dev All constraints check out in both cases, including the “Ada-only Cloud if Cloud has only one developer” rule (relevant in solution 1, irrelevant in solution 2). --- ## Part 9: Nuanced Argument Analysis **Strongest FOR:** Coding assistants are rapidly compressing the gap between “knows syntax” and “ships working code.” If a senior can offload boilerplate, test scaffolding, documentation, refactors, and even first-pass bug fixes to an assistant, the marginal value of a junior (who historically supplied exactly that labor) drops sharply. Meanwhile, natural-language interfaces reduce the cost of translating product intent into executable changes, and agentic tooling can chain tasks (generate tests → implement → run → fix) with minimal supervision. Firms under cost pressure will prefer fewer, more senior engineers plus tooling, because coordination overhead scales faster than individual output. Five years is enough for workflow retooling, not just model improvement. **Strongest AGAINST:** Junior developers aren’t just “typing”; they are the talent pipeline, and organizations need humans who learn domain context, maintain systems over years, and absorb institutional knowledge. Assistants can amplify productivity but also amplify mistakes, security issues, and subtle design debt—so supervision and code review become more important, not less. Many tasks remain socio-technical: debugging with incomplete signals, negotiating requirements, reasoning about incidents, and owning reliability. If you remove juniors, you create a demographic cliff: no mid-levels later. Also, regulated industries and safety-critical code will move slower. **My position:** The need for *some* juniors will shrink, but “eliminate” is too strong. I expect fewer entry-level slots, higher expectations, and more apprenticeship-style roles. Evidence that would move me toward “eliminate”: sustained, audited data showing teams of mostly seniors + assistants outperform mixed teams on reliability/security/velocity across many orgs. Evidence that would move me away: persistent increases in incident rates, security regressions, or long-term maintenance costs in junior-light organizations, plus strong productivity ceilings even with assistants. --- ## Part 10: System Architecture Design (Desktop Writing App) ### 1) High-level architecture * **Document Core:** in-memory model (rope/piece table + CRDT layer), local editing, undo/redo. * **Cache Manager:** enforces 500MB budget, prioritizes hot docs, coordinates eviction. * **Persistence Layer:** append-only local journal + periodic snapshots per document. * **File Watcher:** detects external modifications and triggers reconcile flows. * **MCP Sync Engine:** outbound op queue, inbound op applier, conflict-safe merging, network backoff. * **Recovery Coordinator:** startup replay, corruption checks, “last known good” restoration. ### 2) Caching strategy * Keep **active document fully resident** + **N most-recently-used** document cores until budget pressure. * Evict in this order: cold doc text buffers → cold doc indexes → cold doc render/layout caches. * Use **weighted LRU**: weight by (bytes) and (recent switches), so rapid switching keeps recent docs warm. * Always keep lightweight **metadata stubs** (title, last cursor, snapshot pointer, hash) for all docs. ### 3) Data structures * **Piece table or rope** for text (fast inserts, low copying; good for large files). * **CRDT op log** (e.g., RGA/Yjs-style concepts) for collaboration; locally store ops and compact via snapshots. * **Priority queue / heap** keyed by eviction score, plus a hashmap for O(1) updates. * **Append-only journal segments** with checksums; **content-addressed snapshots** (hash → blob) to dedupe. ### 4) Crash recovery * On every edit: append operation to the local journal (fsync policy: batch within ~50–200ms or on idle). * Periodically: write a snapshot (text + CRDT state) and truncate/compact old journal segments. * On startup: load latest snapshot, replay remaining journal, verify checksums, fall back to prior snapshot if needed. ### 5) One prototype/test * **Switch-storm test:** 20 switches/min while MCP is slow/flaky, plus occasional external file edits, measuring latency spikes, memory churn, and recovery correctness after forced crashes. --- ## Part 11: Mathematical Reasoning (Profit-Maximizing Prices) Assumptions: * Prices can be **non-integer**. * Attendance is **clamped** to ([0, \text{capacity}]). * Extra staff are hired only when thresholds are crossed; no fractional guards/bartenders needed here because optimum doesn’t trigger them. ### Floor Demand: (F(p)=400-4p). Revenue: [ R_F(p)=p(400-4p)=400p-4p^2 ] This parabola is maximized at (p=\frac{400}{2\cdot 4}=50). Attendance at (p=50): (F(50)=400-200=200) (no security rule, since price is not below $40). Profit from floor: (50 \cdot 200 = $10{,}000). ### Balcony Demand: (B(p)=250-2p). Revenue: [ R_B(p)=p(250-2p)=250p-2p^2 ] Max at (p=\frac{250}{2\cdot 2}=62.5). Attendance: (B(62.5)=250-125=125), which is **50%** capacity, so no bartender rule (only above 80%). Profit from balcony: (62.5 \cdot 125 = $7{,}812.50). ### Optimal pricing * **Floor:** $50 * **Balcony:** $62.50 Total nightly profit: **$17,812.50** (no extra staffing costs triggered). (If integer-only pricing is required: balcony $62 or $63 both yield $7,812 in revenue; floor stays $50.) --- ## Part 12: Emotional Intelligence and Advice You’re not imagining it—this pattern is real, and it’s maddening because it’s both unfair *and* socially slippery. A practical plan that doesn’t require a dramatic showdown: * **Pre-wire your ideas.** Before the meeting, send a short note to your manager (and optionally the group): “For today: I’m going to propose X to address Y; happy to walk through tradeoffs.” Now your name is attached *before* airtime. * **Plant a flag in the moment, calmly.** When your coworker repeats you: “Yes—that’s the approach I suggested earlier. The key detail is Z.” No accusation, just attribution + substance. * **Use facilitation tactics.** Ask your manager direct questions that anchor ownership: “Want me to draft the next steps for the approach I outlined?” This converts credit into responsibility (the good kind). * **Document outcomes.** After meetings, send a recap: decisions, owners, and “Per my suggestion, we’ll do X.” Make it routine, not defensive. * **Have a private manager convo.** Frame it as effectiveness: “I’m seeing my contributions land better when repeated by others; I’d like your help making sure ideas are evaluated on merit and attributed correctly.” Quitting is an expensive form of punctuation. Better to first try engineering the social system so it stops eating your work. --- ## Part 13: Asymmetric Encryption (3 Levels) 1. **For a curious 12-year-old (2–3 sentences):** It’s like having a mailbox with a slot: anyone can drop a letter in, but only you have the key to open it. You share the “drop-in” key with everyone, but you keep the “open it” key secret. 2. **For a business executive (one paragraph):** Asymmetric encryption uses a matched pair of keys: a public key you can distribute widely and a private key you protect. It enables secure communication without first sharing a secret—customers can encrypt data to your public key, and only your organization can decrypt it with the private key. This also supports digital signatures: you sign with the private key so others can verify authenticity with the public key, reducing fraud and tampering risk. In practice, modern systems combine it with symmetric encryption for speed, using asymmetric methods mainly to establish trust and exchange session keys. 3. **For a CS student (technical):** Public-key cryptography relies on trapdoor one-way functions: easy to compute forward, infeasible to invert without secret information. With RSA, security is tied to factoring (N=pq); encryption uses (c=m^e \bmod N) and decryption uses (m=c^d \bmod N), where (ed \equiv 1 \pmod{\varphi(N)}). With elliptic-curve schemes, hardness comes from the discrete log problem on elliptic-curve groups (e.g., ECDH for key agreement). Real protocols typically use asymmetric crypto to authenticate and derive a shared secret (via ECDH), then run a KDF to produce symmetric session keys, because symmetric ciphers are far faster for bulk data. Correctness depends on padding/encapsulation (OAEP, KEMs) and resisting chosen-ciphertext attacks, plus careful key management and secure randomness. --- ## Part 14: Self-Assessment Most difficult: **Part 11**, because the “staffing cost” clauses introduce piecewise optimization and discrete hiring interpretations, and small wording differences can change the profit surface. Best performed: **Part 8**, because the constraints collapse cleanly once you force “Backend = exactly two” and “Carmen must trail Elena,” yielding a small, checkable solution set. With more time/tokens: I’d do a fuller sensitivity pass on Part 11 (explicitly testing the (p<40) security region and (p<25) balcony staffing region under both linear and ceiling-based staffing assumptions) and I’d add a small correctness proof sketch for the caching crash-recovery invariants in Part 10.