BB&T Software Engineer Interview Guide

The 60-second brief

BB&T is a bank, and candidates describe the Software Engineer role as building and maintaining the technology behind its financial services. Reported work includes writing code, designing systems that move transactions reliably, and building online banking applications and financial technology integrations. The role sits in cross-functional teams, so day-to-day work mixes development with requirements gathering, code review and fixing live issues. The stack candidates mention is C#, Java, JavaScript and Python, with Agile practice, Git, Docker, Kubernetes, CI/CD pipelines and, as a bonus, AWS or Azure.

This guide is for engineers applying to BB&T as a Software Engineer, typically with a few years of development experience in at least one mainstream language. It covers the four reported stages, the fourteen questions candidates report (coding, REST and security, object-oriented versus functional programming, debugging, design, estimation and behavioral), and the operating-system topics that candidate reports also tag: Linux, Windows and system administration.

Candidates report four stages over roughly three to five weeks: an Initial Screening, a Technical Assessment, Behavioral Interviews and Onsite Interviews. Reports describe the process as varying a little by team and location.

Focus areas

• Linux
• Technical Interview (Phone/Onsite)
• Windows Operating System

Overview

The reported loop starts with a recruiter conversation, moves to coding assessments, then to behavioral interviews, and ends onsite with team members and hiring managers. The questions candidates report fall into four groups: technical explanations (object-oriented versus functional programming, REST design, application security, cloud experience), problem-solving cases (production debugging, designing from requirements, estimating timelines), behavioral stories, and three short coding problems: reverse a string in Python, implement binary search, and find two numbers that add up to a target.

Those coding problems are small, which changes how you prepare. The goal is not a rare algorithm but clean, correct code you can write and test aloud in your chosen language: handle empty input, state the complexity, and explain why you picked the data structure. Pick one of the languages the role lists (C#, Java, JavaScript or Python) and do all practice in it so syntax never costs you attention.

Candidate reports also tag Linux, Windows, system administration and operating-system fundamentals as topics, and one tip warns that some technical questions may not map to the job description. Treat that as a reason to refresh basics you may not use daily: processes and threads, file permissions, reading logs, services on both Linux and Windows. These topics are reported as tags, not tied to a particular stage, so keep them as a background layer rather than the centre of your plan.

The behavioral half carries real weight: three of the reported behavioral prompts, plus the code-optimization and cloud-experience questions, all reward a story where you made a decision and can show a result. Build a bank of five stories (an optimization, a hard project, a team conflict, a technical decision you argued for, and a cloud or deployment experience) and rehearse them aloud in first person.

The BB&T interview process

These are the four stages candidates report, in the order they report them. Treat the descriptions as a guide to what to prepare, since the process may differ slightly by team or location.

Initial Screening

Candidates report that the Initial Screening is run by a recruiter and checks your qualifications and fit for the role. Treat it as the first impression of your whole story: a clear CV walk-through, the languages and tools you have actually used, and a reason you want this role at a bank. It is also the moment to ask which language the team uses and what the Technical Assessment will look like.

What to demonstrate

• Whether your background matches the requirements candidates describe: a few years of development, one major language, Agile experience
• Clarity when you summarise your own experience
• Fit for the role as a recruiter reads it

How to prepare

• Write a short CV walk-through that names your strongest language among C#, Java, JavaScript and Python and one project in it
• List where you meet the stack candidates mention (Git, CI/CD, Docker, Kubernetes, AWS or Azure) and where you do not, so you can answer honestly
• Prepare two or three questions about the team, the language it uses and the next stage

Technical Assessment

The Technical Assessment is reported to include coding assessments that test technical expertise. The coding problems candidates report are reverse a string in Python, binary search, and finding two numbers that sum to a target, so expect this stage to be where coding practice pays off. Write working code, say its complexity, and test it on edge cases before you are asked to.

What to demonstrate

• Working code for a short problem in a language you are fluent in
• Whether you can state time and space complexity and justify a data structure
• Handling of edge cases such as empty input, one element and duplicates

How to prepare

• Write the string reversal, binary search and two-sum solutions from memory in one language, each with three tests including an edge case
• Practise narrating a solution: brute force, then the improvement, then the complexity
• Refresh operating-system basics that reports tag (Linux, Windows, system administration): processes, permissions, reading logs

Behavioral Interviews

Candidates report Behavioral Interviews focused on collaboration and alignment with BB&T's values. Reported prompts include a significant project challenge, handling team conflict, and advocating for a technical decision. Answer with stories in which you made the call and can name the result, and keep technical detail high enough to show what you actually did.

What to demonstrate

• Collaboration, as shown by how you describe working with teammates and disagreeing with them
• Communication of technical choices in plain terms
• How you describe the outcome and what you would change

How to prepare

• Write STAR notes for five stories: optimization, significant challenge, team conflict, advocating a technical decision, cloud experience
• Replace every "we" in your drafts with the specific thing you did, and add a measured or observable result
• Rehearse each story aloud so the situation takes two sentences and the rest is reasoning and result

Onsite Interviews

The Onsite Interviews are reported as conversations with team members and hiring managers that further assess fit. Reported question types that suit this kind of conversation include designing a solution from user requirements, estimating timelines and resources, and debugging a live production issue, so practise explaining these out loud as well as reasoning through them privately.

What to demonstrate

• Fit with the team members and hiring managers you meet
• Reasoning you can explain out loud on design and estimation
• Practical engineering habits: Agile, code review, version control

How to prepare

• Practise the design-from-requirements question: ask who the callers are, define the data and failure behavior, then name the trade-offs
• Outline an estimation method you actually use: break down tasks, size them, add risk, and revisit as work lands
• Prepare questions for team members about code review, release flow and how the team handles production issues

Where candidates lose points

Writing the string reversal as a loop with no edge-case thinking

Say you could use slicing, s[::-1], then show the in-place two-pointer swap on a list of characters. State O(n) time, O(n) extra for a Python string because strings are immutable, and test the empty string, one character and a palindrome.

Binary search with an off-by-one error or an infinite loop

Fix the invariant before you code (lo and hi inclusive, loop while lo <= hi), use mid = lo + (hi - lo) // 2, and move lo to mid + 1 or hi to mid - 1. Test with zero, one and two elements, a missing target and duplicates.

Giving only the nested-loop answer to the two-number target problem

Name the O(n^2) brute force, then one pass with a hash map from value to index, checking target - x before inserting x so you never reuse the same element. Mention sorting plus two pointers as the O(1)-space alternative.

Skipping operating-system fundamentals because the role is software

Candidate reports tag Linux, Windows, system administration and OS basics. Spend a session on processes versus threads, file permissions, finding a service's logs and the Windows equivalents, so an off-topic question does not freeze you.

Behavioral stories told as "we" with no personal decision and no result

For each story write one sentence that starts with "I decided" and one result you can state, such as a measured speed-up or a shipped release. Say what you would change, and do not overstate cloud or tooling experience you lack.

Questions & practice

Write a function to reverse a string in Python.

Medium · Coding / Algorithms

Approach

1. Give the idiomatic answer first: s[::-1]. Slicing with step -1 builds a new string in O(n) time and O(n) space. Python strings are immutable, so no reversal happens in place. ''.join(reversed(s)) is an equivalent alternative.
2. If asked to do it by hand, convert to a list and swap with two pointers, left from the start and right from the end, until they meet, then ''.join the list. That is O(n) time with O(n) extra space for the list. Avoid building the result with result = c + result in a loop, which copies the string each time and is O(n^2).
3. Mention the recursive version only to reject it: s[-1] + rev(s[:-1]) creates a new slice per call, which is O(n^2), and fails on long inputs because CPython's default recursion limit is about 1000.
4. Cover the edge cases: empty string and single character (both return themselves), and non-string input (raise TypeError or convert, as agreed).
5. Unicode: slicing reverses code points, not what the user sees as characters. It splits combining marks (e followed by U+0301) and multi-code-point emoji (ZWJ sequences, flags). Reversing by grapheme needs a grapheme-aware splitter, such as the third-party regex module's \X.

Follow-up

• How would you reverse the order of words in a sentence but not the letters inside each word?
• Reverse a list of characters in place using O(1) extra space.
• How would you check whether a string is a palindrome, ignoring case and punctuation?

How would you implement a binary search algorithm?

Medium · Coding / Algorithms

Approach

1. State the precondition and cost: the input must be sorted, or more generally the predicate you test must be monotonic. Binary search runs in O(log n) time, with O(1) space when written iteratively.
2. Write it around an invariant: if the target is present, it lies in [lo, hi]. Start with lo = 0 and hi = n - 1. While lo <= hi, take mid = lo + (hi - lo) // 2. Return mid on a match, set lo = mid + 1 if a[mid] < target, otherwise hi = mid - 1. Return -1 when the loop ends.
3. Mention integer overflow in Java and C#: (lo + hi) / 2 can overflow int on large arrays, so use lo + (hi - lo) / 2 (or (lo + hi) >>> 1 in Java). Python ints do not overflow, but the safe form is a good habit.
4. Know the lower-bound variant for duplicates and insertion points: use the half-open range [0, n) and loop while lo < hi, setting hi = mid when a[mid] >= target and lo = mid + 1 otherwise. That returns the first index whose value is >= target. Python's bisect_left and bisect_right implement this, and Java's Arrays.binarySearch returns -(insertion point) - 1 when the key is missing.
5. Test the off-by-one cases: empty array, one element, target below the minimum, target above the maximum, and duplicates. Mention binary search on the answer: finding the smallest value x for which a monotonic condition holds.

Follow-up

• How would you search a sorted array that has been rotated at an unknown pivot?
• Find the first and last positions of a target in a sorted array with duplicates.
• Compute the integer square root of n without a library function.

Given an array of integers, find two numbers that add up to a specific target.

Medium · Coding / Algorithms

Approach

1. Clarify the contract: return indices or values? Is exactly one solution guaranteed? Can the same element be used twice? Are there negatives or duplicates? Is the array sorted? What should be returned when no pair exists?
2. Name the brute force: check every pair with nested loops. That is O(n^2) time and O(1) space, and it works as a baseline.
3. Give the main solution, a one-pass hash map: for each index i with value x, if target - x is already in the map, return [map[target - x], i]; otherwise store map[x] = i. That is O(n) time and O(n) space. Checking before inserting stops an element pairing with itself and still handles [3, 3] with target 6.
4. Offer the sorted alternative: if the input is already sorted, move two pointers inward from both ends (sum too small means move left up, too large means move right down) for O(n) time and O(1) space. If it is unsorted, sorting first costs O(n log n) and you must keep the original indices when the answer needs them.
5. Edge cases: fewer than two elements, no valid pair, negative numbers and zero, and in Java or C# a sum of two large ints overflowing. Comparing target - x avoids the addition, or use long.

Follow-up

• How would you return all unique pairs that add up to the target?
• Extend this to three numbers that sum to the target. What is the complexity?
• How would you solve it if the numbers arrive as a stream too large to keep in memory?

Keep soft-deleted accounts from blocking re-registration

Easy · soft delete · unique constraints · engine differences

app_user holds user_id, tenant_id, email CITEXT, password_hash (NULL for SSO principals), email_verified_at, auth_version, status ('invited','active','suspended','deactivated'), created_at, updated_at, deleted_at. Two live accounts for one address inside a tenant must be impossible, but an address freed by a soft delete must be reusable, and the same tenant may delete and re-register it repeatedly. Write the uniqueness DDL for PostgreSQL 16, then the equivalent for MySQL 8 where partial indexes do not exist, and say what each permits once three deleted rows already hold that address.

Approach

1. Start from what is actually unique: not (tenant_id, email), but (tenant_id, email) among live rows. PostgreSQL says that directly — CREATE UNIQUE INDEX app_user_live_email ON app_user (tenant_id, email) WHERE deleted_at IS NULL. A full constraint over the same two columns burns the address permanently the first time someone deletes an account.
2. Keep case-insensitivity in the type or the index, never in the application: CITEXT as given, or UNIQUE (tenant_id, lower(email)) as an expression index where the extension is unavailable. A case-sensitive unique column is exactly how two accounts for one human appear.
3. For MySQL 8 the predicate has to move inside the key: add a discriminator column that is a constant 0 while the row is live and is set to user_id on delete, with UNIQUE (tenant_id, email, deleted_marker). Live rows share the constant and still collide; deleted rows differ from each other and stop colliding.
4. State the NULL variant and its dependency: leaving the marker NULL for deleted rows also works, because a unique index treats NULLs as distinct — true in MySQL, and true in PostgreSQL only under the default NULLS DISTINCT, which PostgreSQL 15 lets you reverse. Check the polarity against the three existing deleted rows: constant-on-live is what preserves the collision you want, and reversing it silently admits duplicate live accounts.

Follow-up

• A deleted account re-registers with the same address the next day. Do the old resource rows follow the new user_id, and how does the API keep the two principals apart?
• How do you honour an erasure request while resource_revision.actor_user_id still references this table?

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

1. 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.
2. 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.
3. 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.
4. 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 object-oriented and functional programming.

Medium · Technical / Domain Questions

Approach

1. Open with each paradigm's organising idea. Object-oriented code bundles state and the methods that change it into objects, and relies on encapsulation, inheritance and polymorphism through subtype dispatch. Functional code models work as pure functions over immutable values, combined through composition and higher-order functions such as map, filter and reduce.
2. Make state the main contrast. An OO method usually mutates its object's fields. A pure function returns a new value and touches nothing outside itself, so it is referentially transparent: you can test it with plain inputs and outputs, and run it in parallel without locks.
3. Name the extensibility trade-off, known as the expression problem. In OO, adding a new type is easy (one new subclass), but adding a new operation means editing every class. With algebraic data types and pattern matching, adding an operation is easy and adding a variant means editing every function.
4. Ground it in the languages listed for this role. Java and C# are object-oriented but now have lambdas, streams and LINQ, and Python supports both styles. Example: applying interest to accounts can be an Account.applyInterest() method that mutates a balance, or a pure function that maps old account records to new ones.
5. Finish with costs on each side. Immutability allocates new objects, which persistent data structures reduce. Deep inheritance trees become brittle, which is why composition over inheritance is the usual advice. Most production code mixes the two: OO for module boundaries, functional style for data transformations.

Follow-up

• What makes a function pure, and why does that make it easier to unit test?
• How would you make a Java or C# class immutable?
• When would you choose inheritance over composition, and when would you avoid it?

What are the key principles of RESTful API design?

Medium · Technical / Domain Questions

Approach

1. Model resources as nouns with stable URIs (/accounts/{id}/transactions) and let the HTTP method carry the verb. GET is safe and idempotent, PUT and DELETE are idempotent, POST is not, and PATCH is not guaranteed to be idempotent.
2. Keep the server stateless: each request carries its own credentials (for example a bearer token), so any instance can serve it and the service scales horizontally. Make responses cacheable where possible with Cache-Control and ETag, so a client sending If-None-Match gets 304 Not Modified.
3. Use status codes consistently, with a stable error body: 201 Created with a Location header, 204 for an empty success, 400 for bad input, 401 when unauthenticated vs 403 when authenticated but not allowed, 404, 409 for a conflict, 429 when rate limited, and 5xx only for server faults.
4. Cover what real clients need: cursor pagination (stable under inserts, unlike offset), filtering and sorting via query parameters, versioning (/v1 path or a header), and optimistic concurrency with If-Match on the ETag, which returns 412 Precondition Failed on a stale write.
5. For money-moving POSTs, require an Idempotency-Key header. The server stores the key with its first result and returns that same result on a retry, so a timeout followed by a resend cannot transfer twice. Mention HATEOAS as part of Fielding's REST constraints that few APIs implement fully.

Follow-up

• How would you make POST /transfers safe for a client to retry after a timeout?
• What is the difference between PUT and PATCH, and which is idempotent?
• How would you version and retire an endpoint without breaking existing clients?

How do you ensure the security of an application?

Medium · Technical / Domain Questions

Approach

1. Start with a threat model: list the assets (customer data, credentials, money movement), the entry points and the trust boundaries, then walk STRIDE (spoofing, tampering, repudiation, information disclosure, denial of service, elevation of privilege) to find which controls matter most.
2. Authentication and authorization: use MFA and a standard protocol (OAuth 2.0 / OpenID Connect) rather than home-grown auth. Check authorization on the server for every request, including that the caller owns the object id it asks for, which blocks IDOR. Give service accounts least privilege.
3. Input and output handling: use parameterized queries with bind parameters against SQL injection, context-aware output encoding plus a Content Security Policy against XSS, CSRF tokens or SameSite cookies on state-changing requests, and server-side allow-list validation. Client-side checks are only for usability.
4. Data protection: TLS in transit, encryption at rest, and secrets in a vault or secret manager, never in source or config files. Store passwords with a slow, salted hash (bcrypt, scrypt or Argon2), never a fast hash like SHA-256 and never reversible encryption.
5. Make it a process, not a one-off: SAST and dependency (SCA) scanning in CI, security-focused code review, prompt patching, rate limiting, and audit logs that record who did what without logging secrets or full card numbers. Use the OWASP Top 10 as the checklist you test against.

Follow-up

• Why is bcrypt or Argon2 better than SHA-256 for storing passwords?
• How would you stop a user from reading another customer's account by changing an id in the URL?
• How would you learn that a library you depend on has a published vulnerability, and what would you do next?

Given a specific set of user requirements, how would you design a solution?

Medium · Problem-Solving / Case Studies

Approach

1. Clarify before designing. Ask who the users are, which use cases are core, and which non-functional needs apply: expected load, latency, availability, data retention and audit or compliance rules, which matter in banking. Say what is out of scope and read the requirements back to confirm them.
2. Define the API and data model next: the entities, how they relate, and the endpoints or events that operate on them. Choose a relational database when you need ACID transactions and constraints (moving money between accounts) and say what you would give up by choosing otherwise.
3. Outline the components and justify each one: clients, a load balancer, stateless application services, the primary database, a cache for hot reads, and a message queue for slow or retryable work such as notifications. Run a quick back-of-envelope estimate of requests per second and storage to size them.
4. State the trade-offs out loud: synchronous vs asynchronous processing, strong vs eventual consistency per data type (balances strong, analytics can lag), and build vs buy. Then cover the failure modes: what happens when the database or a downstream service is unavailable, plus retries with backoff and idempotency.
5. Close with security (authentication, authorization, encryption), observability (metrics, logs, alerts) and delivery: the smallest version that meets the core requirement first, then iterations driven by user feedback.

Follow-up

• What would you change if traffic grew tenfold?
• Two requirements conflict, for example real-time updates and a strict audit trail. How do you resolve that?
• Which part would you build first, and why?

Describe your methodology for estimating project timelines and resource needs.

Medium · Problem-Solving / Case Studies

Approach

1. Break the work into tasks small enough to estimate, ideally a few days each, and include the non-coding work people forget: testing, code review, security review, deployment, data migration, documentation and coordination with other teams.
2. Give ranges, not single points. One method is three-point estimation: optimistic O, most likely M and pessimistic P, with the PERT expected value (O + 4M + P) / 6. In an Agile team, use relative story points and the team's measured velocity to turn the backlog into a number of sprints.
3. Anchor on history: compare against similar past work and how long it actually took. For real unknowns (a new integration or framework), schedule a time-boxed spike to remove the uncertainty before committing, and list the risks and assumptions next to the estimate.
4. For resources, map tasks to the skills they need, find dependencies and the critical path, and plan for realistic capacity (meetings, on-call, leave), never 100% utilisation. Adding people late adds communication overhead (Brooks's law).
5. Track progress against the estimate (burndown, completed vs planned) and re-forecast as soon as reality diverges. Tell stakeholders early, with options: cut scope, add time or accept a risk.

Follow-up

• Tell me about an estimate that turned out badly wrong. What did you do?
• A stakeholder wants a fixed date for a project with unclear requirements. How do you respond?
• How do you estimate work your team has never done before?

How would you approach debugging a production issue in a live application?

Medium · Problem-Solving / Case Studies

Approach

1. Triage before root cause. Measure the impact (which users, endpoints and regions; error rate and latency), tell the people who need to know, and if the start lines up with a deploy, config change or feature flag, roll it back or turn it off first. Restoring service comes before understanding it.
2. Build a timeline from evidence: dashboards for error rate, p95/p99 latency and saturation, then logs filtered by a request or correlation id, then traces. List everything that changed around the start time: deploys, config, traffic volume, an upstream dependency, data shape.
3. Narrow by comparison. Diff failing against healthy requests by host, version, region and input. If only one host fails, pull it from the load balancer and inspect it. Reproduce in staging with the same inputs, and add targeted logging rather than attaching a debugger to a live process.
4. Check resource causes with OS tools: top or htop for CPU, free for memory, df -h for full disks, dmesg or journalctl for OOM-killer events, ss or netstat for connection counts, and a thread dump (jstack for Java) for deadlocks or an exhausted connection pool. On Windows the equivalents are Event Viewer and Performance Monitor.
5. Ship the fix behind a test that reproduces the bug, confirm on the same metrics that the symptom is gone, then write a blameless postmortem: timeline, root cause, why monitoring did or did not catch it, and action items such as a new alert or guardrail.

Follow-up

• Errors appear on only one of several identical hosts. What do you check next?
• How do you debug an issue you cannot reproduce outside production?
• What belongs in the postmortem, and how do you make sure its action items get done?

Suggested practice checklist

The plan follows the four reported stages: screening, coding, behavioral and onsite, with the OS topics candidate reports tag. It spends two days on the reported coding and technical questions and one on behavioral stories.

Day 1 — Map the loop and choose your language

• Write the four reported stages in order and one line on what you need for each
• Choose one of C#, Java, JavaScript or Python for all coding practice
• List the stack items candidates mention (Agile, Git, Docker, Kubernetes, CI/CD, AWS or Azure) and mark each as strong, partial or none

Deliverable: A one-page loop map, the language you chose, and a gap list for the stack items.

Day 2 — Coding fundamentals

• Write reverse a string, binary search and two-sum from memory in your chosen language
• Add at least three tests per problem, including empty input and duplicates
• Say the time and space complexity of each aloud, including the brute-force version of two-sum

Deliverable: Three working solutions with tests and a written complexity note for each.

Day 3 — Operating-system and system-administration basics

• Write a cheat sheet of processes, threads, file permissions and service logs for Linux and the Windows equivalents
• Practise commands that show running processes, disk use and recent errors on both platforms
• Explain aloud the difference between a process and a thread and what happens on a crash

Deliverable: A one-page OS cheat sheet and a short spoken explanation of processes versus threads.

Day 4 — Technical explanations

• Explain object-oriented versus functional programming with a small example in your language
• Outline a REST API for one resource: URLs, methods, status codes, idempotency and versioning
• Write an application security checklist: input validation, authentication, authorisation, secrets and dependency updates

Deliverable: Three spoken answers, each with a concrete example: the paradigm comparison, a REST resource outline and a security checklist.

Day 5 — Debugging, design and estimation

• Write a production-debugging runbook: what changed, logs and metrics, reproduction, rollback or fix
• Design a solution from a set of user requirements you invent, naming data, failure behavior and trade-offs
• Outline an estimation method for a small feature, with task breakdown, risk buffer and what you would revisit

Deliverable: A debugging runbook, a one-page design and an estimation outline.

Day 6 — Behavioral story bank

• Write STAR notes for five stories: code optimization, cloud experience, significant challenge, team conflict and advocating a technical decision
• Mark the "I decided" sentence and the result in each story
• Rehearse each aloud and cut anything that is not reasoning or result

Deliverable: Five rehearsed STAR stories, each with a personal decision and a stated result.

Day 7 — Data modeling and a full mock run

• Run a spoken mock of the screening pitch, one coding problem and two behavioral stories
• Review where you stumbled and fix the weakest answer

Deliverable: Two completed SQL practice answers and notes from one full mock run.

Behavioural preparation

Candidates report Behavioral Interviews focused on collaboration and alignment with BB&T's values, and the reported prompts cover optimizing code, cloud experience, a significant challenge, team conflict and advocating for a technical decision. For a software engineer, strong answers describe one decision you made, the trade-off, and a result you can state. Keep technical detail concrete and avoid stories where you cannot say what you personally did.

Describe a time when you optimized an existing piece of code. What changes did you make?

Medium · Technical / Domain Questions

Approach

1. Choose a case where you found the slowness yourself and made the change. Open with the symptom in one or two sentences, for example a report that ran too long or an endpoint that timed out.
2. Show you measured before touching anything: a profiler, query plan, timing log or metric gave you a baseline, and you located the hot spot instead of guessing.
3. Name the actual change and why it fit, such as replacing a nested loop with a hash lookup, adding an index, batching calls, caching a repeated result or removing work from a loop. State the complexity or resource change.
4. Prove correctness and result: tests that passed before and after, then the new numbers against the baseline. Mention the cost, for example added memory or harder-to-read code.
5. Close with what you would do differently, such as adding a performance test so the regression cannot return.

Follow-up

• How did you know the change, and not something else, caused the speed-up?
• What trade-off did the optimization introduce, and did you consider leaving the code alone?
• How would you stop the same slowdown from coming back?

What is your experience with cloud services, such as AWS or Azure?

Medium · Technical / Domain Questions

Approach

1. Answer with what you personally did, not a list of service names. Say which cloud you used (AWS, Azure or both), for what workload, and your role: deploying, configuring, debugging or cost-watching.
2. Give one concrete example end to end, for example moving an application to a managed environment, wiring storage or a queue to a service, or setting up a deployment pipeline. Include the choice you made and the reason.
3. Cover security and operations briefly: how access was granted with least privilege, where secrets were kept, how you looked at logs and alerts when something broke.
4. If your experience is on one provider only, say so and map it: compute, object storage, managed database and identity have equivalents on the other, and say what you would verify first. Do not claim hands-on work you have not done.
5. If you have none, describe the nearest thing, such as containers with Docker locally or a CI/CD pipeline, and how you would learn the platform.

Follow-up

• How did you manage permissions and secrets in that setup?
• What went wrong in a deployment, and how did you diagnose it?
• If the team used the other provider, what would you check first on day one?

Tell me about a time you faced a significant challenge in a project. How did you overcome it?

Medium · Behavioral / Leadership

Approach

1. Pick a challenge that was genuinely hard for you: an unclear requirement, a failing release, a technical dead end or a deadline squeeze. State the situation in two sentences with your role and what was at stake.
2. Spend most of the answer on actions in the first person: how you diagnosed the problem, what options you weighed, who you pulled in and what you tried that did not work.
3. Show a decision with a trade-off, not just effort. For instance, you cut scope, added a test harness, or split the work so the team could move in parallel.
4. End with a concrete result and a lesson: what shipped or improved, how you checked it, and what you changed in your process afterwards.
5. Avoid a story where the obstacle was someone else's fault or where the team did everything and you cannot say what you did.

Follow-up

• What would you do differently if you faced it again?
• Who disagreed with your approach, and how did you handle that?
• How did you know the problem was actually fixed?

How do you handle conflicts within your team?

Medium · Behavioral / Leadership

Approach

1. Choose a real disagreement between peers or with a lead, such as a code review dispute, a design choice or unequal workload. State what each side wanted and why both positions had merit.
2. Describe the steps you took: talking to the person directly first, listening for their constraint, then reframing around a shared goal such as the release, the customer or the code quality.
3. Show you used evidence to resolve it, such as a small prototype, a benchmark, a written comparison or an agreed convention, rather than winning on seniority or persistence.
4. Give the outcome and the relationship afterwards: the decision made, whether you compromised, and how you worked together after.
5. Avoid portraying the other person as the problem or claiming you never have conflict.

Follow-up

• What if the other person still disagreed after you showed the evidence?
• Did you ever involve a manager, and when is that the right step?
• What did you change in how you give or take code review feedback afterwards?

Describe a situation where you had to advocate for a technical decision. What was the outcome?

Medium · Behavioral / Leadership

Approach

1. Pick a technical decision with real alternatives: a framework, an architecture, a refactor, a testing approach or a security measure. Say what you wanted, what others wanted and what was at stake if the choice went wrong.
2. Show how you built the case: a comparison of options, a small proof of concept, numbers on risk or effort, and a plain-language summary for non-technical stakeholders.
3. Describe how you listened. Mention the concern you took on board, and any change you made to your proposal because of it.
4. State the outcome honestly, including a case where you lost the argument but still supported the decision. Say what was measured afterwards and whether you were right.
5. Avoid a story that is only persistence; the point is influence through evidence and communication.

Follow-up

• How did you explain the decision to someone non-technical?
• What would you have done if the team had chosen the other option?
• Looking back, were you right, and how do you know?