Interview guides / Teramind / Software Engineer
Teramind · Software Engineer
Updated · 2026-09-23

Teramind Software Engineer
Interview Guide

THE 60-SECOND BRIEF

A Software Engineer at Teramind plays a pivotal role in designing, building, and scaling enterprise-grade employee monitoring, data loss prevention (DLP), and insider threat detection software. Because Teramind products are deployed across thousands of customer endpoints and massive cloud infrastructures, engineers here face unique challenges related to low-latency data collection, high-throughput pipeline processing, and real-time behavioral analysis. The systems you build and maintain directly impact how organizations protect their digital assets and optimize operational efficiency. This requires a deep understanding of system-level performance, security protocols, and robust full-stack architecture. Engineers work on a mix of lightweight endpoint agents, complex on-premise deployments, and highly scalable cloud architectures.

This guide is scoped to a Software Engineer candidate at Teramind.

Teramind candidates report 4 rounds over 3-5 weeks. The stages below are what candidates describe, not a published process.

PythonLive CodingReact

42 min read

Practice 18 Software Engineer prompts
18Practice promptsAcross five skill areas
1With worked solutionsIncluded in the practice prompts

A Software Engineer at Teramind plays a pivotal role in designing, building, and scaling enterprise-grade employee monitoring, data loss prevention (DLP), and insider threat detection software. Because Teramind products are deployed across thousands of customer endpoints and massive cloud infrastructures, engineers here face unique challenges related to low-latency data collection, high-throughput pipeline processing, and real-time behavioral analysis. The systems you build and maintain directly impact how organizations protect their digital assets and optimize operational efficiency. This requires a deep understanding of system-level performance, security protocols, and robust full-stack architecture. Engineers work on a mix of lightweight endpoint agents, complex on-premise deployments, and highly scalable cloud architectures. Working as a Software Engineer at Teramind demands a balance of rapid execution and extreme technical precision. Because the company's core product involves deep system monitoring, the engineering team relies on highly optimized code that must run seamlessly in the background of target operating systems without degrading user experience or performance.

The Teramind interview process

01

HR Screening

reported

Initial screening conducted by HR to assess candidate fit.

What to demonstrate

  • Initial screening conducted by HR to assess candidate fit
  • Depth in Python

How to prepare

  • Be able to walk your CV end to end in two minutes, and say why this company specifically.
  • Have your salary expectations, notice period and location constraints ready, and ask for the rest of the loop in writing.
Teramind Software Engineer candidate reports ↗
02

Online Assessment

reported

Evaluation of critical thinking, logical reasoning, and basic coding proficiency.

What to demonstrate

  • Evaluation of critical thinking, logical reasoning, and basic coding proficiency
  • Depth in Python

How to prepare

  • Answer aloud and timed: What are the time and space complexities of inserting and deleting elements from a doubly linked list?
  • Answer aloud and timed: How does memory management differ when executing processes in a monolithic architecture versus microservices?
Teramind Software Engineer candidate reports ↗
03

Technical Round

reported

Live coding, system architecture, and code reviews are the primary focus.

What to demonstrate

  • Live coding, system architecture, and code reviews are the primary focus
  • Depth in Python

How to prepare

  • Answer aloud and timed: Implement a small end-to-end service with a Node.js backend and a React frontend that fetches, filters, and displays a list of active system processes.
  • Answer aloud and timed: Write a program to download a CSV file from a provided Google Sheets URL, parse the data, and import it into a local database using your preferred language and tools.
Teramind Software Engineer candidate reports ↗
04

Final Stage

reported

Deep dive with engineering leadership or executive management to discuss contract terms and technical expectations.

What to demonstrate

  • Deep dive with engineering leadership or executive management to discuss contract terms and technical expectations
  • Depth in Python

How to prepare

  • Answer aloud and timed: Create a functional full-stack TTL cache implementation within a strict 30-minute window.
  • Answer aloud and timed: How would you handle real-time state synchronization between a React frontend and a fast-updating backend data stream?
Teramind Software Engineer candidate reports ↗

Where candidates lose points

PracHub editorial advice for the preparation topics above.

01

Going into the loop without having done this.

To maximize your chances of success during the Teramind interview process, keep these practical tips in mind:

02

Going into the loop without having done this.

Prepare for Screen Sharing: You will be asked to share your screen and code live in front of the interviewer. Practice thinking out loud and structuring your workspace for maximum efficiency before the call.

03

Going into the loop without having done this.

Ensure you are fully comfortable with Teramind's internal tracking policy before proceeding deep into the interview process. The company requires all remote contractors to install their monitoring software, which tracks mouse movement, keyboard activity, and takes live screenshots to log billable hours.

04

Going into the loop without having done this.

Master Your Linux Basics: Be ready for rapid-fire questions on Linux terminal commands, process management, and basic networking. This is especially common if you reach the interview stages with senior engineering leadership.

Questions & practice

Choose a category, try a prompt, then open its approach, worked solution or follow-up when you need it.

15 technical prompts1 include a worked solution

Implement a small end-to-end service with a Node.js backend and a React frontend that fetches, filters, and di

medium
Full-Stack & Live Coding

Implement a small end-to-end service with a Node.js backend and a React frontend that fetches, filters, and displays a list of active system processes.

Approach
  1. Interpretation: list the OS processes on the machine running the Node server. Fix the contract first, e.g. GET /api/processes?q=node&minCpu=1&sort=cpu&limit=50 returning [{pid, name, cpu, memMb}], so the backend and the React side can be built and tested independently.
  2. Backend: an Express route runs execFile('ps', ['-A', '-o', 'pid=', '-o', 'pcpu=', '-o', 'rss=', '-o', 'comm=']): no shell, so no injection, and one -o per column since POSIX reads all text after = as the header. Match ^\s*(\d+)\s+(\S+)\s+(\d+)\s+(.*)$ so names keep spaces; rss is KiB.
  3. Filter, sort and limit on the server after parsing: validate minCpu as a number, allow sort only if Object.hasOwn(SORTS, sort) (a plain lookup lets constructor through), clamp limit, and return 400 otherwise. Parsing and filtering are O(n) in the process count; sorting is O(n log n).
  4. Frontend: state for processes, query, loading and error; a useEffect refetches when the debounced query changes, cancels the previous request with AbortController, and polls every few seconds with the interval cleared in cleanup. Key rows by pid; render empty and error states.
  5. Wiring and safety: proxy /api through the frontend dev server (or enable CORS on Express) and return a 500 with a readable message if ps fails. A process list reveals what runs on the host, so bind to localhost or put it behind auth.
  6. Test what breaks easily: unit-test the parser on a captured ps output fixture (names with spaces, trailing newline), test the filter and sort function without Express, and mock fetch in a component test that checks the empty, error and filtered states.
Follow-up
  • How would you add a Kill button safely? Behind auth, accept only an integer PID above 1 that isn't process.pid (kill(0) hits your process group, -1 every process you may signal), send SIGTERM, and map ESRCH/EPERM to 404/403.
  • Why can the CPU column look wrong? On Linux, ps %CPU is CPU time divided by the process's lifetime, not current usage; sample CPU time twice and divide the delta by the interval.
  • How would you make the list live instead of polling? Push changes over SSE or a WebSocket once a second, sending only added, removed and changed PIDs, and merge them into state keyed by pid.

Write a program to download a CSV file from a provided Google Sheets URL, parse the data, and import it into a

mediumWorked solution
Full-Stack & Live Coding

Write a program to download a CSV file from a provided Google Sheets URL, parse the data, and import it into a local database using your preferred language and tools.

Approach
  1. Don't fetch the share link itself: take the ID from /spreadsheets/d/<id>/ and request .../d/<id>/export?format=csv&gid=<gid>, leaving out gid for the first tab. The sheet must be readable by anyone with the link, or you get an HTML sign-in page, not CSV.
  2. Download defensively: set a timeout, follow redirects (the export endpoint typically redirects to a download host), check that Content-Type is text/csv before parsing, and decode with utf-8-sig so a byte-order mark doesn't end up in the first column's name.
  3. Parse with a real CSV parser (csv.reader or DictReader), never split(','): quoted fields can legally contain commas, quotes and newlines. Normalize headers into safe, unique column names and decide up front how to treat blank rows and rows longer than the header.
  4. Insert with parameterized executemany, never by formatting values into SQL, and quote identifiers that come from the header. Storing every column as TEXT is safe; inferring INTEGER or REAL is a bonus, but spreadsheet columns often mix types, so validate before trusting a guess.
  5. Make reruns safe: replace the table atomically (explicit BEGIN, drop, create, insert, commit) or upsert on a natural key. Python's sqlite3 autocommits DDL that runs outside a transaction, so without the explicit BEGIN a failed load can leave the old data dropped.
  6. Package it as a CLI (import_sheet.py URL --db data.db --table orders), log rows imported and skipped, and exit non-zero on failure so cron or CI notices. For very large sheets, stream the download to disk and insert in batches instead of holding everything in memory.
Worked solution 30 min

Sheet URL to SQLite importer

  1. export_url pulls the spreadsheet ID and optional gid out of an edit or share link, including multi-account /spreadsheets/u/1/d/ links, and omits gid when the link has none so Google exports the first tab; publish-to-web /d/e/ links map to pub?output=csv instead.
  2. download_csv fetches with a 30-second timeout, raises on a non-CSV response (the private-sheet case) and returns decoded text with any BOM removed.
  3. import_csv turns headers into lowercase snake_case names, names blanks col_N and suffixes duplicates, then skips blank rows, pads short rows, rejects rows with extra non-empty cells and stores empty cells as NULL.
  4. The drop, create and bulk insert run inside one explicit transaction, so an error leaves the previous table untouched. Wire it to a CLI with sqlite3.connect(db_path) and import_csv(download_csv(url), conn, table).
Python
import csv, io, re, urllib.request

def export_url(sheet_url):
    """Turn a Sheets edit/share or publish-to-web link into its CSV download link."""
    m = re.search(r"/spreadsheets/(?:u/\d+/)?d/(e/[\w-]+|[\w-]+)", sheet_url)
    if not m:
        raise ValueError("not a Google Sheets URL")
    gid = re.search(r"[#?&]gid=(\d+)", sheet_url)  # no gid -> Google exports the first tab
    base = f"https://docs.google.com/spreadsheets/d/{m.group(1)}"
    if m.group(1).startswith("e/"):  # publish-to-web link
        return base + "/pub?output=csv" + (f"&gid={gid.group(1)}&single=true" if gid else "")
    return base + "/export?format=csv" + (f"&gid={gid.group(1)}" if gid else "")

def download_csv(sheet_url, timeout=30):
    with urllib.request.urlopen(export_url(sheet_url), timeout=timeout) as resp:
        if "text/csv" not in resp.headers.get("Content-Type", ""):
            raise RuntimeError("got a non-CSV response; is the sheet link-shared?")
        return resp.read().decode("utf-8-sig")  # drops a leading BOM if present

def import_csv(text, conn, table):
    reader = csv.reader(io.StringIO(text, newline=""))
    header = next(reader, None)
    if not header:
        raise ValueError("CSV has no header row")
    cols = []
    for i, h in enumerate(header):  # safe, unique column names
        name = re.sub(r"\W+", "_", h.strip().lower()).strip("_") or f"col_{i + 1}"
        while name in cols:
            name += "_dup"
        cols.append(name)
    n, rows = len(cols), []
    for rec_no, row in enumerate(reader, start=2):
        if not any(cell.strip() for cell in row):
            continue  # skip blank rows
        if any(cell.strip() for cell in row[n:]):
            raise ValueError(f"record {rec_no} has more cells than the header")
        rows.append([cell or None for cell in (row + [""] * n)[:n]])  # '' -> NULL
    q = lambda ident: '"' + ident.replace('"', '""') + '"'
    conn.execute("BEGIN")  # explicit: sqlite3 would otherwise autocommit the DDL
    with conn:  # commit on success, roll back drop + create + inserts on any error
        conn.execute(f"DROP TABLE IF EXISTS {q(table)}")
        col_defs = ", ".join(q(c) + " TEXT" for c in cols)
        conn.execute(f"CREATE TABLE {q(table)} ({col_defs})")
        conn.executemany(f"INSERT INTO {q(table)} VALUES ({', '.join('?' * n)})", rows)
    return len(rows)

Scroll sideways to view long lines.

EXPECTED RESULTCalled with `table='people'` on CSV text `Name,Email Address\nAda,ada@x.io\nBob,`, it creates `people(name, email_address)` holding `('Ada', 'ada@x.io')` and `('Bob', NULL)` and returns 2. Time is O(rows x columns); memory is O(file size), since the text and parsed rows are held in memory.
Follow-up
  • How would you infer column types? Try int, then float, then date on every non-empty value; fall back to TEXT if any fails or has a leading zero before another digit ('02134' and '007' are identifiers, '0' and '0.5' are not).
  • What if the sheet is private? Call the Sheets API with a service account that has been granted read access to that sheet, and keep the service account key out of the repo.
  • How would you test it without the network? Stub the download function (or urlopen) and feed fixture CSVs with quoted commas, embedded newlines, blank rows, a BOM and an HTML error page.

Create a functional full-stack TTL cache implementation within a strict 30-minute window.

medium
Full-Stack & Live Coding

Create a functional full-stack TTL cache implementation within a strict 30-minute window.

Approach
  1. Interpretation: 'full-stack' means a cache service with an HTTP API plus a small UI to set, read and watch entries expire; here Flask and one HTML page. Budget ~3 minutes for the API contract, ~12 for the core and tests, ~8 for routes, ~7 for the UI; get one path working end to end first.
  2. API: PUT /cache/<key> with {value, ttlSeconds} returns 204; GET /cache/<key> returns {value} or 404 when missing or expired; DELETE /cache/<key>; GET /cache lists live entries with expiresInMs. Return 400 for booleans, non-numbers, NaN, infinity, TTLs <= 0 and TTLs over a 30-day cap.
  3. Core: a map of key to (value, expires_at) on a monotonic clock, lazy expiry inside get, and a background sweeper thread that pops a min-heap of (expires_at, seq, key) once a second so unread keys get freed. The seq tie-breaker stops the heap comparing keys; one lock guards every method.
  4. Inject the clock so tests never sleep: set with ttl 10, advance a fake clock by 9.999 and expect a hit, advance to 10 and expect a miss. Also test that an overwrite resets expiry and that the first write's leftover heap row doesn't evict the new value.
  5. UI: one HTML page served at / with a form for key, value and TTL and a table of live keys from GET /cache, refreshed after each write and once a second. Fill cells with textContent, not innerHTML, so a stored value can't inject script, and show a 404 as 'expired or missing'.
  6. Close by naming what was cut and the order you'd add it back: a size cap first, since memory is unbounded; then auth; then a shared store such as Redis if entries must survive restarts or be shared across instances.
Follow-up
  • How would the UI show a live countdown without calling GET /cache every second? Fetch expiresInMs once, count down locally from performance.now(), and refetch after a write, when a row hits zero, or on a slow poll for others' writes.
  • Why does the cache need a lock? Flask's dev server runs each request on its own thread by default, and the sweeper is one more: unlocked, items() can fail mid-iteration and sweep can delete a fresh write.
  • Why not one threading.Timer per key? Each timer is a thread and every overwrite must cancel the old one, so threads and memory grow with the key count, while one sweeper over a heap stays a single thread.

Suggested practice checklist

Built from the rounds and topics Teramind candidates report.

Small steps. Visible outcomes.0 / 7 completed
ONE WEEK · YOUR PACE

Prepare, practise & reflect

One practical outcome each day. Spend longer where you need it.

0 / 7 done
01Map the Teramind loop
  • Write out the reported sequence: HR Screening, Online Assessment, Technical Round, Final Stage.
  • For each round, write one sentence on what it is judging, from the description above, and mark the one you are least ready for.

Deliverable: A one-page map of the 4 reported rounds, with the weakest marked.

02Work Python
  • Spend the session on Python, which Teramind candidates report being tested on.
  • Write one worked example in Python and time yourself on it.

Deliverable: One timed worked example in Python.

03Work Live Coding
  • Spend the session on Live Coding, which Teramind candidates report being tested on.
  • Write one worked example in Live Coding and time yourself on it.

Deliverable: One timed worked example in Live Coding.

04Work React
  • Spend the session on React, which Teramind candidates report being tested on.
  • Write one worked example in React and time yourself on it.

Deliverable: One timed worked example in React.

05Answer out loud: Data Structures & Computer Science Fundamentals
  • Answer aloud, timed: Explain the difference between a stack and a queue, and describe a real-world scenario where you would use each.
  • Answer aloud, timed: How does a Time-To-Live (TTL) cache work, and how would you structure its eviction policy?

Deliverable: Spoken answers to 2 reported Data Structures & Computer Science Fundamentals question(s), under time.

06Answer out loud: Full-Stack & Live Coding
  • Answer aloud, timed: Implement a small end-to-end service with a Node.js backend and a React frontend that fetches, filters, and displays a list of active system processes.
  • Answer aloud, timed: Write a program to download a CSV file from a provided Google Sheets URL, parse the data, and import it into a local database using your preferred language and tools.

Deliverable: Spoken answers to 2 reported Full-Stack & Live Coding question(s), under time.

07Answer out loud: Systems, Scripting & Environment
  • Answer aloud, timed: What Linux commands would you use to find and terminate a process running on a specific port?
  • Answer aloud, timed: How do you optimize Python scripts for handling large, continuous streams of JSON data?

Deliverable: Spoken answers to 2 reported Systems, Scripting & Environment question(s), under time.

Expand any day for tasks and deliverables. Your progress is saved on this device.

Behavioural preparation

Behavioural rounds judge the decision you made and what it cost.

Estimate work you have never done and defend the range

hard
estimationbackfillsexpand-contract

You are asked to estimate a change you have never attempted: add a column to a 100-million-row table, populate it, move reads across, and drop the old shape. Give a range with the assumptions that generate it, including batch size, the signal your backfill throttles on, and wall-clock hours, and name the three unknowns that would move the number most. Then describe a real estimate you gave under comparable ignorance: how you expressed its uncertainty, what you committed to, and how wrong you turned out to be.

Approach
  1. Decompose into independently deployable steps before estimating anything: add the column nullable, write both shapes, backfill in batches, verify, move reads, stop writing the old shape, drop it. That is four deploys spread over days, and the calendar estimate is dominated by them rather than by the loop's runtime.
  2. Do the arithmetic aloud for the part that has arithmetic in it: batch size times number of batches times per-batch duration, at a write rate the primary can absorb alongside roughly 1.2k writes per second of production traffic. The loop is throttled by replication lag and lock waits, not by how fast it can issue statements.
  3. Price the schema step by its lock rather than its statement duration. In PostgreSQL an ALTER TABLE taking ACCESS EXCLUSIVE waits for every open transaction on that table while later queries queue behind it, so a millisecond change issued during a thirty-second analytics query stalls that table for thirty seconds. Adding a nullable column with a non-volatile default avoids a rewrite from version 11; a new index wants CREATE INDEX CONCURRENTLY, which cannot run inside a transaction block and leaves an invalid index behind if it fails.
  4. Express the answer as a range whose endpoints each trace to a stated assumption, then name the cheapest experiment that collapses it, which is almost always running one real batch against the real table and multiplying.
Follow-up
  • How do you verify the backfill genuinely finished, given rows written by production traffic while it ran?
  • Where does the backfill resume from after a worker is killed mid-batch, and what makes that resume point trustworthy?

Reverse your own decision and price the reversal

medium
reversibilitymeasurementmigrations

Describe a technical decision you made and later reversed. Pick one that cost something: a service you split and merged back, a cache you added and removed, an index you created that pushed the planner onto a worse plan, a projection you rebuilt from scratch. State what you believed when you decided, the measurement that changed your mind, how long the wrong version ran in production, and what the reversal cost in migrations, dual writes, and a deprecation window for callers you did not own.

Approach
  1. State the original rationale without irony, in the version you would still defend given what was known then. If it is not defensible, the story is about carelessness rather than judgement, and a different example serves you better.
  2. Give the measurement that moved with a before and after: the p99 that did not improve, the cache hit rate that sat at 40%, the plan that flipped to a sequential scan once the table passed a size you can name.
  3. Cost the reversal in steps, not adjectives: expand-and-contract deploys, the dual-write window, the callers who had to be notified, the rows already written in the wrong shape that had to be backfilled or abandoned.
  4. Distinguish reversal from rewrite by naming what you kept. Most good reversals preserve the schema or the interface and undo one decision inside it, which is also why they were affordable.
Follow-up
  • What in that decision was irreversible, and did you know it was irreversible when you made it?
  • How did you tell the people who had already built on top of the original decision?

Tell callers you do not own that their integration breaks

medium
deprecationcompatibilitystakeholders

A field in a write endpoint's response must change shape. You own the endpoint; you do not own the four internal callers or the outbound webhook consumers who read it. Describe a deprecation you were responsible for: what you shipped first, how you established who was actually reading the field, the window you gave and what set its length, what you did about the consumer who never moved, and how you decided removal was safe. Name the signal you used, not the announcement you sent.

Approach
  1. Establish the reader set empirically rather than from a wiki of owners: per-field usage counters keyed by principal, or access logs attributed to a consumer. State the blind spot of whichever you pick, since a consumer that reads the field only on a monthly job will not appear in a week of logs.
  2. Ship additive first. Populate the new field alongside the old one so no reader is forced to move, which is also what keeps a rolling deploy safe, because old and new instances answer the same requests at the same time and a rollback must still find the old shape present.
  3. Set the window from the slowest legitimate consumer's release cadence, not from your calendar, and decide separately what to do for a consumer with no release process at all, such as an external webhook endpoint you can only email.
  4. Convert silence into evidence before you rely on it: a short, low-traffic removal window that makes a still-dependent consumer fail visibly and loudly while you are watching, rather than at three in the morning after you have moved on.
Follow-up
  • How would you detect a consumer that reads the field only during a monthly export?
  • One caller refuses to move and has a commercial relationship behind it. What changes in your plan and what does not?
  • 01

    You are asked to estimate a change you have never attempted: add a column to a 100-million-row table, populate it, move reads across, and drop the old shape. Give a range with the assumptions that generate it, including batch size, the signal your backfill throttles on, and wall-clock hours, and name the three unknowns that would move the number most. Then describe a real estimate you gave under comparable ignorance: how you expressed its uncertainty, what you committed to, and how wrong you turned out to be.

  • 02

    Describe a technical decision you made and later reversed. Pick one that cost something: a service you split and merged back, a cache you added and removed, an index you created that pushed the planner onto a worse plan, a projection you rebuilt from scratch. State what you believed when you decided, the measurement that changed your mind, how long the wrong version ran in production, and what the reversal cost in migrations, dual writes, and a deprecation window for callers you did not own.

  • 03

    A field in a write endpoint's response must change shape. You own the endpoint; you do not own the four internal callers or the outbound webhook consumers who read it. Describe a deprecation you were responsible for: what you shipped first, how you established who was actually reading the field, the window you gave and what set its length, what you did about the consumer who never moved, and how you decided removal was safe. Name the signal you used, not the announcement you sent.

PracHub preparation framework ↗

Frequently asked questions

What is the company culture like regarding remote work?

Teramind operates as a fully remote company, primarily hiring engineers on a B2B contractor basis. They employ a strict micromanagement and time-tracking paradigm, utilizing their own software to monitor keyboard and mouse activity. You are compensated strictly for tracked, active working hours.

Teramind Software Engineer candidate reports ↗
How difficult are the technical interviews?

The technical interviews are of average difficulty but are highly practical. They focus heavily on your ability to implement working full-stack features, write clean code under time pressure, and demonstrate core computer science definitions.

Teramind Software Engineer candidate reports ↗
Are AI tools allowed during the live coding sessions?

Yes. In many technical rounds, candidates are explicitly encouraged to use AI tools like ChatGPT to assist with coding speed. The interviewers evaluate how effectively you integrate these tools to solve the problem at hand.

Teramind Software Engineer candidate reports ↗
How quickly does Teramind make hiring decisions?

The process is typically very fast, often concluding within 1 to 2 weeks from the initial application. However, because they use strict elimination filters, you can expect to be rejected rapidly if you do not meet their specific technical or operational criteria.

Teramind Software Engineer candidate reports ↗
How hard is the Teramind interview?

Candidates most commonly rate Teramind interviews as medium, based on 36 reported interviews. About 25% of candidates who interview go on to receive an offer.

Teramind Software Engineer candidate reports ↗
What topics does Teramind test in interviews?

Teramind interviews most often cover Full-Stack Development, React, Python, Marketing Analytics, and Sales Metrics (Quota & Attainment). The exact emphasis depends on the specific role you apply for.

Teramind Software Engineer candidate reports ↗
Where is Teramind headquartered?

Teramind is headquartered in Cheyenne, US.

Teramind Software Engineer candidate reports ↗
Sources & methodology 3 sources ↗

Official role evidence, timestamped platform data and clearly labeled preparation advice.

Practice 18 Software Engineer prompts