Avensys Consulting UK Software Engineer Interview Guide

The 60-second brief

Candidates describe Avensys Consulting UK as a consulting firm that supplies both people and delivery to its clients. A Software Engineer may work on the firm's own development projects or be placed on a client project. That work mixes general software development, architecture, and platform-specific work such as Pega. Day to day, the role reportedly means turning client requirements into specifications and working code across the whole lifecycle, from design through debugging to delivery. You work alongside project managers and other engineers, and you sometimes write presentations or documents that explain technical choices to people who are not engineers.

This guide is for Software Engineer candidates at Avensys Consulting UK, from trainee to experienced hires. Candidates report that the questions change with seniority, but the topics stay the same. It covers the Java and C fundamentals listed as must-have skills, object-oriented design, complexity analysis, array and string coding problems, high-level architecture explanations, Pega (reported as a nice-to-have), and the behavioural side of a client-facing consulting role. That includes presenting your own project history.

Candidates report that technical aptitude is checked first, through screening calls and a technical assessment that can be live coding or an assignment set before the interview. Behavioural interviews with project managers or hiring leads follow. No fixed number of rounds has been reported.

Focus areas

• Technical and Domain Knowledge
• Software Engineer fundamentals
• Working through problems out loud

Overview

All five reported questions ask you to explain something you know or have done: your Pega experience, your Java and C background, how you show OOP understanding, how you approach a high-level architecture, and how you state the Big O cost of your own solution. Reciting definitions will not answer any of them. Each answer needs a concrete project, a piece of code you can write on the spot, or a complexity you can derive line by line. Prepare every topic as a short spoken explanation backed by an example you can defend if someone asks follow-up questions.

On the coding side, candidates name arrays, string manipulation and pattern-finding problems. The examples they give are "Find the first repeating element in an array" and "Optimize a given algorithm for both time and space complexity." Both test whether you can move from a brute-force solution to a better one and give the time and space cost at each step. Practise in Java or C without relying on IDE autocomplete. Candidates say the technical stage may be live coding and that you should have your own environment ready if it is remote.

The language fundamentals candidates mention are Java and C syntax and memory management. That makes the contrast between them a likely deep-dive area: manual allocation and pointers in C, garbage collection and references in Java. Pega appears as a nice-to-have. If you list it, be ready to talk about how case types, rules and flows work. If you don't, be ready to explain what it is and how your experience carries over.

Because the role can mean working on client sites, the behavioural stage reportedly looks at how you present your skills and past projects, including the reasons behind your technical choices. Candidates say a structured walkthrough or short presentation of your project history is worth preparing, and that STAR is the expected way to structure behavioural answers. Build two or three project stories that each cover a technical decision, a stakeholder you had to explain it to, and a result you can measure.

Where to focus your preparation

Candidates report the overall shape of the process (screening, technical assessment, then behavioural interviews) but no fixed sequence of rounds. This guide treats it as a single preparation focus that covers all three stages.

Preparation focus

Candidates report three stages. First come screening calls. Next is a technical assessment, which can be live coding or an assignment set before the interview and covers core programming, OOP, complexity analysis and familiarity with Java, C or Pega. Last are behavioural interviews with project managers or hiring leads, where you present your experience and your projects. Ask the recruiter whether the technical stage is live or take-home, which language you may use, and whether your project walkthrough should be spoken or a short slide deck. Then prepare each stage separately. For the technical stage, solve array and string problems aloud in Java or C and state their Big O. For the knowledge questions, have a two-minute answer and one code example for each. For the behavioural stage, have STAR stories built from the projects on your CV.

What to demonstrate

• Working code for array and string problems in Java or C, plus a correct time and space analysis
• Command of OOP and of Java and C fundamentals, including memory management
• Ability to give a high-level architecture overview and justify the technical choices in your own projects
• Clear communication of your experience and project history in the behavioural interviews

How to prepare

• Solve "Find the first repeating element in an array" three ways (nested loops, sorting index pairs, one pass with a HashSet) and say the time and space cost of each
• Write a small Java class hierarchy that uses an interface, encapsulated state and runtime polymorphism, and explain it in under two minutes
• Draw a component diagram of one project from your CV, and practise walking one request through it plus explaining it to a non-technical listener
• Set up javac and gcc so you can compile and run code from a plain editor, in case the live coding stage has no IDE

Where candidates lose points

Giving only the time complexity, or saying 'O(1)' for a hash lookup without noting it is an average, when asked to explain your solution's Big O

Practise saying both costs for every solution: time, then extra space, including the recursion stack. Add the qualifier for hash structures (average O(1), worse under collisions) and for amortised operations such as ArrayList.add. When you optimise, say exactly which cost you traded for which.

Coding the first-repeating-element problem without fixing what 'first' means, then returning the wrong element on a case like [3, 1, 2, 1, 3]

Before coding, say both readings out loud: the earliest second occurrence (scan left to right, answer 1) or the earliest first occurrence (scan right to left, answer 3). Pick one, then test it on an array with no repeat, an array of one element, and an array where every element repeats.

Answering the OOP question with textbook definitions of the four principles and no code

Have a small Java example you can write from memory (an interface, two implementations, encapsulated state, a polymorphic call). Have one design decision from your own project where you chose composition or an interface over inheritance, and why.

Overstating Pega or C experience on the CV and then being unable to discuss rule resolution, case types, or pointer and memory bugs

For every technology on your CV, prepare one concrete thing you built and one technical detail you could explain in depth. If your Pega knowledge comes from study rather than projects, say so plainly and show what you learned and how your Java and workflow experience carries over.

Giving the architecture overview as a list of buzzwords, or being unable to explain why a past project used the stack it did

For one project on your CV, write down the components, one request's path through them, and the reason behind each major choice, including the alternative you rejected. Practise a technical version and a two-sentence version for a project manager or client.

Questions & practice

Can you explain the time and space complexity of your solution using Big O notation?

Medium · Technical and Domain Knowledge

Approach

1. Derive the bound from the code instead of quoting it. Name n (and m if there are two inputs), count how many times the innermost operation runs, and drop constants and lower-order terms. Two nested loops over the same array are O(n^2). A loop that halves its range each time is O(log n). Sorting first costs O(n log n), which outweighs any linear pass after it.
2. Give time and space separately, and say whether space means extra (auxiliary) space or includes the input. Count the recursion stack: a recursive traversal of a skewed tree uses O(n) stack even if you allocate nothing else.
3. Use "Find the first repeating element in an array" as a ladder: nested loops are O(n^2) time and O(1) space; sorted (value, index) pairs are O(n log n) and O(n); a HashSet pass is O(n) average and O(n). Pin down 'first': left to right, the first value already seen has the earliest second occurrence; right to left, overwriting on each seen value, gives the earliest first occurrence.
4. Qualify average and amortised costs. HashSet and HashMap operations are O(1) on average but slow down with collisions; since Java 8, crowded buckets become balanced trees, so one lookup is at worst O(log n). ArrayList.add is amortised O(1) because the capacity grows by a constant factor. In C, say which code allocates the extra array and where it is freed.
5. When asked to optimise, name what you are trading. If values are known to lie in 0..k, a boolean or count array of size k+1 replaces the hash set: true O(1) lookups for O(k) space. If extra space is not allowed and the array may be modified, sorting it in place costs O(n log n) time and O(1) extra space with heapsort.

Follow-up

• The array holds n values in the range 1..n-1 and must not be modified. Can you find a duplicate in O(1) extra space? (Floyd's cycle detection, treating each value as a pointer to an index: O(n) time.)
• What is the worst-case time of your HashSet solution, and what input would trigger it?
• How does the space complexity change if you rewrite the solution recursively?

Diff a projection against the primary without per-row point reads

Hard · reconciliation · range hashing · throttling

The listing projection has drifted and some rows show a stale version. The primary holds 40,000,000 resource rows across 12,000 tenants while serving 1,200 writes and 14,000 reads per second. The obvious repair, reading each resource row and comparing its version against the projection, is correct and would eventually finish. Explain precisely why it is unacceptable here, then give a diff that finds the differing rows, state its complexity, and make it safe to run against a live primary. Replication lag is usually under 100 ms and is not bounded.

Approach

1. Quantify the naive cost rather than calling it slow: 40,000,000 point reads at even 0.5 ms each is over five hours serialised, and the only lever is concurrency, which is exactly what you cannot spend. The primary's pool is sized for the write path, and 40,000,000 random reads evict the buffer cache that sustains the 85 percent cache hit rate, so the audit degrades the system it is auditing.
2. Replace random access with one ordered pass per side. Both sides can be read in (tenant_id, resource_id) order, which is a sequential scan on each and a merge join in O(n) time and O(1) memory. For a dense diff that is the whole answer, and it reads the primary once instead of 40,000,000 times.
3. For the expected sparse case, compare range hashes instead of rows: partition the key space, compute per range an order-independent aggregate over hash(resource_id, version), compare aggregates, and descend only into ranges that differ. With d differing rows and branching factor B, at most d ranges mismatch per level, so the drill-down examines O(d log_B(n/d)) ranges and reads full rows only in mismatching leaves.
4. Aggregate with a sum modulo 2^64 or a multiset hash, never XOR. XOR is order-independent but self-cancelling, so two rows wrong in the same way, or a row duplicated on one side, leave the range aggregate matching and the range is declared clean.

Follow-up

• The diff reports 900 stale rows. How do you decide between patching those rows and rebuilding the projection from resource_revision?
• Same job, but the projection lives in a search index that cannot be scanned in key order. What changes?

Archive a resource graph without breaking live references or recursing

Medium · graph traversal · topological order · tenant isolation

Resources reference other resources within a tenant; for the largest tenant the reference table holds up to 2,000,000 nodes and 8,000,000 edges. Archiving a resource must archive everything reachable from it that nothing outside the set still references, refuse when a live external referrer exists, and terminate when references form cycles, which they legitimately do. Produce the archive order and the refusal list, targeting O(V+E). Say what stops the traversal crossing a tenant boundary, and why recursion is the wrong control structure at this size.

Approach

1. Load the subgraph with the tenant predicate on both endpoints of the edge, not only on the side you started from. Scoping the left table alone is the classic cross-tenant leak: one mis-entered edge then pulls another tenant's resources into the traversal and, worse, into the archive.
2. Traverse iteratively with an explicit stack. A 2,000,000-node graph can hold a chain deep enough to exhaust a native stack in the low tens of thousands of frames, and that failure is a process crash rather than an error you can return.
3. Treat cycles as data rather than corruption: compute strongly connected components with Tarjan in O(V+E) using its own explicit stack, then condense. The condensation is a DAG, so a topological order over it gives the archive order, and every member of a component archives in one transaction because no order within a cycle is valid.
4. Decide refusals with reverse edges. A candidate is archivable only if every in-edge originates inside the candidate set, so build the transpose or count in-degrees restricted to the visited set, and emit each blocked resource with the id of the external referrer, which is the only part of the answer an operator can act on.

Follow-up

• The graph is read in one query and the archive writes a minute later. What can change in between, and how do you make the write safe?
• The candidate set is 400,000 resources. Is that one transaction, and if not, what does a half-finished archive look like to a reader?

Hold a per-tenant active cap against concurrent creates

Hard · write skew · isolation levels · constraints

A tenant on the standard plan may hold at most 50 resources with status='active'. The create handler runs SELECT count(*) FROM resource WHERE tenant_id = $1 AND status = 'active', compares to 50, then inserts. Two creates arrive 3 ms apart on different instances and the tenant lands at 51. Name the anomaly, say whether PostgreSQL 16 READ COMMITTED or REPEATABLE READ prevents it and why, then give an implementation that holds the cap at READ COMMITTED with the exact statements. Finally, say what changes when the cap is 'at most one running export per tenant' on job_run.

Approach

1. Name it: write skew. The two transactions read an overlapping set and write disjoint rows, so there is no row-level conflict for the engine to detect and each commit is individually legal.
2. Rule out the levels precisely. READ COMMITTED takes a fresh snapshot per statement and takes no lock on the counted rows, so both see 49. PostgreSQL's REPEATABLE READ is snapshot isolation: it removes non-repeatable reads and phantoms within the snapshot but still admits write skew, because the anomaly is not a re-read of a changed row, it is a read of a set that a concurrent transaction invalidates. Only SERIALIZABLE closes it, by tracking the read dependency and aborting one transaction with SQLSTATE 40001 — a guarantee that exists only if the application re-runs the whole transaction from the read.
3. Convert the set predicate into a single-row conflict: keep tenant.active_resource_count and run UPDATE tenant SET active_resource_count = active_resource_count + 1 WHERE tenant_id = $1 AND active_resource_count < 50 in the same transaction as the INSERT. Zero affected rows is the cap, returned as 409. The row lock serialises the decision at any isolation level, and contention is bounded to one tenant's row — which is also the fair-scheduling unit, unlike a global counter that would convoy every tenant behind one row.
4. State the cost you just took on: a counter is a second source of truth that can drift, so every path that changes status must adjust it inside the same transaction, and a periodic reconciliation has to exist, with resource_revision as the authority for what the count should have been.

Follow-up

• A resource moves from archived back to active. Which statements change, and what breaks if the counter update and the status change land in different transactions?
• The cap becomes plan-dependent and a plan can change mid-month. Where does the number 50 live, and who reads it?

Replace offset paging on the resource feed with keyset

Easy · keyset pagination · composite index · sort order

resource holds resource_id, tenant_id, owner_user_id, title, body_ref, version, status ('draft','active','archived','deleted'), created_at, updated_at, deleted_at, with an index on (tenant_id, status, updated_at DESC, resource_id DESC). The listing endpoint returns active resources for one tenant, newest update first, 50 per page, today with LIMIT 50 OFFSET n. Tenants reach page 400 and rows are created while they read. Write the keyset query, define what the cursor carries and how it is encoded, and say which part of the index each predicate uses. Assume PostgreSQL 16.

Approach

1. Name the two failures separately. OFFSET 20000 makes the server produce and discard 20,000 rows, so page cost grows with depth rather than with page size. Independently, any write that changes how many rows sort above the offset moves the window between two fetches, and the direction decides which anomaly you get: an insert lands at the head of updated_at DESC and pushes already-returned rows down past the boundary, so they are returned a second time; a delete above the offset, or a row whose updated_at is bumped above the cursor, pulls rows up and one is never returned at all. Nothing in the response reveals either.
2. Write the seek: WHERE tenant_id = $1 AND status = 'active' AND (updated_at, resource_id) < ($2, $3) ORDER BY updated_at DESC, resource_id DESC LIMIT 50. The row-value comparison is one index range rather than a disjunction, and both columns are NOT NULL, which is what makes that comparison well defined.
3. Map each predicate onto the index: tenant_id and status are equality on the leading columns, (updated_at, resource_id) is the range, and the ORDER BY matches the index order so no Sort node appears and the scan stops after 50 rows. The DESC in the definition only matters for mixed directions — a plain ascending btree on the same columns is read backwards for this query.
4. Put both sort columns in the cursor and nothing the client can tamper with into another tenant: base64 of (updated_at, resource_id), validated server-side, with tenant_id taken from the principal.

Follow-up

• The client asks for 'jump to page 400'. What do you offer instead, and what does the honest version cost?
• Sort order becomes user-selectable across four columns. How many indexes is that, and which would you refuse to add?

How do you demonstrate your understanding of Object-Oriented Programming (OOP)?

Medium · Technical and Domain Knowledge

Approach

1. Show each principle with code you can write on the spot, not with definitions. Encapsulation: private fields changed only through validating methods. Abstraction: an interface such as PaymentMethod with pay(amount). Inheritance: a base class that shares real behaviour. Polymorphism: a List<PaymentMethod> where each call runs the subclass's own implementation.
2. Distinguish the two kinds of polymorphism. Overloading is resolved at compile time from the parameter types. Overriding is resolved at run time by dynamic dispatch on the object's actual class.
3. Argue for composition over inheritance with a concrete failure. Square extending Rectangle breaks Liskov substitution because setting the width silently changes the height. Sharing behaviour through interfaces or composed strategy objects avoids that.
4. Mention SOLID briefly, then tie one principle to a decision from your own project. For example, depending on an interface so a client-specific integration could be swapped out without touching the business logic.
5. Be ready to apply this to a small modelling task such as a library, parking lot or bank account. Identify the entities and what each is responsible for, decide which relationships are is-a and which are has-a, and say which state should be immutable.

Follow-up

• What is the difference between an abstract class and an interface in Java 8 and later, now that interfaces can have default methods?
• How would you get polymorphic behaviour in C, which has no classes (for example a struct of function pointers)?
• Describe a time inheritance caused a problem in code you worked on, and how you refactored it.

How do you approach architectural design in a high-level overview?

Medium · Technical and Domain Knowledge

Approach

1. Start with requirements, not boxes. Who are the users, what are the main use cases, how much load and data do you expect, and what constraints apply (availability, security, data protection, integration with the client's existing systems)? State two or three assumptions out loud.
2. Sketch the layers: clients, an API or gateway layer, application services each with one clear responsibility, and the data store. Use a relational database when you need transactions and joins, and anything else only with a stated reason. Then add the cross-cutting pieces: authentication, caching, a queue for asynchronous work, logging and monitoring.
3. Walk one request through the diagram from start to finish. For example: a user submits a form, the API validates it, a service saves it in a transaction, and a notification job goes onto a queue. This shows how the components work together, not just what they are.
4. Name the trade-offs you made: a monolith or separate services for a team of this size, synchronous or queued calls, strong consistency or availability, and building or buying (including a workflow platform such as Pega for process-heavy cases).
5. Close with risks and how the design grows: the single points of failure, what you would scale first and why, and a two-sentence version of the design for a non-technical client.

Follow-up

• Which component breaks first if traffic grows tenfold, and what would you change?
• How would you integrate with a client's legacy system that you are not allowed to modify?
• Explain this architecture to a project manager without using technical terms.

Edge instances grow 400 MB per hour until the nightly restart

Hard · memory leak · heap analysis · metric cardinality

Edge API instances start at 700 MB resident and grow about 400 MB/hour; a nightly rolling restart has hidden it for weeks. Growth continues unchanged when request rate halves overnight, p99 degrades in the last hours before an instance is recycled, and heap used immediately after a forced full GC rises monotonically. The service holds no product state. Name the discriminating measurement that separates the plausible causes, give the most likely cause, and give the fix and how you would verify it.

Approach

1. Separate resident memory from live heap first, because they fail differently. Resident size can grow from fragmentation, native buffers or thread stacks while the heap is flat; heap used after a full GC rising monotonically is the measurement that says objects are reachable and not being released. You already have it, so this is retention, not fragmentation, and that closes off half the candidate list.
2. Use the rate's independence from traffic as the discriminator. Growth that continues at half the request rate rules out per-request objects that are merely slow to collect and points at a structure that grows with distinct values observed rather than with call volume. Write the candidates that have that property: a metrics registry keyed on a high-cardinality label, an unevicted cache, an interner, a per-key lock map.
3. Take two heap snapshots an hour apart and diff by retained size, reading the dominator tree, not by allocation count or instance count. Expect one root holding a map with millions of entries, then follow the reference chain to the code that inserts and never removes. Allocation profilers point at churn, which is the wrong signal here.
4. The candidate that fits this service is an observability label carrying an identifier, such as a request path recorded before templating so that /v1/resources/48213 becomes its own metric series. That grows with distinct ids seen, is independent of rate, and explains the late p99 degradation, since GC cost rises with the size of the live set.

Follow-up

• Post-GC heap is now flat but resident size still creeps. What are you looking at, and does it matter?
• How would you have detected this before an OOM, given the nightly restart masked the trend?

Suggested practice checklist

Each day is built around one of the reported questions or stages: the Java and C deep dive, array and string coding with Big O, OOP, the architecture overview, Pega with the behavioural stories, and a full mock at the end.

Day 1 — Confirm the format and set up a no-IDE environment

• Ask your recruiter whether the technical stage is live coding or an assignment set before the interview, which languages are allowed, and whether you should bring a project presentation
• Set up javac and gcc so you can compile and run from a plain editor and terminal, then solve one easy array problem that way in each language
• List every technology and project on your CV and mark the ones you could not discuss in depth

Deliverable: The recruiter's answers written down, a working Java and C setup with one solved problem in each, and a marked-up CV list of weak spots.

Day 2 — Java and C fundamentals deep dive

• Write a two-minute spoken answer to the Java and C experience question, organised by project, and record it
• In C, write an in-place string reversal and a realloc-backed dynamic array that frees its memory, and run it under Valgrind or AddressSanitizer
• In Java, write a demonstration of the equals/hashCode contract that breaks a HashMap lookup when hashCode is missing, and a method showing that Java passes references by value

Deliverable: A recorded Java/C answer, two leak-free C programs, and two short Java demonstrations you can explain line by line.

Day 3 — Arrays, strings and complexity

• Solve the first-repeating-element problem three ways (nested loops, sorted index pairs, HashSet) and write the time and space cost of each
• Solve two string problems (for example, first non-repeating character and checking whether two strings are anagrams) and state their complexity aloud
• Take your slowest solution and optimise it for time, then for space, saying each trade-off out loud
• Stretch: work the resource-graph archiving question, which needs an iterative graph traversal instead of recursion, and state its stack and space cost

Deliverable: Five solved problems, each with a written time and space analysis and one explained optimisation.

Day 4 — Object-oriented design in Java

• Write a small payment or library model with an interface, two implementations, encapsulated state and a polymorphic call, and explain it in under two minutes
• Write the Square-extends-Rectangle example, show the Liskov violation, then refactor it using composition or interfaces
• Pick one SOLID principle and match it to a real decision from a project on your CV

Deliverable: A working Java OOP example, a before-and-after Liskov refactor, and one project decision linked to a SOLID principle.

Day 5 — High-level architecture overview

• Draw a component diagram for one project on your CV: clients, API layer, services, data store, queue, authentication and monitoring
• Practise a five-minute walkthrough that starts with requirements, follows one request through the system, and names two trade-offs you made
• Write a two-sentence version for a non-technical stakeholder and answer the tenfold-traffic follow-up

Deliverable: A component diagram, a recorded five-minute walkthrough, and a plain-language summary of the same design.

Day 6 — Pega and behavioural stories

• Write your Pega answer: your honest level of exposure, the building blocks you used or studied (case types, flows, data pages, rule resolution), and how your Java experience carries over
• Write three STAR stories from your CV: a technical decision you made, a time you explained a technical choice to a non-technical stakeholder, and a time you learned a new domain or tool quickly
• Rehearse walking through an incident or outage you owned, from first symptom to fix and follow-up, with the numbers you measured

Deliverable: A written Pega answer, three STAR stories each with a measurable result, and a rehearsed incident walkthrough.

Day 7 — Full mock of the reported process

• Have a peer give you one array or string problem to solve live in Java or C without an IDE, then ask you its Big O
• Answer the OOP and architecture questions back to back, then present one project from your CV as you would in the behavioural interview
• Write down the two weakest answers from the mock and redo them once

Deliverable: A completed mock with notes, and improved second versions of your two weakest answers.

Behavioural preparation

Candidates report behavioural interviews with project managers or hiring leads after the technical stage, with a focus on how you present your skills and project history and how you would work in a client-facing setting. Use STAR. Each story should show a decision you made yourself, the reason behind it, how you explained it to someone non-technical, and a result you can put a number on.

1. Walk me through a project on your CV and explain why you chose its main technologies.
2. Tell me about a time you explained a technical decision to a non-technical stakeholder or client.
3. Tell me about a time you had to learn a new technology or business domain quickly to deliver.
4. Describe a production issue you owned, from the first symptom to the fix and what you changed afterwards.

What is your experience with Pega and related software development processes?

Medium · Technical and Domain Knowledge

Approach

1. Open with one honest sentence about how much Pega you have done: production projects, a training or certification track (CSA and CSSA are the usual Pega certifications), or none. Use the rest of the answer for specifics, not a description of the platform.
2. If you have used it, name the parts you actually worked with: case types with stages and steps, flows and flow actions, data pages and data transforms, activities, decision tables and when rules, and connectors or services for integrations. Walk through one case you built end to end and the business process it ran.
3. Show you know how Pega development differs from hand-written Java. Rules are versioned in rulesets. Rule resolution picks which version runs by walking the class inheritance hierarchy. Most logic is configured rather than coded, and guardrail warnings flag custom activities or Java that make upgrades harder. Say when you chose custom code anyway, and why.
4. Answer the 'development processes' part as well: how you gathered requirements with business users, how rulesets were packaged and moved between environments, and how you tested a case flow before release.
5. If you have no Pega experience, map what transfers: Java and OOP (Pega classes use inheritance), workflow or state-machine code you have written, and any rules engine or configuration-driven system you have worked on. Then say exactly what you have done to learn it, such as Pega Academy modules.

Follow-up

• How does rule resolution decide which version of a rule runs for a given case?
• When would you write an activity or custom Java rather than configure a flow or data transform?
• How would you explain a case type's stages to a business stakeholder who has never seen Pega?

Can you explain your experience with Java and C?

Medium · Technical and Domain Knowledge

Approach

1. Organise the answer by project. For each language, give one project, what you built, which parts were yours, and one decision you made in that language and why. Only claim what you could defend if asked to write the code.
2. Contrast the memory models. C gives you malloc and free, pointer arithmetic, stack versus heap allocation, and undefined behaviour on out-of-bounds access or use-after-free. Java puts objects on the heap, a garbage collector reclaims them, and object references are passed by value. Have a real bug of each kind ready: a leak or dangling pointer in C, and an object kept alive by a static collection in Java.
3. Review the Java topics deep dives usually reach: the equals/hashCode contract and how HashMap depends on it, String immutability and StringBuilder, checked versus unchecked exceptions, and the collections (ArrayList, LinkedList, HashMap, TreeMap) with the cost of their main operations.
4. For C, be ready to write and explain an in-place string reversal, a dynamic array that grows with realloc (checking the return value before overwriting the pointer), and a linked list that frees every node. Name Valgrind or AddressSanitizer as how you would find memory errors.
5. Finish with when you would pick each: C for tight memory or latency budgets and low-level system interfaces; Java for large applications that benefit from managed memory, a big standard library and JVM portability.

Follow-up

• Is Java pass-by-value or pass-by-reference? Show it with a method that reassigns its parameter.
• How would you track down a memory leak in a C program, and what does a leak look like in Java?
• What goes wrong if you override equals but not hashCode and then use the object as a HashMap key?

Narrate an outage you owned from page to postmortem

Hard · incident response · blast radius · postmortems

Pick an incident you personally drove, ideally one where writes were affected rather than reads. In six to eight minutes: state the symptom as it first appeared on a dashboard, the blast radius you established before you knew the cause, the mitigation you applied and when, the mechanism you eventually proved, and the follow-up that would prevent a repeat. Bring numbers: error rate, tenants affected, minutes to mitigate, minutes to resolve. If you cannot name what you measured, choose a different incident.

Approach

1. Open on the signal rather than the cause: which metric at which percentile moved, on which service, at what time, so the listener follows the same evidence you had rather than a conclusion you already reached.
2. Separate mitigation from diagnosis out loud. State what you did to stop the bleeding (flag off, shed traffic, drain a lease, roll back a deploy) and say plainly that you did it before the mechanism was known, because those are two jobs with different deadlines.
3. Establish blast radius in countable terms: how many tenants, how many writes, and crucially whether the effect was loss or only delay. An append-only revision table or a pending outbox row means the change survived and the projection was merely behind, which is a repair rather than a data-loss incident.
4. Prove the mechanism instead of asserting it. Name the trace span that grew, the plan that flipped to a sequential scan, the lease that expired, plus one alternative you ruled out and the signal that stayed flat while you ruled it out.

Follow-up

• What would you do differently in the first five minutes, given the same dashboard and no more information?
• Which follow-up action did you deliberately not take, and why was dropping it the right call?