A Software Engineer at Grady Health System occupies a unique position at the intersection of cutting-edge technology and life-saving healthcare. Unlike traditional tech firms, engineering at Grady is directly tied to the health and well-being of the Atlanta community. Whether you are optimizing Workday Application suites for finance and supply chain or developing internal tools for Professional Billing (PB) and clinical coding, your work ensures that the infrastructure supporting our medical professionals remains robust, secure, and efficient. In this role, you will contribute to a complex ecosystem of integrated platforms that manage everything from patient data to resource allocation. The impact of your work is measured by the seamlessness of clinical workflows and the accuracy of the data that drives institutional decisions. You aren't just writing code; you are building the digital backbone of a Level 1 Trauma Center, where system reliability and data integrity can have a direct influence on patient outcomes and organizational sustainability. The technical environment at Grady is both challenging and rewarding, requiring engineers to navigate high-stakes environments with precision. You will work on diverse problem spaces, such as automating financial reporting, integrating disparate healthcare databases, and ensuring that our Workday environment is tailored to the specific needs of a massive health system.
Recruiter Screen
reportedInitial screening by a recruiter to discuss your background and alignment with the role.
What to demonstrate
- Initial screening by a recruiter to discuss your background and alignment with the role
- Depth in Software Engineering (General)
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.
Technical Assessment
reportedRigorous evaluation of your technical skills and problem-solving abilities through practical scenarios.
What to demonstrate
- Rigorous evaluation of your technical skills and problem-solving abilities through practical scenarios
- Depth in Software Engineering (General)
How to prepare
- Answer aloud and timed: "What is your process for optimizing a slow-running SQL query in a production environment?"
- Answer aloud and timed: "How do you ensure that a third-party API integration remains secure?"
Behavioral Assessment
reportedAssessment of your soft skills and cultural fit through behavioral interview questions.
What to demonstrate
- Assessment of your soft skills and cultural fit through behavioral interview questions
- Depth in Software Engineering (General)
How to prepare
- Prepare three examples from your own work, each with a decision you made and an outcome you can quantify.
- Re-read the description of the behavioral assessment above and write down what you would ask to confirm before it.
Final Panel
reportedFinal interview with multiple stakeholders to evaluate your overall fit for the team and organization.
What to demonstrate
- Final interview with multiple stakeholders to evaluate your overall fit for the team and organization
- Depth in Software Engineering (General)
How to prepare
- Answer aloud and timed: "Give an example of a time you disagreed with a teammate's technical approach. How did you resolve it?"
- Answer aloud and timed: "Describe a project where you had to manage competing priorities with tight deadlines."
PracHub editorial advice for the preparation topics above.
Be Honest
As noted by previous candidates, do not lie about your experience. If you don't know a specific technology, explain how you would go about learning it. Grady values integrity over a perfect (but potentially inaccurate) resume.
Understand the Mission
Take the time to learn about Grady's role in the Atlanta community. Showing that you care about the hospital's impact will set you apart from candidates who only care about the code.
Use the STAR Method
When answering behavioral questions, structure your responses using the Situation, Task, Action, and Result framework. This ensures your answers are concise and highlight your specific contributions.
Prepare a few questions for your interviewers about the future of Grady’s tech stack
It shows you are thinking about the long-term success of the organization.
Choose a category, try a prompt, then open its approach, worked solution or follow-up when you need it.
Track a rolling failure rate per destination for circuit decisions
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?
Merge partitioned event streams into one ordered feed with bounded lateness
The read-model service consumes 64 log partitions carrying about 4,000 events per second in total. Each partition is ordered within itself, but partitions drift by up to 30 seconds, and the activity feed must present a tenant's events in occurred_at order. Produce the merge. State its complexity, the buffer it requires in events and in bytes, what happens when one partition is idle, and what you do with an event that arrives after you have already emitted its position. Payloads average 1 KB.
Approach
- Merge with a min-heap over the 64 partition heads keyed on (occurred_at, event_id): O(log P) per event and O(n log P) overall. The tie-break on event_id is what makes the output deterministic when two partitions carry the same millisecond, which matters because the feed is paginated and a non-deterministic order reorders pages under the reader.
- Emitting the heap head is only correct once every partition has produced everything up to that timestamp, so the emit condition is a watermark: the minimum across partitions of the highest occurred_at seen, less the allowed lateness. Events are held until the watermark passes them, which is what turns individually ordered streams into a jointly ordered one.
- Size the buffer from the lateness rather than guessing: 4,000 events per second times 30 seconds is 120,000 buffered events, and at 1 KB each about 120 MB of heap. That number is the real price of the ordering guarantee and belongs in front of whoever asked for it.
- Handle the idle partition explicitly, because it fails the feed rather than corrupting it: a partition with no traffic never advances its own maximum, so the watermark freezes and output stops entirely. Either every partition emits a periodic idle marker carrying the broker's current time, or the watermark falls back to wall clock for a partition silent beyond a threshold.
Follow-up
- The lateness budget is raised to five minutes. What is the new buffer, and what besides memory changes?
- The consumer restarts. Where does it resume from, and what does the feed look like for the first 30 seconds?
Canonicalise a request body into a stable idempotency fingerprint
idempotency_key.request_fingerprint is a SHA-256 over the method, path and canonicalised body, and a retry whose fingerprint differs must be rejected with 422 rather than served the stored response. Write the canonicaliser. Bodies are JSON up to 256 KB nested at most 32 levels; clients vary key order, whitespace and unicode escaping, and some send 64-bit ids as JSON numbers. Produce a deterministic byte string such that semantically identical bodies match and any semantic difference does not. State your complexity and name two normalisations you refuse to perform.
Approach
- Parse once into a tree, then re-serialise under fixed rules: object keys sorted, array order preserved, one escaping convention, no insignificant whitespace. Parsing is O(n) and sorting keys is O(k log k) per object, so O(n log n) overall with O(depth) stack, and the 32-level cap is enforced during parsing because hostile nesting is how a canonicaliser becomes a stack overflow.
- Sort keys by their UTF-8 bytes and say why the obvious implementation is wrong in some runtimes: a default string comparison that orders by UTF-16 code units places surrogate pairs, meaning code points from U+10000 up, below U+E000 to U+FFFF, which is not UTF-8 byte order, so two services written in different languages disagree on the same document.
- Do not re-encode numbers through a double. IEEE-754 binary64 represents integers exactly only up to 2^53, so normalising a 19-digit id through a float changes it, and 1 against 1.0 cannot be reconciled without deciding whether they are the same value. Preserve the literal token, and require ids as strings at the API boundary if you want them comparable.
- Reject duplicate keys rather than picking one. JSON permits them and parsers disagree, most keeping the last, so any choice you make ties the fingerprint to a parser detail that the code handling the request does not necessarily share.
Follow-up
- A client sends the same logical request with an extra field your API ignores. Same key, different fingerprint, so you return 422. Is that the right answer?
- Where does the fingerprint get computed relative to request decompression and the body-size limit?
"What is your process for optimizing a slow-running SQL query in a production environment?"
"What is your process for optimizing a slow-running SQL query in a production environment?"
Approach
- Name the grain you start from and join outward from it.
- Check whether any join is one-to-many before aggregating, or the sums inflate.
- Say which index the query would use, and what makes it unusable.
- Handle the rows that do not match: that is usually the actual question.
Follow-up
- How does the query change if that join becomes one-to-many?
- What happens to this when the table is ten times larger?
Explain why the owner filter ignores the listing index
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?
"Explain the difference between a calculated field and a core connector in an ERP context."
"Explain the difference between a calculated field and a core connector in an ERP context."
Approach
- Clarify what is being asked and what a complete answer contains.
- State your assumptions explicitly before working the problem.
- Say what you would check first and why it is the highest-information step.
- Work from the requirement backwards to the design.
Follow-up
- What assumption would you test first?
- How would you know your answer was wrong?
"How do you ensure that a third-party API integration remains secure?"
"How do you ensure that a third-party API integration remains secure?"
Approach
- Say who the caller is and what they do when the call fails halfway.
- Define the identity of a request so a retry cannot double-apply it.
- Separate accepted, pending, failed and confirmed; they are different facts.
- Design the error taxonomy before the success shape; callers branch on it.
Follow-up
- What happens if the caller retries after a timeout?
- How does a client discover it is on an old version of this contract?
Read latency spikes on a sixty-second sawtooth
The cached listing read path serves about 14k reads/second at an 85% hit rate. p99 sits at 35 ms for 57 seconds, jumps to 900 ms for 3, and repeats. During each spike the primary shows several hundred identical listing queries starting within the same millisecond, all carrying one large tenant's id. Cache entries use a 60-second TTL. Give the mechanism, the ordered checks, the fix, and the correctness hazard your fix must not introduce.
Approach
- Match the period to a configured number before theorising about load. A spike every 60 seconds against a 60-second TTL is an entry expiring, and you confirm it by correlating spike timestamps with the entry's write time rather than with the traffic curve. If the period had matched a cron or a GC interval instead, this is a different investigation.
- Establish the concurrency of the miss. Several hundred identical queries in one millisecond means the miss path has no coalescing: every request that arrives between expiry and repopulation recomputes. The herd size is that key's arrival rate times its recompute time, so at 1.2k reads/second for the hot key and a 250 ms recompute you expect about 300 concurrent misses, which matches what is observed.
- Add single-flight on the miss path so one caller per key recomputes under a short-lived lock while the rest wait for its result. Prefer stale-while-revalidate where the read tolerates it: return the expired value immediately and refresh asynchronously, which removes the latency spike rather than serialising it into a queue of waiters.
- De-synchronise the keys. Write TTLs with jitter, for example 60 seconds plus or minus 10%, so a deploy or a mass invalidation does not align every key on the same second and turn a per-key herd into a fleet-wide one.
Follow-up
- The same sawtooth appears on a key that is invalidated on write rather than expired. Is that the same bug?
- How does your answer change if the recompute takes 4 seconds instead of 250 ms?
Built from the rounds and topics Grady Health System candidates report.
Prepare, practise & reflect
One practical outcome each day. Spend longer where you need it.
0 / 7 done01Map the Grady Health System loop
- Write out the reported sequence: Recruiter Screen, Technical Assessment, Behavioral Assessment, Final Panel.
- 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 Software Engineering (General)
- Spend the session on Software Engineering (General), which Grady Health System candidates report being tested on.
- Write one worked example in Software Engineering (General) and time yourself on it.
Deliverable: One timed worked example in Software Engineering (General).
03Work Coding / Programming Ability
- Spend the session on Coding / Programming Ability, which Grady Health System candidates report being tested on.
- Write one worked example in Coding / Programming Ability and time yourself on it.
Deliverable: One timed worked example in Coding / Programming Ability.
04Work Application Management
- Spend the session on Application Management, which Grady Health System candidates report being tested on.
- Write one worked example in Application Management and time yourself on it.
Deliverable: One timed worked example in Application Management.
05Answer out loud: Technical & Domain Expertise
- Answer aloud, timed: "How do you handle data transformations when moving information between a legacy system and Workday?"
- Answer aloud, timed: "Explain the difference between a calculated field and a core connector in an ERP context."
Deliverable: Spoken answers to 2 reported Technical & Domain Expertise question(s), under time.
06Answer out loud: Behavioral & Situational
- Answer aloud, timed: "Tell me about a time you had to explain a technical limitation to a frustrated business user."
- Answer aloud, timed: "Describe a situation where you had to learn a new technology very quickly to solve a critical problem."
Deliverable: Spoken answers to 2 reported Behavioral & Situational question(s), under time.
07Answer out loud: Mission & Values
- Answer aloud, timed: "Why do you want to work in healthcare IT specifically at Grady Health System?"
- Answer aloud, timed: "How do you maintain focus on quality and accuracy when working on repetitive or highly detailed tasks?"
Deliverable: Spoken answers to 2 reported Mission & Values question(s), under time.
Expand any day for tasks and deliverables. Your progress is saved on this device.
Behavioural rounds judge the decision you made and what it cost.
"How do you handle data transformations when moving information between a legacy system and Workday?"
"How do you handle data transformations when moving information between a legacy system and Workday?"
Approach
- Pick a story where you made the decision, not one where you watched it.
- State the situation in two sentences and spend the rest on the reasoning.
- Give the blast radius: what could have broken, and what you measured.
- Name the disagreement and how you resolved it with evidence.
Follow-up
- What would you do differently if you ran that again?
- How did you know your change caused the improvement?
"Tell me about a time you had to explain a technical limitation to a frustrated business user."
"Tell me about a time you had to explain a technical limitation to a frustrated business user."
Approach
- Pick a story where you made the decision, not one where you watched it.
- State the situation in two sentences and spend the rest on the reasoning.
- Give the blast radius: what could have broken, and what you measured.
- Name the disagreement and how you resolved it with evidence.
Follow-up
- What would you do differently if you ran that again?
- How did you know your change caused the improvement?
"Describe a situation where you had to learn a new technology very quickly to solve a critical problem."
"Describe a situation where you had to learn a new technology very quickly to solve a critical problem."
Approach
- Pick a story where you made the decision, not one where you watched it.
- State the situation in two sentences and spend the rest on the reasoning.
- Give the blast radius: what could have broken, and what you measured.
- Name the disagreement and how you resolved it with evidence.
Follow-up
- What would you do differently if you ran that again?
- How did you know your change caused the improvement?
"Give an example of a time you disagreed with a teammate's technical approach. How did you resolve it?"
"Give an example of a time you disagreed with a teammate's technical approach. How did you resolve it?"
Approach
- Pick a story where you made the decision, not one where you watched it.
- State the situation in two sentences and spend the rest on the reasoning.
- Give the blast radius: what could have broken, and what you measured.
- Name the disagreement and how you resolved it with evidence.
Follow-up
- What would you do differently if you ran that again?
- How did you know your change caused the improvement?
"Describe a project where you had to manage competing priorities with tight deadlines."
"Describe a project where you had to manage competing priorities with tight deadlines."
Approach
- Pick a story where you made the decision, not one where you watched it.
- State the situation in two sentences and spend the rest on the reasoning.
- Give the blast radius: what could have broken, and what you measured.
- Name the disagreement and how you resolved it with evidence.
Follow-up
- What would you do differently if you ran that again?
- How did you know your change caused the improvement?
"Why do you want to work in healthcare IT specifically at Grady Health System?"
"Why do you want to work in healthcare IT specifically at Grady Health System?"
Approach
- Pick a story where you made the decision, not one where you watched it.
- State the situation in two sentences and spend the rest on the reasoning.
- Give the blast radius: what could have broken, and what you measured.
- Name the disagreement and how you resolved it with evidence.
Follow-up
- What would you do differently if you ran that again?
- How did you know your change caused the improvement?
"How do you maintain focus on quality and accuracy when working on repetitive or highly detailed tasks?"
"How do you maintain focus on quality and accuracy when working on repetitive or highly detailed tasks?"
Approach
- Pick a story where you made the decision, not one where you watched it.
- State the situation in two sentences and spend the rest on the reasoning.
- Give the blast radius: what could have broken, and what you measured.
- Name the disagreement and how you resolved it with evidence.
Follow-up
- What would you do differently if you ran that again?
- How did you know your change caused the improvement?
"What does 'integrity' mean to you in the context of software engineering?"
"What does 'integrity' mean to you in the context of software engineering?"
Approach
- Pick a story where you made the decision, not one where you watched it.
- State the situation in two sentences and spend the rest on the reasoning.
- Give the blast radius: what could have broken, and what you measured.
- Name the disagreement and how you resolved it with evidence.
Follow-up
- What would you do differently if you ran that again?
- How did you know your change caused the improvement?
- 01
"How do you handle data transformations when moving information between a legacy system and Workday?"
- 02
"Tell me about a time you had to explain a technical limitation to a frustrated business user."
- 03
"Describe a situation where you had to learn a new technology very quickly to solve a critical problem."
- 04
"Give an example of a time you disagreed with a teammate's technical approach. How did you resolve it?"
How difficult is the interview process for Software Engineers?
The process is moderately rigorous, focusing more on applied knowledge and situational judgment than on abstract algorithm challenges. If you know your tech stack and can explain your past projects clearly, you will find the process very manageable.
Grady Health System Software Engineer candidate reports ↗What is the culture like for the engineering team at Grady?
The culture is collaborative, mission-driven, and stable. Engineers at Grady take great pride in knowing their work supports a vital community institution, and there is a strong emphasis on work-life balance and long-term career growth.
Grady Health System Software Engineer candidate reports ↗Are there remote work opportunities for Software Engineers?
Yes, several roles, particularly those in Workday Application Management, offer remote or hybrid options. However, some positions may require an on-site presence at our Atlanta, GA headquarters depending on the specific team needs.
Grady Health System Software Engineer candidate reports ↗How long does it take to hear back after the final interview?
Typically, the hiring team reaches a decision within one to two weeks following the final panel. We strive to keep candidates informed at every stage of the process.
Grady Health System Software Engineer candidate reports ↗What topics does Grady Health System test in interviews?
Grady Health System interviews most often cover Problem Solving, Root Cause Analysis, Stakeholder Management, Statistical Analysis, and Requirements Gathering. The exact emphasis depends on the specific role you apply for.
Grady Health System Software Engineer candidate reports ↗Sources & methodology 3 sources ↗
No official company page is cited. Rounds and questions come from candidate reports and PracHub editorial material; each source shows the date it was read.
- 01Grady Health System Software Engineer candidate reports ↗
Company-reported rounds, questions and FAQ.
Candidate reports · Accessed 2026-09-22 - 02PracHub Software Engineer practice ↗
PracHub practice material, not company-reported.
PracHub page · Accessed 2026-09-22 - 03PracHub preparation framework ↗
PracHub preparation guidance.
PracHub page · Accessed 2026-09-22
Explore related engineering environments and compare the preparation focus.
Cognition Software Engineer Interview Guide
What Cognition asks Software Engineer candidates, from reported rounds and questions.
YES Software Engineer Interview Guide
What YES asks Software Engineer candidates, from reported rounds and questions.
ValueLabs Software Engineer Interview Guide
What ValueLabs asks Software Engineer candidates, from reported rounds and questions.
Viber Software Engineer Interview Guide
What Viber asks Software Engineer candidates, from reported rounds and questions.