cswork / libraryOpen practice workspace

Interview guides · AIMDek Technologies

AIMDek Technologies Software Engineer Interview Guide

AIMDek Technologies Software Engineer interview guide: five reported rounds, OOP, SQL, Liferay, Salesforce and React questions, and a 7-day plan.

The 60-second brief

Candidates describe AIMDek Technologies as a company that delivers software to enterprise clients. The platforms they mention are Liferay and Salesforce, alongside web stacks built on React and Node.js. For a Software Engineer, the reported work is assignment to client projects across the development lifecycle, including code review and upkeep of modules that already exist. Day to day that means Java backends, SQL queries, and front ends that behave on different screen sizes, with Salesforce triggers and database tuning named as typical tasks.

This guide is for candidates interviewing for a Software Engineer position at AIMDek Technologies, from campus recruits to engineers with project experience. It covers the five reported rounds, the core questions on OOP, Java, data structures, C++ versus Java and DBMS, the platform questions on Liferay, OSGi, Salesforce, cross-browser work, React and Node.js, and the behavioral questions on your past project and teamwork. It does not predict which question appears in which round.

Candidates report five rounds over roughly 4-6 weeks: Initial Screening, Algorithmic Challenges, Technical Rounds, Group Discussion and a Final Management Round. The Group Discussion is reported mainly for campus recruits.

Focus areas

  • Algorithms
  • Data Structures
  • Problem Solving

Overview

The reported work is delivery for enterprise clients on a mix of platforms: Liferay, Salesforce, React, Node.js, plus Java backends and SQL. The loop mirrors that mix. You need fundamentals you can explain from first principles, and you need to talk about real projects without reading from a script. Plan for two kinds of questions: textbook topics, where candidates are advised to give the reasons behind a choice as well as the definition, and experience questions where your own project is the material.

The fundamentals candidates report are OOP (classes, objects, inheritance, polymorphism), String versus StringBuilder in Java, the kinds of data structures and when each fits, C++ versus Java, and DBMS concepts with complex SQL. Must-have skills reported for the role are Java or C++, OOP, DBMS with SQL, and basic data structures and algorithms. For each topic prepare a definition, a short code or query example, a trade-off, and a place you used it. Algorithm work reported in the loop covers arrays and lists (finding consecutive sequences is the example given), string handling, and time and space complexity, sometimes on paper or in a shared coding environment.

Platform questions cover Liferay as a portal, OSGi and modular development, Salesforce triggers, Aura components and Admin tasks, cross-browser behaviour of responsive pages, and React with Node.js. Candidates describe Liferay and Salesforce as nice-to-have rather than required, so an honest account of what you have and have not done, tied to the closest technology you do know, is a stronger answer than bluffing. Practise a troubleshooting sequence for a platform error as well: reproduce, read the log, isolate the layer, test one change.

The last two stages shift from knowledge to communication. The Group Discussion is reported for campus recruits and the Final Management Round is reported as a conversation with leadership about critical thinking and trajectory. Rehearse your project story until you can give it in layers, from the one-minute version to the schema and the failure you debugged, and prepare to link your technical work to what the client needed.

The AIMDek Technologies interview process

These are the five rounds candidates describe, in the order they report them. This guide does not map questions to rounds, so the preparation below is organised by question type.

Initial Screening

Candidates describe the first stage as an assessment of foundational skills to gauge basic technical capability. Candidates also report questions on how they learned about the opening and on their strengths and weaknesses, but the reports do not say which round those belong to, so keep short answers ready for any stage. Approach this stage as a short, clear performance: crisp definitions of OOP, DBMS and data structure basics, and a brief account of your background and your stack.

What to demonstrate

  • Command of core concepts: OOP, DBMS, data structures
  • Clear spoken explanation of fundamentals
  • Fit between your resume stack and the Java or C++, SQL and web skills listed for the role

How to prepare

  • Give a two-sentence definition plus one example for each of the four OOP principles, using classes from a project you built.
  • Be able to state the difference between String and StringBuilder and between C++ and Java in under a minute each.
  • Write one honest answer for how you learned about the opening and one for your strengths and weaknesses.

Algorithmic Challenges

Candidates report coding ability being tested early, through algorithmic challenges, sometimes on paper or in a shared coding environment. The areas named are arrays and lists (finding consecutive sequences), string manipulation, and complexity analysis. Candidates also mention medium-to-difficult coding problems in an aptitude or online test phase. Approach each problem by restating it, listing edge cases, naming the brute-force idea and its cost, then improving it and writing complete code.

What to demonstrate

  • Working code for array, list and string problems
  • Time and space complexity analysis of your own solution
  • Edge-case handling: empty input, duplicates, single element

How to prepare

  • Solve the longest consecutive sequence problem two ways: sort and scan in O(n log n), then a hash set in O(n), and state when you would choose each.
  • Practise writing a full Java or C++ solution on paper, including imports, method signature and a hand-traced test case.

Technical Rounds

Candidates describe the technical rounds as deeper evaluations of specialised skills: platform architecture for Liferay or Salesforce, the development lifecycle from writing triggers and queries to building responsive components, and less common topics such as OSGi modularity, database indexing and cross-browser strategies. Deep dives into your previous project's stack and troubleshooting a platform error are also reported. Approach it by choosing the stack you can defend in depth and saying plainly where your experience ends.

What to demonstrate

  • Depth in the stack you claim: Java, SQL, Salesforce, Liferay, React or Node.js
  • Understanding of why a design or implementation choice was made, not only how
  • Ability to describe a debugging path for a platform-related error

How to prepare

  • Write three SQL queries on a customers-orders-payments schema: a multi-join aggregate, a window function ranking, and a left join that finds rows with no match. Then explain the index each would use.
  • Prepare a one-page note on Liferay as a portal and on OSGi bundles, services and the module lifecycle, with the limits of your hands-on experience marked.
  • Rehearse a troubleshooting walk-through: reproduce, read logs, isolate frontend, backend or data, change one thing, verify.

Group Discussion

Candidates report a Group Discussion for campus recruits, used to assess communication and teamwork. Candidates are advised to treat it as a joint task: pay attention to others, add points that move the conversation along, and help the group settle on an answer instead of competing for airtime. The discussion topics are not reported, so prepare the behaviours rather than a topic list. If you are an experienced hire, ask the recruiter whether this round applies to you.

What to demonstrate

  • Communication within a group
  • Teamwork: building on others' points and reaching agreement
  • Listening and helping the group converge

How to prepare

  • Practise two or three group discussions with friends on any technology or workplace topic, and have one person track how often each speaker contributed.
  • Prepare opening, bridging and summarising sentences, such as restating a peer's point before adding yours and offering a closing summary of where the group agrees.
  • Rehearse disagreeing politely with a reason, then proposing a way for the group to test the two positions.

Final Management Round

Candidates report a final round with management, often a leadership or director conversation, covering critical thinking, professional trajectory and ambiguous business scenarios. It is also described as a check of alignment with the company's long-term direction. Prepare to describe your projects in terms of client and business outcomes, to reason aloud through an unclear scenario, and to explain where you want your career to go and why this role fits.

What to demonstrate

  • Critical thinking on an open-ended business scenario
  • Clarity about your professional direction
  • Reasoning through ambiguous, real-world business situations

How to prepare

  • Pick two ambiguous scenarios, such as a client asking for a feature that conflicts with the schedule, and practise a four-step answer: clarify, list options, weigh trade-offs, recommend and name the risk.
  • Write a short account of which practice you would grow into (Liferay, Salesforce, or React and Node.js) and how you would handle a client-facing case such as a requirement that conflicts with a platform limit.
  • Convert your best project into a client-facing summary with no jargon: the problem, what you built, what changed for the user.

Where candidates lose points

Reciting OOP, String versus StringBuilder or C++ versus Java as a definition with no example or consequence.

For each topic, prepare a four-part answer: the definition, a short code sample, the trade-off, and where you used it. For String versus StringBuilder, show immutability and the cost of repeated concatenation in a loop, not just the words 'mutable' and 'immutable'.

Starting to code on paper or in a shared environment before restating the problem, naming complexity and listing edge cases.

Spend the first minutes on the input, an example, the brute-force cost and the edge cases (empty input, duplicates, a single element). Candidates are advised to explain their reasoning, so say the complexity of each version aloud, then write the final one fully and trace it.

Claiming Liferay, OSGi or Salesforce experience you cannot support when the follow-up reaches triggers, bundles or governor limits.

State your real level at the start of the answer and map it to the nearest tool you have used, for instance an event-driven ORM hook for a Salesforce trigger. Candidates report these platforms as nice-to-have, so honest depth with a learning plan is safer than breadth you cannot defend.

Describing a past project as what 'the team' did, with no clear personal contribution, schema or architecture you can draw.

Choose the project you can explain at four levels: the one-line summary, the architecture, the data model and one production problem. Rehearse it out loud and mark which decisions were yours.

In the Group Discussion, either dominating the conversation or saying nothing until the end.

Aim to contribute early, build on a specific earlier point, ask one question that moves the group forward, and offer a closing summary. Candidates are advised that listening and helping the group converge matter more than volume.

Questions & practice

Find overlapping job attempts and peak concurrency from lease records

Medium · sweep line · intervals · leases

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

Approach

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

Follow-up

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

Merge partitioned event streams into one ordered feed with bounded lateness

Hard · k-way merge · watermarks · out-of-order streams

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

  1. 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.
  2. 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.
  3. 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.
  4. 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

Medium · parsing · canonicalisation · hashing

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

  1. 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.
  2. 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.
  3. 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.
  4. 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?

Can you explain basic DBMS concepts and write complex SQL queries?

Medium · Core Technical Foundations

Approach

  1. Cover the DBMS basics briefly and concretely: primary, foreign and unique keys; normalisation up to 3NF (no repeating groups, no partial dependency on a composite key, no transitive dependency); ACID; and the isolation levels with the anomaly each prevents (dirty read, non-repeatable read, phantom).
  2. For the query part, start from the grain of the result and build outward: a classic is the top earners per department, written as DENSE_RANK() OVER (PARTITION BY dept_id ORDER BY salary DESC) in a subquery or CTE, then filtered to rank <= N in the outer query, because a window function cannot be filtered in the same WHERE clause.
  3. State the clause semantics precisely: WHERE filters rows before grouping, HAVING filters groups after aggregation; COUNT(*) counts rows while COUNT(col) skips NULLs; a LEFT JOIN plus a filter on the right table in WHERE silently turns it into an inner join, so that filter belongs in the ON clause.
  4. Handle NULLs and missing rows: NOT IN against a subquery that returns any NULL yields no rows, so I use NOT EXISTS or a LEFT JOIN ... WHERE right.id IS NULL for anti-joins.
  5. Say how the query would perform: a composite B-tree index on (dept_id, salary) supports the partition-and-order, and a composite index is used most efficiently when the query constrains its leading column or columns. Some engines can skip-scan (Oracle, MySQL 8, PostgreSQL 18), but I do not rely on that. Wrapping the indexed column in a function or using LIKE '%x' usually prevents an index seek.

Follow-up

  • What is the difference between ROW_NUMBER, RANK and DENSE_RANK when two employees share a salary?
  • Rewrite the per-department top-N query without window functions, for example with a correlated subquery.
  • When would you deliberately denormalise a table, and what do you give up?

Find version gaps and relay lag with window functions

Medium · window functions · event tables · frame semantics

outbox_event holds event_id, aggregate_type, aggregate_id, aggregate_version, event_type, payload, status ('pending','published','dead'), attempts, created_at, published_at. A projection is missing rows and you must decide whether the relay skipped events or the consumer dropped them. Write three queries over the last seven days: one listing every aggregate_id whose published aggregate_version sequence has a hole, one giving per-day counts with a running total, and one returning the newest published event per aggregate. For each, say where the window function is evaluated relative to WHERE and LIMIT. PostgreSQL 16.

Approach

  1. Gaps: compute lead(aggregate_version) OVER (PARTITION BY aggregate_id ORDER BY aggregate_version) in a subquery, then filter next_version <> aggregate_version + 1 in the outer query. Window functions are evaluated after WHERE, GROUP BY and HAVING and before the outer ORDER BY and LIMIT, so the predicate cannot sit in the same WHERE clause and PostgreSQL 16 has no QUALIFY.
  2. Say what the seven-day filter does to the answer: it truncates every partition, so the first row per aggregate has no predecessor inside the window and a hole spanning the boundary is invisible. Widen the window, or join to resource.version as the authority for the true maximum.
  3. Running total: SELECT date_trunc('day', created_at) AS d, count() AS n, sum(count()) OVER (ORDER BY date_trunc('day', created_at) ROWS UNBOUNDED PRECEDING). An aggregate inside a window call is legal because grouping runs before windowing. The grouping key is unique per row here so ROWS and RANGE agree, but write the frame anyway — over ungrouped rows with tied timestamps the default RANGE frame pulls in every peer row and the total jumps.
  4. Newest per aggregate: DISTINCT ON (aggregate_id) ... ORDER BY aggregate_id, aggregate_version DESC is the cheap PostgreSQL-only form when an index matches that order; row_number() OVER (PARTITION BY aggregate_id ORDER BY aggregate_version DESC) = 1 is the portable form and needs a subquery for the same evaluation-order reason as the gap query.

Follow-up

  • Relay failover redelivers events. Does a duplicate break the gap query, and how would you detect one from this table alone?
  • Turn the gap check into a continuous monitor rather than a query someone runs after an incident. What does it watch?

Explain the core principles of OOP (Classes, Objects, Inheritance, Polymorphism).

Medium · Core Technical Foundations

Approach

  1. Define a class as the blueprint (fields plus methods) and an object as one instance with its own state, then use one running example for every principle, such as a Shape base type with Circle and Rectangle subclasses that each implement area().
  2. Cover all four pillars, not only the two in the title: encapsulation (private fields behind methods that enforce invariants), abstraction (callers depend on Shape, not on the concrete class), inheritance (is-a reuse) and polymorphism.
  3. Split polymorphism into compile-time (method overloading, resolved by the parameter types at compile time) and runtime (method overriding, resolved by dynamic dispatch on the object's actual class), and show a List<Shape> loop calling area() on each element.
  4. Point out the Java specifics: a class extends one class but implements many interfaces, and non-static, non-private, non-final methods are overridable by default.
  5. Close with a trade-off: deep inheritance trees couple subclasses to base-class internals, so I prefer composition when the relationship is has-a, and I keep subclasses substitutable for their base type (the Liskov substitution principle).

Follow-up

  • What is the difference between an abstract class and an interface in Java, and how did default methods in Java 8 change that choice?
  • Can you override a static or private method? What happens if you try?
  • Give an example from your own code where you replaced inheritance with composition, and why.

What are the differences between String and StringBuilder in Java?

Medium · Core Technical Foundations

Approach

  1. Start with the core difference: String is immutable (every apparent change returns a new object), while StringBuilder is mutable and edits its internal character buffer in place.
  2. Give the cost consequence: s = s + x inside a loop copies the whole string each iteration, so building a string of n pieces is O(n^2) character copying; StringBuilder.append is amortised O(1) because the buffer grows geometrically, so the loop becomes O(n).
  3. Explain why String is immutable: literals can be shared safely in the string pool, the hashCode can be cached (which makes Strings good HashMap keys), and an immutable object is thread-safe without locks.
  4. Add StringBuffer as the third option: same API as StringBuilder but its methods are synchronized, so StringBuilder is the default for single-threaded code.
  5. Mention the traps: compare String contents with equals(), not ==; StringBuilder does not override equals(), so compare sb1.toString().equals(sb2.toString()); and a single-expression concatenation such as a + b + c is already optimised by the compiler, so the builder only matters across loop iterations.

Follow-up

  • Why does "hello" == "hello" usually return true, while new String("hello") == "hello" returns false?
  • When would you pass an initial capacity to the StringBuilder constructor?
  • Is StringBuilder safe to share between two threads? What would you use instead?

Explain the different types of Data Structures and when to use them.

Medium · Core Technical Foundations

Approach

  1. Organise the answer by access pattern, not as a list of names: for each structure give its key operations and their complexity, then one situation where it is the right choice.
  2. Linear structures: an array or ArrayList gives O(1) access by index but O(n) insertion in the middle; a linked list gives O(1) insertion or removal at a node you already hold but O(n) access by position; a stack (LIFO) suits undo and expression parsing, and a queue (FIFO) suits BFS and task buffers.
  3. Hash-based: HashMap and HashSet give average O(1) lookup, insert and delete with no ordering; Java 8+ turns a heavily collided bucket into a tree, so the worst case is O(log n) per bucket rather than O(n). A problem like the longest consecutive sequence in an unsorted array becomes O(n) with a HashSet instead of O(n log n) by sorting.
  4. Ordered and priority structures: a balanced BST such as TreeMap gives O(log n) operations plus sorted iteration and range queries; a binary heap (PriorityQueue) gives O(1) peek and O(log n) insert or extract, which is what top-k and Dijkstra need.
  5. Graphs: an adjacency list costs O(V + E) memory and suits sparse graphs; an adjacency matrix costs O(V^2) but answers 'is there an edge?' in O(1), which pays off only for dense graphs.

Follow-up

  • In Java, when would you choose LinkedList over ArrayList, and does that choice hold up in practice given cache locality?
  • How does HashMap handle collisions and resizing, and what happens if a key's hashCode changes after insertion?
  • How would you find the k largest elements in a stream, and what is the complexity?

What is the difference between C++ and Java?

Medium · Core Technical Foundations

Approach

  1. Execution model: C++ compiles to native machine code for a target platform; Java compiles to bytecode that runs on the JVM, which interprets it and JIT-compiles hot paths, so the same .class files run anywhere a JVM exists.
  2. Memory: C++ gives manual control (new/delete, stack objects) and deterministic destruction, with RAII and smart pointers (unique_ptr, shared_ptr) as the idiomatic safety net; Java allocates objects on the heap and frees them with a garbage collector, so object cleanup is not deterministic and resources are closed with try-with-resources.
  3. Language model: C++ has pointers and pointer arithmetic, multiple inheritance of classes, operator overloading, and methods that dispatch dynamically only when declared virtual; Java has references without arithmetic, single class inheritance plus multiple interfaces, no user-defined operator overloading, and overridable methods by default.
  4. Generics: C++ templates are instantiated per type at compile time (fast, but larger binaries and harder error messages); Java generics use type erasure, so the type parameter is gone at runtime, you cannot write new T(), and primitives must be boxed (List<Integer>, not List<int>).
  5. Finish with when each fits: C++ for latency-sensitive or hardware-near work where control over memory matters; Java for server-side applications where portability, a large standard library and GC-managed safety outweigh that control.

Follow-up

  • How does C++ handle the diamond problem with multiple inheritance, and why does Java avoid it?
  • Is Java pass-by-value or pass-by-reference? Show what happens when a method reassigns an object parameter.
  • What does type erasure prevent you from doing in Java generics?

What is Liferay and how does it function as a portal?

Medium · Web & Platform-Specific Expertise

Approach

  1. Define it plainly: Liferay is a Java-based open-source portal platform (offered as Liferay Portal CE and the commercial Liferay DXP) for building intranets, customer portals and content sites where one page aggregates several independent applications behind a single login.
  2. Explain the portal model: a page is a layout of portlets, each a pluggable UI component that renders a fragment of the page rather than a whole document; the portal assembles the fragments, applies the theme and layout template, and enforces roles and permissions per site, page and portlet.
  3. Walk the portlet lifecycle from the Java portlet specification (JSR 168/286): the action phase (processAction) handles a form submission once, then the render phase draws every portlet on the page; serveResource handles AJAX and file downloads; portlets also have modes (VIEW, EDIT, HELP) and window states (normal, maximized, minimized).
  4. Cover how development works on Liferay 7 and later: custom code ships as OSGi modules, and Service Builder generates the model, persistence and service layers from a service.xml entity definition, which keeps business logic out of the portlet class.
  5. If you have not used it, say so and map it to what you know, for example portlets as server-rendered widgets and Service Builder as an ORM-plus-service code generator, rather than claiming experience you cannot defend in a follow-up.

Follow-up

  • Why are the action and render phases separate, and what happens if a user refreshes the page after submitting a form?
  • How can two portlets on the same page share data, for example through public render parameters or portlet events?
  • What does Service Builder generate from service.xml, and where would you put custom business logic?

Have you worked with OSGi? Explain its relevance in modular development.

Medium · Web & Platform-Specific Expertise

Approach

  1. Define OSGi as a module system and service platform for Java: code ships as bundles, which are ordinary JARs whose MANIFEST.MF declares Bundle-SymbolicName, Bundle-Version, Export-Package and Import-Package (with version ranges).
  2. Explain why that matters for modularity: each bundle gets its own class loader and sees only the packages it imports, so internal packages stay hidden, dependencies are explicit, and two versions of the same package can be loaded side by side for different consumers.
  3. Describe the lifecycle (INSTALLED, RESOLVED, STARTING, ACTIVE, STOPPING, UNINSTALLED): bundles can be installed, updated or stopped at runtime without restarting the whole application, which is how a platform such as Liferay 7+ deploys modules.
  4. Cover the service registry: a bundle publishes an implementation under an interface and others look it up; with Declarative Services this is @Component on the provider and @Reference on the consumer, so implementations can be swapped without touching callers.
  5. Give the debugging sequence and the trade-off: a bundle stuck in INSTALLED usually has an unsatisfied Import-Package, so I list bundles and their states in the Gogo shell and check its imports against what is exported; the cost of OSGi is manifest and class-loading complexity compared with a plain classpath or Java 9 JPMS, which is static and has no runtime lifecycle.

Follow-up

  • What is the difference between Import-Package and Require-Bundle, and why is Import-Package usually preferred?
  • How does OSGi differ from the Java Platform Module System introduced in Java 9?
  • A component stays unsatisfied even though its bundle is ACTIVE. How would you find out why?

Exports duplicate a row range about once a week

Hard · leases · clock skew · idempotency

Roughly once a week an export writes a file containing a duplicated range of rows. The affected job_run rows show attempt = 1, status = succeeded, one started_at, and a lease_owner naming a different host from the one whose logs show the job starting. Leases last 30 seconds and are heartbeated every 10 from inside the handler; lease_expires_at is computed on the worker and compared against the database's now(). Find the mechanism, and give a fix that holds even if you cannot fix the clocks.

Approach

  1. Start from the fact that eliminates the obvious answer. attempt = 1 means no retry was recorded, so this is not a re-run after failure; two workers ran the same row concurrently and the takeover path never touched the counter. lease_owner naming a host other than the one that started the job is the same statement from the other side.
  2. Enumerate the mechanisms that cause a premature takeover, then find the signal that separates them. Either the lease genuinely expired because the heartbeat did not fire, which is what happens when the heartbeat runs on the handler's own thread and the handler makes a long blocking call, or it only appeared expired because two clocks disagree, since lease_expires_at is written from the worker's clock and evaluated against the database's. The discriminator is the distribution: incidents clustered on the longest exports indict the heartbeat, incidents clustered on one host indict skew. Measure both, and measure each host's offset against the database directly.
  3. Read the reclaim query precisely. In PostgreSQL now() is transaction start time, not statement time, so a reclaimer holding a long transaction compares against an older timestamp than expected; clock_timestamp() is the statement-time function. This is worth ruling in or out before you redesign anything, because it changes which rows look expired.
  4. Remove the second clock rather than trying to synchronise it. Issue and extend the lease in the database, with lease_expires_at = now() + interval '30 seconds' in both the claim and the heartbeat, so exactly one clock is ever compared and worker skew stops mattering to this predicate.

Follow-up

  • The displaced worker has already streamed half the file to object storage. What makes that side effect safe to repeat?
  • You now count takeovers. What alert fires on that counter, and at what threshold?

Suggested practice checklist

The plan follows the loop: core fundamentals first, then algorithms and SQL, the platform stack, front end, and finally project and behavioral stories.

Day 1 — Map the loop and audit your stack

  • Write the five reported rounds in order and, beside each, the question types its format can cover: foundations, coding, platform depth, group communication, management conversation.
  • List the must-have skills (Java or C++, OOP, DBMS with SQL, data structures and algorithms) and the nice-to-have ones (Liferay, Salesforce, React, HTML and CSS, Node.js). Rate your honest level in each from 1 to 3.
  • Choose the single project you will build your stories around.

Deliverable: A one-page loop map, a rated skills table with the weakest three topics marked, and the name of your anchor project.

Day 2 — Say the Java and OOP fundamentals out loud

  • Answer the OOP principles question aloud with an example from your anchor project for each of classes, objects, inheritance and polymorphism, including one example of overriding versus overloading.
  • Write a short Java program that shows String immutability and compares repeated concatenation with StringBuilder, and note the result you observe.
  • Write a table of C++ versus Java covering memory management, pointers, multiple inheritance, compilation and platform model, and say which you would pick for which job.

Deliverable: Three recorded spoken answers (OOP, String versus StringBuilder, C++ versus Java), one working Java sample, and the C++ versus Java table.

Day 3 — Data structures, algorithm patterns and an online-test run

  • Write a table of the data structures you would name (array, linked list, stack, queue, hash map, tree, heap, graph) with the operation costs and one realistic use for each.
  • Solve the longest consecutive sequence problem with sort-and-scan, then with a hash set, and state both complexities.
  • Because candidates mention an aptitude or online test phase, do one self-timed online-test style set: two coding problems plus a short aptitude-style set of quantitative and logical questions.

Deliverable: A completed data-structure table, two handwritten solutions with complexity statements, a traced test for the interval problem, and your results from the self-timed online-test set.

Day 4 — DBMS concepts and SQL

  • Write a one-page summary of DBMS concepts: keys, normalization up to third normal form, ACID, transactions and isolation, and how a B-tree index speeds lookups.
  • Write and run three queries on a sample schema: a multi-join aggregate, a left join finding unmatched rows, and a window function ranking.

Deliverable: A DBMS summary page, three tested queries with notes on the index each uses, and a worked solution to the window-function practice question.

Day 5 — Platform depth: Liferay, OSGi and Salesforce

  • Write a half-page note on Liferay as a portal (pages, portlets or modules, content) and one on OSGi bundles, the service registry and the lifecycle, marking what you have actually used.
  • Write an Apex trigger on paper that updates related records in bulk, using a Set of Ids, one query into a Map and one DML statement, and list the governor limits it respects.
  • Prepare the answer to the Salesforce experience question, with triggers, Aura components and Admin tasks, tailored to your real level.

Deliverable: Two platform notes with honest experience marks, one bulk-safe trigger sketch, and a written Salesforce answer.

Day 6 — Front end, Node.js and troubleshooting

  • Build a small page that is responsive with flexbox or grid and media queries, then write down the browsers you would test and the three checks you would run in each.
  • Write a short account of your React and Node.js project: component structure, state location, API shape, error handling. Prepare answers about useEffect cleanup and the Node.js event loop.

Deliverable: A responsive sample page, a React and Node.js talking-points sheet, and a recorded debugging narration for the duplicated exports question.

Day 7 — Project story, behavioral answers and a full mock

  • Write and rehearse the previous project answer at one-minute and five-minute lengths, with the architecture sketch and one production problem.
  • Prepare answers to the team problem-solving, how you learned about the opening, and strengths and weaknesses questions, each with a concrete example.
  • Hold a mock group discussion with two people and a mock management conversation on an ambiguous scenario, then note what to fix.

Deliverable: A written project script at two lengths, four short behavioral answers, and a notes sheet from the group discussion and management mocks.

Project, team and personal stories

Behavioral questions candidates report for this role are about your own work: the previous project in detail, how you solve problems with a team, how you found the opening, and your strengths and weaknesses. The Group Discussion round, reported for campus recruits, and the management round also rely on how clearly you communicate. Give each story a specific project, your decision, the trade-off and the result. Questions on Salesforce, cross-browser work and React with Node.js are covered in the platform days of the plan.

Describe your experience with Salesforce development (e.g., triggers, Aura components, or Admin tasks).

Medium · Web & Platform-Specific Expertise

Approach

  1. Start with an honest scope statement: which of the three you have done (Apex triggers, Aura components, or Admin configuration), on what kind of project, and for how long. If you have none, say that, and describe the closest thing you have built or the trial org you worked in, so the answer stays truthful.
  2. For triggers, show you know the mechanics: one trigger per object delegating to a handler class; before triggers to change the record's own fields without extra DML, after triggers to touch related records; loop over the Trigger.new batch, gather Ids in a Set, run one SOQL query into a Map and one DML on a list. Mention governor limits (100 SOQL queries and 150 DML statements per synchronous transaction) as the reason for never querying inside a loop.
  3. For Aura, describe the component bundle (markup, controller, helper, style), attributes, component versus application events, and calling an @AuraEnabled Apex method with a callback. Say that Lightning Web Components is the newer model and give a reason why you used Aura, such as maintaining an existing module.
  4. For Admin work, name concrete items: custom objects and fields, validation rules, page layouts, profiles and permission sets, flows. Explain how you chose declarative tools over code, and how you tested in a sandbox before deploying; Apex deployment needs test coverage.
  5. Close with one specific case: the requirement, what you built, the bug you hit and how you tested the fix. Mistake that sinks the answer: a list of feature names with no decision you made.

Follow-up

  • How do you stop a trigger from re-firing itself when it updates the same object?
  • What happens when a data load of 200 or more records runs through your trigger, and how did you make it safe?
  • When would you choose a Flow over an Apex trigger, and what would make you switch?

How do you handle cross-browser compatibility when implementing responsive web pages?

Medium · Web & Platform-Specific Expertise

Approach

  1. Treat it as a process story. State the target: which browsers and devices the project had to support, and how that was decided (analytics, client requirement, a browserslist file). Without a target, 'compatible' has no meaning.
  2. Describe your baseline: semantic HTML, a CSS reset or normalize, mobile-first media queries, the viewport meta tag, relative units, flexbox and grid for layout, and Autoprefixer plus Babel driven by the browserslist config for vendor prefixes and newer JavaScript syntax.
  3. Explain feature detection over browser sniffing: @supports in CSS, checking for an API before calling it in JavaScript, and polyfills or a graceful fallback only where the feature is missing. This is progressive enhancement: the page works everywhere and improves where it can.
  4. Describe how you test: browser developer tools device emulation first, then real devices or a cross-browser testing service for Safari on iOS, Firefox and an older Edge or Chrome. Name an actual bug you fixed, such as viewport height on mobile Safari, a form control that rendered differently, or a missing flex gap.
  5. State the cost of the decision: extra polyfill size, dropped support for an old browser agreed with the client, and a regression checklist you kept.

Follow-up

  • A page renders correctly in Chrome but breaks in Safari. What is your debugging sequence?
  • How do you decide which old browsers to stop supporting, and who needs to agree?
  • What is the difference between feature detection and user-agent sniffing, and why is the second fragile?

Deep dive into your experience with React and Node.js.

Medium · Web & Platform-Specific Expertise

Approach

  1. Choose one project and open with its shape: what the React front end did, what the Node.js service did, how they talked (REST or another protocol) and where the data lived. Keep it to a few sentences, then go deep on two decisions.
  2. On React, be ready to explain state versus props, controlled inputs, keys in lists, how hooks work (useState, useEffect with a dependency array and cleanup, useMemo and useCallback when a re-render is measurably costly), and where you kept shared state and why: lifting state, context, or a store library.
  3. On Node.js, explain the single-threaded event loop and non-blocking I/O, Express-style middleware (authentication, validation, error handling), async/await with try/catch or an error middleware, and why CPU-heavy work must be moved off the main thread to a worker thread or a queue.
  4. Cover the integration seams: how you handled loading and error states, request cancellation or race conditions in useEffect, CORS, validation on both sides, and configuration through environment variables.
  5. Admit boundaries. If you used React but not Node.js in production, say so and describe the nearest backend you owned. Mistake that sinks it: naming libraries without being able to say what problem each solved.

Follow-up

  • Why might a useEffect run twice in development, and how do you write an effect that is safe to run more than once?
  • How would you handle a CPU-heavy task, such as generating a large report, in a Node.js API without blocking other requests?
  • How do you avoid showing stale data when a user triggers two quick searches and the responses return out of order?

Explain a previous project you worked on in detail.

Medium · Behavioral & Critical Thinking

Approach

  1. Select one project in which you made decisions and can explain every layer. Open with a short frame: who the users or client were, what the system had to do, your role, and the stack. Stay under a minute before inviting questions.
  2. Describe the architecture in order: front end, backend, database and integrations, and draw it if you have paper or a whiteboard. Name the data model's main tables or objects and one place performance or correctness mattered.
  3. Pick two technical decisions and give the alternative you rejected and why, for example a SQL index, a framework or a way to structure modules. This addresses the 'why, not only how' that candidates report being asked.
  4. Tell one real problem: the symptom, how you narrowed it down, the fix and how you confirmed it. Quantify the outcome only with numbers you actually measured.
  5. Separate 'I' from 'the team': say what you wrote, reviewed and decided. Mistake that sinks it: a project you only touched, which collapses at the second follow-up about schema or deployment.

Follow-up

  • Why did you choose that database or framework, and what would you pick today?
  • What was the hardest bug in this project and how did you find the cause?
  • If the client doubled the number of users, which part of this design breaks first?

How do you approach complex problem-solving in a team setting?

Medium · Behavioral & Critical Thinking

Approach

  1. Pick one concrete problem that was ambiguous and needed more than one person: a production defect, an unclear client requirement, or an integration that failed intermittently. State the problem and your role in two sentences.
  2. Show your method in sequence: clarify the goal and constraints, break the problem into parts, assign or take parts, share what you learn quickly, and decide using evidence such as logs, a small prototype or a benchmark rather than opinion.
  3. Include a disagreement. Describe the two positions fairly, how you tested them, and how the group settled, including the case where your own view lost. This connects to the Group Discussion style in which agreement is built by listening.
  4. Say how you communicated: a short written summary of the plan, updates when blocked, and code review as a place to resolve design questions. If a non-technical stakeholder was involved, mention how you explained trade-offs to them.
  5. Finish with the result and one process change you kept. Mistake that sinks it: a hero story in which teammates are obstacles, or a generic list of steps with no real incident.

Follow-up

  • What did you do when a teammate disagreed with your approach and you could not settle it by discussion?
  • How did you decide when to stop investigating and ship a workaround?
  • Tell me about a time a teammate was stuck. What did you do and what did you learn?

How did you learn about this opening?

Medium · Behavioral & Critical Thinking

Approach

  1. Answer directly in two or three sentences with the true source: a referral, a job board, a campus drive, a recruiter message or a company page. Name the source. Inventing a story is easy to catch with one follow-up.
  2. Add the reason the opening caught your attention, linked to something you can check: the Java or C++ and SQL fundamentals the role lists, or exposure to Liferay, Salesforce, React or Node.js that you have already touched.
  3. If a person referred you, say who and what they told you about the work, without claiming facts about the company you have not verified.
  4. Close with a bridge to the conversation: one sentence on what you hope to learn or build in the role. Keep the whole answer under a minute.
  5. Mistake that sinks it: flattery with no content, or a long autobiography that never says how you heard about the job.

Follow-up

  • What do you already know about the kind of projects this team delivers?
  • Why this role over the other offers or openings you are considering?
  • Which part of the platform or tool list would you need the most time to learn, and how would you start?

What are your professional strengths and weaknesses?

Medium · Behavioral & Critical Thinking

Approach

  1. Choose two strengths that matter for this role and attach evidence to each, such as writing SQL that fixed a slow report, or explaining technical choices to a non-technical person. A strength without a proof point is only an adjective.
  2. Choose one genuine weakness that does not disqualify the role: for example, limited experience with Liferay or Salesforce, hesitation in group discussion, or a habit of over-polishing code. Avoid disguised strengths such as 'I work too hard'.
  3. Show what you are doing about it with a visible, recent action: a trial Salesforce org you have been building in, a timed practice schedule, or asking for earlier code review. Give the result so far, even if small.
  4. Keep the answer balanced: roughly half on strengths, a quarter on the weakness, a quarter on the fix. Tie the closing sentence back to the work the role involves.
  5. Mistake that sinks it: a weakness you immediately dismiss, or one so central to the role, such as 'I do not like debugging', that it ends the conversation.

Follow-up

  • Can you give an example of when that weakness affected your work?
  • How would a teammate or mentor describe you, and would they agree with what you just said?
  • What is the next concrete step you are taking to improve on it?