Interview guides · Allied Benefit Systems

Allied Benefit Systems Software Engineer Interview Guide

Allied Benefit Systems Software Engineer interview guide: reported rounds, C#, ASP.NET/MVC and SQL Server questions, HIPAA prep and a 7-day plan.

The 60-second brief

Allied Benefit Systems works in healthcare administration, and candidates describe its business as delivering insurance and self-insurance solutions. The Software Engineer role covers the development lifecycle on a Microsoft-based stack: keeping older systems running and building newer applications beside them. Candidates describe work organised in Agile sprints with daily scrums, pull requests reviewed with the QA team, and code that has to respect HIPAA and HITECH. Candidates also say the role includes continuing education sessions on HIPAA and related regulations.

This guide is for candidates applying to the Software Engineer role (described as Software Engineer I, with 2 to 4 years of C#, ASP.NET/MVC, Web APIs and SQL Server experience). It covers the four reported rounds, the ten questions candidates report, the legacy technologies named as nice-to-have (VB6, Joget) and the Classic ASP integration topic, and a plan that splits time between stack depth, security and compliance, and behavioral stories.

Candidates report four rounds over roughly 3-5 weeks: Initial Screening, Technical Assessments, Behavioral Discussions and Final Rounds. The process can vary by team.

Focus areas

C#
ASP.NET
Web APIs

Overview

The reported questions describe day-to-day maintenance work more than puzzle solving: refactor legacy code toward SOLID, debug a hard problem in an ASP.NET/MVC application, compare WCF with RESTful APIs, tune SQL Server stored procedures, and describe how TDD fits a CI/CD pipeline. Candidates also report that the emphasis is on practical use of the Microsoft stack rather than algorithm puzzles, so your preparation time belongs in C# design, the request pipeline, and T-SQL performance rather than competitive-programming drills.

Two themes run through the stack topics candidates list. The first is legacy and modern code living side by side: dependency injection for testability, Entity Framework versus stored procedures, and ways to touch VB6 or Classic ASP without destabilising what works. The second is protecting sensitive data: encryption at rest and in transit, keeping personal information out of logs, and adding security checks to QA and TDD cycles. Have a concrete example for each, from your own code or from a small project you build this week.

The behavioral side is tied to Agile delivery. Reported prompts cover working with QA on a bug, changing priorities mid-sprint, explaining a technical constraint to a non-technical stakeholder, staying current on privacy and security regulations, and trading speed against quality. Prepare stories that show your own decisions and results, and rehearse them in the STAR shape so they stay short. Candidates also say communication after interviews can be inconsistent, so keep your own record of who said what and when.

The Allied Benefit Systems interview process

Four stages are reported. Ask the recruiter early how many technical rounds your team runs.

Initial Screening

Candidates describe Initial Screening as an early check on whether you suit the role. Use the recruiter conversation to ask how many technical rounds your team runs, to line up your background against the listed requirements (C#, ASP.NET/MVC, Web APIs, SQL Server, SOLID, OOP, SDLC), and to say plainly which of the nice-to-haves you have touched: Azure or AWS, Joget, VB6, automated tests with QA.

What to demonstrate

Fit for the role at a preliminary level
How your experience lines up with the Microsoft-stack requirements candidates describe
Clarity when you summarise your background and your legacy-system exposure

How to prepare

Write a short summary of your most recent C#/ASP.NET project: what it did, what you owned, and one decision you would defend.
List which of VB6, Classic ASP, Joget, Azure or AWS you have used, and one sentence on how for each, so you can answer without stalling.
Prepare questions for the recruiter about the number of technical rounds and the timeline, and mention other active processes politely.

Technical Assessments

Candidates describe Technical Assessments as a mix of theory questions and hands-on application. The reported technical questions are the best map: SOLID when refactoring legacy code, debugging an ASP.NET/MVC problem, WCF versus RESTful APIs, and SQL Server stored procedure performance. Practise giving each answer as a sequence of concrete steps, and finish with how you would test the change and keep sensitive data safe.

What to demonstrate

Working knowledge of C#, ASP.NET/MVC, Web APIs and SQL Server
Ability to connect theory (SOLID, dependency injection) to practical changes in existing code
A troubleshooting method you can state step by step, including security implications

How to prepare

Take one real legacy class and refactor it on paper toward SOLID, naming each principle you apply and the seam you introduce for testing.
Capture an actual execution plan for a slow stored procedure and list the changes you would make, from missing indexes to parameter handling.
Write a one-page comparison of WCF and a REST Web API for versioning, hosting, tooling and testing effort.

Behavioral Discussions

Candidates describe Behavioral Discussions as a walk through your own stories, where interpersonal skills and fit with the team come across. The reported prompts centre on Agile working: QA collaboration on a bug, changes of priority during a sprint, explaining constraints to non-technical people, staying current on regulations, and balancing speed with code quality. Build each story around a decision you made and its result.

What to demonstrate

Soft skills and team fit, as candidates describe the stage
Collaboration with QA and non-technical stakeholders in an Agile team
Personal contribution to the outcome, shown through STAR-structured answers

How to prepare

Write five STAR stories, one per reported behavioral prompt, each with your action and a concrete result, and say each aloud once.
Pick one story that shows compliance or data-protection thinking, such as catching sensitive data in a log or limiting access to a record.
Check your written stories for plural pronouns and replace them with what you personally decided, built or communicated.

Final Rounds

Candidates describe Final Rounds as deeper technical discussions that may span several conversations. Prepare for deeper technical discussion; the stack topics candidates list are the best things to review. Be ready to explain the reasons behind your choices and what you would test.

What to demonstrate

Depth of technical discussion across the Microsoft stack
Reasoning behind architectural choices, especially around legacy systems
Handling of data integrity and security within the SDLC

How to prepare

Prepare a worked example of when you would choose Entity Framework and when a stored procedure, including transactions, auditing and performance.
Outline a strategy for adding a feature next to a VB6 or Classic ASP component without changing its behaviour, using wrappers, tests and a rollback plan.
Review encryption in transit and at rest, and write a short checklist for keeping PII out of logs, error pages and test data.

Where candidates lose points

Answering the SOLID refactoring question with definitions of the five principles instead of changes made to a real class

Walk through one legacy class: extract an interface, inject the dependency, split responsibilities, and say what test you wrote first. Principles are the label, the change is the answer.

Describing the debugging process as "I would look at the logs" without a sequence for an ASP.NET/MVC problem

State an order: scope the problem and get a failing request, read the application, IIS and Event Log evidence, then bisect the MVC pipeline layer by layer (routing, model binding, filters, controller, service, data access) and inspect the SQL actually sent. Finish with one hypothesis and a regression test alongside the fix.

Tuning stored procedures by guessing at indexes, with no execution plan, statistics or parameter-handling discussion

Begin with the actual plan and measured reads, look for scans, key lookups and implicit conversions, then change one thing and measure again. Prepare an example from your own work or practise on a test database.

Mentioning HIPAA and HITECH by name but giving no code-level practice, such as what you keep out of logs or how you secure data

Prepare four concrete habits: no PII in logs, encryption in transit and at rest, access checks on every record path, and synthetic test data. Attach one real example to each.

Telling behavioral stories in the first person plural so your own role disappears, or skipping the result

Use STAR, say "I decided" and "I built", and end with a result you can state. Keep each story short enough to leave room for follow-up questions.

Questions & practice

Find overlapping job attempts and peak concurrency from lease records

Medium · sweep line · intervals · leases

A day of job_run history yields about 50,000,000 attempt records: (job_run_id, job_type, attempt, started_at, finished_at which is NULL when the worker died, lease_expires_at). Leases expire on a clock, so a job that outran its lease ran twice. Produce (a) every job_run_id whose attempts overlapped in wall-clock time and (b) the peak number of simultaneously running attempts per job_type with the minute it occurred. Target O(n log n). State how you treat a NULL finished_at and what clock skew does to your answer.

Approach

Define the interval before sorting anything: an attempt occupies [started_at, COALESCE(finished_at, lease_expires_at)). finished_at is observed and lease_expires_at is only a promise, so every attempt without a finish contributes an estimate and the whole result is a lower bound on overlap rather than an exact count.
For peak concurrency, sweep: emit 2n endpoints, sort by (timestamp, kind) with ends ordered before starts at equal timestamps, then walk the sequence maintaining a counter per job_type and record each type's maximum with its timestamp. O(n log n) dominated by the sort, O(n) space, or O(1) extra if the sort is external and the walk streams.
For overlap detection, do not compare attempts pairwise. A single global sort by (job_run_id, started_at) gives both the grouping and the order; within a group, keep the maximum end seen so far and report an overlap exactly when the next start is less than that running maximum, which is one linear pass after the sort.
Half-open intervals matter and are easy to get wrong: with closed intervals an attempt ending at the same millisecond another begins reads as concurrency two, and across 50,000,000 records that artefact swamps the real signal.

Follow-up

A handler is not idempotent and you have found 400 overlapping jobs. Which of them actually caused damage, and what would you query to find out?
Peak concurrency for one job_type is 4 against a configured cap of 4. Is the cap working, or is the data hiding attempts that never started?

Track a rolling failure rate per destination for circuit decisions

Easy · sliding window · ring buffer · circuit breaker

The egress service delivers about 1,500 webhooks per second across roughly 40,000 destinations, each call bounded by a 10 second timeout. Maintain, per destination, the failure rate over the trailing 60 seconds so a caller can ask before dispatch whether the circuit should open. Attempts arrive as (destination_id, finished_at_ms, outcome). Requirement: amortised O(1) per attempt, with total memory bounded by the destination count rather than by traffic. Give the structure, its exact memory, and the rule that stops a destination with three attempts from opening a circuit.

Approach

Name the exact-deque version and then reject it as the default. Holding timestamps and advancing a tail pointer past anything older than now minus 60 seconds is a correct two-pointer window at amortised O(1) per attempt, but its memory tracks in-window traffic, so one destination in a retry storm holds hundreds of thousands of entries while thousands of quiet destinations hold none.
Use a ring of 60 one-second buckets per destination, each bucket a pair of counters for attempts and failures. On an attempt, advance the ring by the elapsed whole seconds, zeroing at most min(elapsed, 60) buckets, then increment the head. That is amortised O(1) with a fixed footprint per destination.
State the footprint: 60 buckets times two 4-byte counters is 480 bytes of payload per destination, so 40,000 destinations is roughly 20 to 25 MB with per-entry overhead, bounded by the catalogue rather than by the rate. The cost is granularity, since the oldest bucket ages out in whole seconds, which is far tighter than the decision needs.
Require a minimum sample before the circuit may open. A destination with three attempts and three failures reads as 100 percent and is not evidence; a floor of roughly 20 attempts in the window makes the ratio meaningful, and below that floor use a run of consecutive failures as the trigger instead.

Follow-up

The fleet is 30 instances and each sees roughly a thirtieth of a destination's traffic. Where does the rate actually live, and what does a per-instance answer get wrong?
A destination answers in 9.5 seconds and succeeds. It is not failing but it is consuming your per-destination concurrency. What signal should open the circuit here?

Identify the heaviest tenants in a five-minute window under memory pressure

Medium · top-k · heavy hitters · streaming

The edge service handles about 3,000 requests per second across roughly 50,000 tenants, peaking near 9,000. Expose the 50 heaviest tenants by request count over the trailing five minutes so limits can be tightened before one tenant's backfill starves the fleet. You may not retain five minutes of raw records. Give the exact solution and its memory, then the bounded-memory approximation with its error stated as a formula, and say which you would ship and at what tenant cardinality that choice changes.

Approach

Do the exact version first, because it is affordable at this cardinality: a ring of 300 one-second counters per tenant, advanced lazily, is 1,200 bytes of counters per tenant and roughly 60 to 90 MB for 50,000 tenants with overhead. Carry a running total and subtract the bucket you overwrite so a window read is O(1) rather than 300 adds.
Extract the top 50 with a size-k min-heap over the tenant sums: O(d log k) for d tenants, against O(d log d) to sort them all. Maintaining the heap continuously instead of on query requires a tenant-to-heap-index map, because incrementing a count already inside the heap means sifting from a known position, and without that map you rebuild the heap on every request.
State the approximation precisely rather than gesturing at sketches. Misra-Gries with m counters retains every item whose true count exceeds N/(m+1), and each retained count underestimates the truth by at most N/(m+1). With m = 1,000 and N = 900,000 requests in the window the error is roughly 900 requests, which is fine for spotting a tenant sending 50,000 and useless for ranking two tenants 200 apart.
Say what breaks when the window slides: Misra-Gries and Space-Saving are insert-only and cannot be decremented as records age out. The workable construction is one summary per sub-window, say ten seconds, with 30 summaries merged at query time, and the merged error is the sum of the per-summary errors, so the bound degrades linearly in the number of sub-windows.

Follow-up

The heaviest tenant is heavy because of one export job rather than user traffic. Should the limiter treat those as the same tenant?
Two tenants sit tied at the boundary of the top 50. Does your answer flap, and does the flapping matter?

How do you approach optimizing SQL Server stored procedures for performance?

Medium · Technical & Domain Expertise

Approach

Measure before changing anything. Find the top consumers with Query Store or sys.dm_exec_procedure_stats, then capture the actual execution plan with Include Actual Execution Plan in SSMS, SET STATISTICS XML ON, or Query Store. Use SET STATISTICS IO, TIME ON separately for per-statement logical reads and CPU and elapsed time; it does not produce a plan. Logical reads are the number to drive down.
Read the plan for the usual culprits: scans where a seek is possible; key lookups, fixed with a covering index using INCLUDE columns; implicit conversions such as an nvarchar parameter against a varchar column; and non-SARGable predicates (a function wrapped around a column, a leading-wildcard LIKE, ISNULL(col, ...)).
Handle parameter sniffing. A cached plan built for the first parameter values can be badly wrong for later ones. Options are OPTION (RECOMPILE), OPTIMIZE FOR UNKNOWN or a specific value, or splitting the procedure. A catch-all filter like (@p IS NULL OR col = @p) is better as parameterised dynamic SQL through sp_executesql, never string-concatenated values.
Rewrite row-by-row logic as set-based: replace cursors, WHILE loops and scalar UDFs called per row with joins and window functions. Check temp table versus table variable: before SQL Server 2019, table variables are estimated at one row. Keep statistics current, and don't use NOLOCK as a fix, because dirty reads can return wrong results.
Verify on production-sized data. Compare logical reads and duration before and after, and weigh the write and storage cost of every new index on busy tables. Keep the before/after plans as evidence for the change.

Follow-up

The procedure is fast in SSMS but slow from the application. What could cause that? (Different SET options such as ARITHABORT produce separate cached plans, combined with parameter sniffing.)
When would you decide not to add an index the plan is suggesting?
How would you rewrite a search procedure with eight optional filters so it stays fast for every combination?

Explain why the owner filter ignores the listing index

Medium · composite index · query plans · sort elimination

The only index on resource is (tenant_id, status, updated_at DESC, resource_id DESC). A new endpoint returns one user's resources across all statuses, newest created first: WHERE tenant_id = $1 AND owner_user_id = $2 ORDER BY created_at DESC LIMIT 20. On a tenant with 2M rows it takes 900 ms and EXPLAIN shows a sort above a large scan. Explain precisely why the existing index cannot serve it, give the index that can, and state which of these the new index still will not help: owner_user_id alone across tenants; the same query ordered by updated_at. PostgreSQL 16.

Approach

Separate the two jobs an index does. For filtering, a composite btree is seekable only on a left prefix, so with no predicate on status the scan can at best range over tenant_id and test owner_user_id per row; PostgreSQL 16 has no btree skip scan to jump the unconstrained column.
For ordering, the index is sorted by (status, updated_at) within a tenant and not by created_at, so the LIMIT cannot stop early: every matching row is read and then sorted. That is the 'Sort Method: top-N heapsort' line, and it is why the plan reads 2M rows to answer with 20.
Derive the replacement from the access path — equality, equality, then the ordering column: CREATE INDEX CONCURRENTLY ON resource (tenant_id, owner_user_id, created_at DESC). The scan seeks to the (tenant, owner) range and walks 20 entries in order, so the Sort node disappears along with the row-read.
Treat INCLUDE (title, status) as conditional, not free. An index-only scan still visits the heap for any row whose page is not marked all-visible, so on a table taking 1.2k writes/second the win depends on autovacuum keeping the visibility map current, and the wider index costs more on every insert.

Follow-up

90% of rows are status='active'. Would a partial index WHERE status = 'active' change your answer, and for which of the three queries?
A dashboard runs this for 40 owners in one page load. What changes about the design?

How do you ensure SOLID principles are applied when refactoring legacy code?

Medium · Technical & Domain Expertise

Approach

Before touching structure, pin current behaviour with characterization tests: call the legacy method with recorded real inputs and assert today's outputs, even odd ones. Without that safety net, a SOLID refactor is just a rewrite with no way to prove nothing changed.
Apply Single Responsibility by finding the separate reasons a class changes. A controller that validates, queries SQL, applies business rules and formats output gets split with Extract Method and then Extract Class, one small reviewable step at a time.
Use Dependency Inversion to create seams. Put an interface in front of data access and external calls, inject it through the constructor, and register it in the container. ASP.NET Core has one built in; classic MVC wires a container through DependencyResolver. Static calls such as DateTime.Now go behind an injectable abstraction.
Use the other three only where they pay off. Open/Closed: swap a growing switch on type for strategy classes. Liskov: a subclass that throws NotImplementedException means the hierarchy is wrong. Interface Segregation: split fat interfaces so each client depends only on what it calls.
Trade-off: work incrementally (strangler style, small PRs, behaviour unchanged at each step) rather than a big-bang rewrite. Don't add an interface for every class; add one where a test or a real second implementation needs it.

Follow-up

How do you get a sealed class or a static helper with side effects under test without changing its behaviour?
When does applying SOLID become over-engineering, and how do you decide where to stop?
How would you refactor a module with no tests that reads and writes sensitive member data?

What are the key differences between WCF and modern RESTful APIs in terms of maintenance?

Medium · Technical & Domain Expertise

Approach

Contrast the models. WCF is contract-first SOAP (ServiceContract, OperationContract, DataContract, WSDL) with many bindings (basicHttpBinding, wsHttpBinding, netTcpBinding) and WS-* features such as message-level security. REST exposes resources over HTTP verbs, status codes and usually JSON, built with ASP.NET Web API or ASP.NET Core controllers.
Maintenance cost on the WCF side: heavy system.serviceModel configuration, and generated client proxies (svcutil or Add Service Reference) that must be regenerated and redeployed when a contract changes. The full WCF server runtime stays on .NET Framework. Modern .NET has WCF client libraries and CoreWCF, a .NET Foundation project that Microsoft officially supports.
CoreWCF covers only a subset of WCF: some WS-* features and bindings are missing. That gap is what turns a migration into a real maintenance decision, so check which bindings and security features the existing service uses before choosing to port it or replace it.
Maintenance on the REST side: any client with an HTTP library can call it, OpenAPI describes the contract, HTTP caching and status semantics come for free, and it runs on current .NET. The cost is that the contract is looser, so you need explicit validation and contract tests to catch breaking changes.
Versioning and migration: adding optional fields is safe on both sides (DataMember with IsRequired=false in WCF; tolerant readers in REST), while removing or renaming needs a new contract or endpoint. Put a REST facade beside the WCF endpoints, move consumers over one at a time behind contract tests, then retire the old endpoint.

Follow-up

How would you migrate a WCF service that has external consumers you do not control without breaking them?
What do you lose by moving from wsHttpBinding message security to TLS plus bearer tokens, and does that matter for sensitive data?
How do you version a REST API once clients depend on it?

Can you explain your process for debugging a complex issue within an ASP.NET/MVC application?

Medium · Technical & Domain Expertise

Approach

Scope it first: which route or action, which users, which environment, and since when. Then line that up against recent deploys and config changes (web.config transforms, connection strings). Get a failing request with a timestamp or correlation id before forming any theory.
Read the evidence before attaching a debugger. Check application logs for that request, IIS W3C logs (sc-status and time-taken show whether it fails or is slow), and the Windows Event Log for unhandled exceptions or app-pool recycles. Turn customErrors off only in a non-production environment to see the real stack trace.
Walk the MVC pipeline in order to bisect: routing, model binding (inspect ModelState errors), action filters, controller, service layer, data access, view rendering. Reproduce with breakpoints, or attach to w3wp.exe in a test environment, and trace the SQL the action actually issues.
Check the MVC-specific causes by name: .Result or .Wait() on async code deadlocking under the classic ASP.NET SynchronizationContext; session-state locking that serialises concurrent requests from one user; static mutable state shared across requests; Entity Framework lazy loading firing N+1 queries from the view.
Close the loop: write a test that fails on the bug, fix it, and confirm the test passes and the symptom is gone. While debugging, mask or omit any patient or member identifiers you add to logs.

Follow-up

The issue only happens in production and you cannot attach a debugger. What do you do next?
How do you tell whether a slow page is spending its time in SQL Server, in the application code or in view rendering?
How do you add diagnostic logging without writing protected health information to the logs?

Suggested practice checklist

The plan follows the reported loop: stack fundamentals and the four technical questions first, security and compliance next, then behavioral stories, and a full mock at the end. Each day produces something written or spoken that you can review.

Day 1 — Map the loop and your gaps

Write the four reported rounds and the number of technical rounds you will ask the recruiter about.
List each listed requirement (C#, ASP.NET/MVC, Web APIs, SQL Server, SOLID, OOP, SDLC) and rate your confidence, then mark the nice-to-haves you can claim honestly.

Deliverable: A one-page loop map and a requirement checklist with your weakest three topics marked.

Day 2 — SOLID, dependency injection and legacy refactoring

Take a real class from a past project (or a small sample) that mixes responsibilities and refactor it on paper toward SOLID with constructor injection.
Write two unit tests against the refactored class using fakes, and prepare a spoken answer to the SOLID refactoring question.

Deliverable: A before-and-after outline of the refactored class, two test cases, and a recorded spoken answer.

Day 3 — ASP.NET/MVC debugging and WCF versus REST

Write a debugging sequence for a failing MVC request, from routing and model binding through the controller and service to the database call, and name the tool you use at each step.
Make a table comparing WCF and RESTful Web APIs on contracts, hosting, versioning, tooling and maintenance, then answer the comparison question aloud.

Deliverable: A debugging checklist plus a WCF versus REST maintenance table, each rehearsed aloud once.

Day 4 — SQL Server performance and Entity Framework versus stored procedures

Capture the execution plan of a slow query or stored procedure on a test database and list your changes: indexes, predicates, parameter handling, set-based rewrites.

Deliverable: An annotated execution plan with the fixes, and a short decision note on Entity Framework versus stored procedures.

Day 5 — Security, compliance and TDD in CI/CD

Audit a small project for PII in logs and error messages, and write the fixes plus how you would test them.
Write down a pipeline outline (build, unit tests, integration tests, merge gate) and prepare answers to the TDD and regulations questions.

Deliverable: A log-audit list with fixes, a pipeline outline, and spoken answers on TDD with CI/CD and on staying current with regulations.

Day 6 — Behavioral stories in STAR form

Write STAR stories for the QA bug, the sprint priority change, the technical constraint explained to a non-technical person, and speed versus quality.
Say each story aloud, then cut anything that does not show your own decision or the result.

Deliverable: Four STAR stories on one page each, with a result stated in the last line.

Day 7 — Full mock and legacy talking points

Run a mock that mixes two technical questions and two behavioral ones, answering aloud without notes.
Write a short plan for adding a feature next to a VB6 or Classic ASP component, and note two questions to ask, including timeline and follow-up communication.

Deliverable: A recorded mock with notes on what to tighten, a legacy-integration outline, and two written questions to ask.

Agile, QA and compliance stories

Candidates describe the behavioral stage as a review of your stories for soft skills and team fit. The reported prompts focus on Agile teamwork: QA collaboration, shifting sprint priorities, explaining constraints to non-technical people, regulatory awareness and quality under time pressure. Prepare each as a story with your own decision and a result.

Describe your experience with TDD and how you integrate it into a CI/CD pipeline.

Medium · Technical & Domain Expertise

Approach

Describe the loop precisely: write a failing test, make it pass with the simplest code, then refactor while the tests stay green. Name the C# test framework you used (xUnit, NUnit or MSTest) and what you replaced with fakes or mocks.
Explain how dependency injection makes this possible: services take repositories and clocks as interfaces, so unit tests need no SQL Server. Keep a smaller set of integration tests against a real database for stored procedures and mappings.
Place the tests in the pipeline: build, then unit tests and fast integration tests as required checks on every pull request, with a failing check blocking the merge. If slower integration tests run after merge, say that a failure blocks promotion to the next environment or release, not the merge itself. Say which stage catches which kind of defect.
Cover legacy code: with no seams, write characterization tests that pin current behaviour before refactoring. Use synthetic data in fixtures, never real member records, and include a security test such as an authorization check or a log-scrubbing assertion.
Be honest about limits: say where TDD is not worth it (throwaway scripts, layout tweaks) and what you do there instead.

Follow-up

The test suite became too slow and developers skip it. What do you change?
How do you test a stored procedure or an Entity Framework query?
What do you do about a flaky test that blocks the pipeline?