Amrita University Software Engineer Interview Guide

The 60-second brief

Amrita University is a multi-campus university in India. Candidates describe the Software Engineer role as building and maintaining the systems used by its students, faculty and administrative staff, including research data management, with work that ranges from web development and system support to 5G software development and digital circuit design. Reported responsibilities include taking small and medium projects from design through deployment, keeping existing web and software systems stable, integrating new features alongside other teams, and documenting system architecture and code changes. That spread explains the question mix: next to programming, SQL and JavaScript, candidates report digital electronics and microprocessor questions even for software positions.

This guide is for candidates applying to a Software Engineer position at Amrita University, whether on the web and systems side or on a hardware-adjacent track such as 5G software or digital circuit design. It covers the six stages candidates report, answer approaches and likely follow-ups for all ten reported questions (combinational vs sequential circuits, latch vs flip-flop, call by value vs reference, SQL, OOP principles, JavaScript placement, microprocessor interrupts, resume walkthrough, education and motivation), and a seven-day plan that splits time between fundamentals, timed aptitude practice and your project story.

Candidates report six stages over roughly 4-6 weeks: Application Review, Online Aptitude Test, Technical Group Discussion, One-on-One Technical Interview, Senior Leadership Interview and Final HR Review. Not every candidate sees every stage: the aptitude test is described as possible rather than certain, and the senior leadership conversation as reserved for high-level roles.

Focus areas

• Combinational Circuits
• Sequential Circuits
• Latch vs Flip-Flop

Overview

The reported questions fall into three groups. Digital logic and microprocessors: combinational vs sequential circuits, latches vs flip-flops, and the most common interrupt signal. Programming and web fundamentals: call by value vs call by reference, OOP principles, what SQL is and how it works, and where JavaScript belongs in an HTML file. Resume-based: a project walkthrough, your highest level of education, and what draws you to Amrita University. The topics candidates report lean toward digital design (combinational and sequential circuits, latch vs flip-flop, VLSI fundamentals, digital design concepts), so if your background is purely web or application development, that is the gap to close first. Day 1 and day 2 of the plan cover the logic topics, including a transistor-level VLSI refresher.

Most of these are definition-style questions, and a bare definition is the weakest possible answer. For each one, prepare four layers: a one-sentence definition, a concrete example (a full adder, a D flip-flop, a swap function, a JOIN with GROUP BY), the trade-off that makes the distinction matter, and one edge case such as the invalid state of an SR latch, Java passing object references by value, or a script in the head that runs before the DOM exists. Candidates also report basic data structures and algorithms questions and scenarios such as optimizing a given code snippet or comparing memory management in a project's architecture with standard models, so practise writing and improving short programs by hand, not only explaining concepts.

Candidates report that project work on the CV becomes the starting point for technical questions, and that academic background is reviewed at application and asked about directly. Treat every technology on your CV as something you may need to explain one level deeper than you wrote it. The aptitude stage is reported to cover aptitude-style math and logic, which is speed practice rather than theory, and the group discussion is reported to assess technical knowledge together with teamwork, which rewards a clear, structured contribution over volume.

The Amrita University interview process

The stages below are what candidates describe, not a published process, and candidates report that the formats vary by department and seniority.

Application Review

Candidates report that the process opens with a review of the application and academic background. Because candidates also report that project work becomes the starting point for later technical questions, make the CV state your degree, the projects you built, what you personally did on each, and which kind of work you are aiming at (web and systems, 5G software, or circuit design).

What to demonstrate

• The application as you submit it
• Academic background and highest qualification

How to prepare

• Rewrite each project line as problem, your contribution, stack, result, using 'I' rather than 'the team'.
• Remove any technology from the CV you cannot explain one level deeper; every listed item can become a technical question later.
• State your degree, specialization, institution and year plainly, and add relevant coursework (digital design, microprocessors, DBMS, web) if you are applying to a matching track.

Online Aptitude Test

Candidates report an online aptitude test that may be part of the process, used to check basic skills; the reported evaluation areas include aptitude-style math and logical reasoning. These are standard problem types where practice matters more than depth, so timed sets are a sensible way to prepare.

What to demonstrate

• Quantitative aptitude (arithmetic and math reasoning)
• Logical and analytical reasoning

How to prepare

• Work timed mixed sets of percentages, ratios, profit and loss, time and work, and time-speed-distance problems, and log which types cost you the most.
• Practise logical reasoning formats: number and letter series, coding-decoding, blood relations, syllogisms and seating arrangements.
• Review your error log at the end of each set and redo only the missed types until they stop recurring.

Technical Group Discussion

Candidates report a technical group discussion where participants talk through a topic together, assessing both technical knowledge and teamwork; candidates also report it appears mainly for some specialized roles. To approach it, contribute one precise technical point early, build on or correct others by name and with reasons, and offer a short summary near the end that pulls the threads together.

What to demonstrate

• Technical knowledge expressed accurately in discussion
• Teamwork, as candidates report it is assessed alongside technical knowledge

How to prepare

• Pick two fundamentals from this guide (for example latch vs flip-flop, or call by value vs reference) and practise explaining each to a peer in a few sentences with one example.
• Run a mock discussion with two or three friends on a technical topic and practise one opening point, one build-on, and one closing summary.
• Prepare a polite phrasing for correcting a wrong claim with a reason, for example 'I would add that a latch is level-sensitive, so...'.

One-on-One Technical Interview

Candidates report this as a face-to-face technical conversation that includes coding. Reported evaluation areas across the loop include basic data structures and algorithms, the hardware/software interface (circuits, microprocessors, interrupts) for some roles, and JavaScript and SQL practice, plus scenarios such as optimizing a code snippet or discussing memory management in your project's architecture. Candidates do not say which reported questions come up in this stage, so rehearse all of the technical ones and be ready to write code by hand.

What to demonstrate

• Basic data structures and algorithms, as reported across the loop
• Hardware/software interface topics for some roles
• JavaScript and SQL practice

How to prepare

• Write short programs by hand on arrays, strings, linked lists and stacks, then state their time and space complexity and one optimization.
• For each technical question in this guide, practise the four layers: definition, example, trade-off, edge case.
• Pick one project and prepare a memory and performance discussion: what is allocated where, what you would optimize first and how you would measure it.

Senior Leadership Interview

Candidates report that some high-level roles add a conversation with senior staff or faculty. Nothing reported says what is covered, so use the reported resume-based questions on projects, education and motivation as rehearsal material, and make your explanations understandable to someone outside your exact specialty.

What to demonstrate

• Applicability: reported only for high-level roles, so ask the recruiter whether it applies to your position
• Content: not reported, so confirm who attends and what the conversation covers

How to prepare

• Prepare a version of your strongest project explanation that a faculty member from another department could follow, with one sentence on why it mattered.
• Write down a specific answer to why this role at Amrita University, tied to the track you applied for (web and systems, 5G, or circuit design).
• Prepare two questions about the team's current systems or research support work to ask at the end.

Final HR Review

Candidates report a final HR review that covers the outcome and next steps. Treat it as the point to confirm details rather than as another technical round: which department or track the offer is for, the joining timeline, and any open questions from earlier stages.

What to demonstrate

• Reported scope: the outcome and next steps
• Things for you to confirm: role, department, track and joining logistics

How to prepare

• List the facts you need confirmed in writing: department, track, start date and location.
• Keep your education and project facts consistent with what you said in earlier stages and on the CV.
• Prepare a short, factual answer on your notice period or availability.

Where candidates lose points

Explaining latch vs flip-flop or combinational vs sequential circuits with only a one-line definition and no circuit, timing or example.

For each digital logic question, be able to sketch the circuit (cross-coupled NOR gates, master-slave D flip-flop, a counter) and state one timing fact such as setup and hold time or the SR forbidden state. Practise drawing these on paper, not just reading them.

Saying Java or Python pass objects by reference.

State that both pass by value, where the value for an object is a reference, and back it with a two-line example: mutating the object is visible to the caller, reassigning the parameter is not. Contrast with C++ references and C pointers.

Answering 'What is SQL' with a dictionary definition and no query.

Have a small schema in your head (students, courses, enrollments) and write a JOIN with GROUP BY on demand. Know the command categories, the logical clause order, WHERE vs HAVING, and what an index costs on writes.

Listing project technologies on the CV that you cannot explain one level deeper.

Candidates report that project work leads into technical questions. Go through your CV line by line and, for each technology, prepare why you chose it, one problem it caused and how you solved it; remove anything you cannot defend.

In the technical group discussion, either talking over others or saying nothing technical.

Bring one precise point early, build on someone else's point by name, correct an error with a reason rather than a dismissal, and offer a short summary near the end. Rehearse this pattern in at least one mock discussion.

Questions & practice

Call by value vs call by reference: what is the difference?

Medium · Technical Fundamentals

Approach

1. Define both: call by value copies the argument into the parameter, so changes inside the function do not affect the caller; call by reference passes an alias to the caller's variable, so changes are visible to the caller.
2. Use the swap example: in C, swap(int a, int b) does nothing for the caller, swap(int *a, int *b) works by passing addresses by value; in C++, void swap(int& a, int& b) is true pass by reference.
3. Correct the common misconception for managed languages: Java is always pass by value, but for objects the value is a reference, so mutating the object is visible to the caller while reassigning the parameter is not; Python behaves the same way (call by sharing).
4. State the trade-off: by value is safer but copies large structs or objects; by reference avoids the copy, and C++ const T& gives that efficiency without allowing modification.
5. Cover the edge cases: aliasing when the same variable is passed twice (an XOR swap with both references pointing at one variable zeroes it) and returning a reference to a local variable, which dangles.

Follow-up

• Is Java pass by reference? Show a short example that proves your answer.
• Why would you pass a large object as const reference in C++ rather than by value?
• What does a pointer-based swap in C actually pass to the function?

Track a rolling failure rate per destination for circuit decisions

Easy · sliding window · ring buffer · circuit breaker

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

Approach

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

Follow-up

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

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?

What is SQL and how does it function in database management?

Medium · Technical Fundamentals

Approach

1. Define it: SQL is a declarative language for relational databases; you state what result you want and the database engine decides how to get it.
2. Name the sublanguages with one statement each: DDL (CREATE, ALTER, DROP), DML (SELECT, INSERT, UPDATE, DELETE), DCL (GRANT, REVOKE) and transaction control (COMMIT, ROLLBACK).
3. Explain how a query actually runs: the engine parses it, the optimizer picks a plan (index lookup or full scan, join order and method), and the executor returns rows; the logical clause order is FROM and JOIN, WHERE, GROUP BY, HAVING, SELECT, ORDER BY, LIMIT.
4. Ground it with a small schema such as students, courses and enrollments, and write a JOIN with GROUP BY and COUNT to show enrollments per course, including a LEFT JOIN for courses with zero students.
5. Close with what the DBMS guarantees around SQL: constraints (primary key, foreign key, unique, not null) and ACID transactions, plus the cost of an index: faster reads, slower writes and extra storage.

Follow-up

• What is the difference between WHERE and HAVING?
• Compare DELETE, TRUNCATE and DROP.
• On the students, courses and enrollments schema, find the course with the second-highest enrollment count using DENSE_RANK or a subquery with MAX, and say how each handles ties.

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?

What is the difference between Combinational and Sequential Circuits?

Medium · Technical Fundamentals

Approach

1. Define both: a combinational circuit's output depends only on its current inputs, with no memory; a sequential circuit's output depends on current inputs and stored state, so it has memory elements (latches or flip-flops) and usually a clock.
2. Give examples on each side: adders, multiplexers, decoders, encoders and comparators are combinational; registers, counters, shift registers and finite state machines are sequential.
3. Contrast how each is described: a truth table and Boolean expressions for combinational logic, a state table or state diagram (Mealy or Moore) for sequential logic.
4. Add the timing difference: combinational logic is limited by propagation delay and can glitch (hazards); synchronous sequential logic must meet setup and hold times, and the clock period must cover clock-to-Q delay plus the combinational path plus setup time.
5. Cover the edge cases: sequential circuits can be asynchronous (no clock, like an SR latch or ripple counter), and feeding a combinational output back into its input creates state, which makes the circuit sequential.

Follow-up

• Design a 2-bit synchronous up-counter: what is the state table and what are the flip-flop input equations?
• What is the difference between a Mealy and a Moore machine, and which reacts to an input change sooner?
• What limits the maximum clock frequency of a sequential circuit?

Can you explain the difference between a latch and a flip-flop?

Medium · Technical Fundamentals

Approach

1. Lead with the core distinction: a latch is level-sensitive (transparent while its enable is active, so the output follows the input), while a flip-flop is edge-triggered and samples its input only on a clock edge.
2. Show the construction: an SR latch from two cross-coupled NOR or NAND gates, a gated D latch, and a D flip-flop built as a master-slave pair of D latches on opposite clock phases.
3. Mention the SR latch invalid input (S=R=1 for the NOR version) and how JK flip-flops resolve it (J=K=1 toggles) and how a T flip-flop toggles on T=1.
4. Give the trade-off: latches use fewer transistors and allow time borrowing, but transparency lets data race through and complicates timing analysis, which is why synchronous designs mostly use flip-flops.
5. Name the shared hazard: violating setup or hold time can leave either element metastable, typically mitigated with a two-flip-flop synchronizer when crossing clock domains.

Follow-up

• Draw an SR latch with NAND gates and give its truth table, including the forbidden input.
• Why does a synthesis tool warn about an inferred latch, and what in HDL code usually causes it?
• What is metastability, and why does a two-stage synchronizer reduce rather than eliminate it?

What is OOPS and can you explain its core principles?

Medium · Technical Fundamentals

Approach

1. Name the four principles with one line each: encapsulation (bundle data with the methods that guard it, using access modifiers), abstraction (expose what an object does, hide how), inheritance (reuse and extend a parent type), polymorphism (one interface, many implementations).
2. Use one running example for all four, such as an abstract Shape with area() implemented by Circle and Rectangle, with private fields and validated setters.
3. Split polymorphism correctly: compile-time through method overloading, runtime through overriding resolved by dynamic dispatch (virtual functions in C++, all non-static, non-final, non-private instance methods in Java).
4. Give the design trade-off: deep inheritance hierarchies couple classes tightly, so composition is often preferred when the relationship is has-a rather than is-a.
5. Cover multiple inheritance: the diamond problem, which C++ handles with virtual inheritance and Java avoids for classes by allowing one superclass. Since Java 8 the diamond returns when two interfaces share a default method; the class must override it and can pick one version with X.super.method().

Follow-up

• What is the difference between overloading and overriding?
• Two interfaces define the same default method and a class implements both: what happens, and how do you resolve it?
• Can a constructor be overridden or made virtual, and why not?

Which is the most accurate place to place the JavaScript code in a file?

Medium · Web Development & Systems

Approach

1. Give the direct answer: either just before the closing </body> tag, or in the <head> with the defer attribute, ideally as an external .js file rather than inline code.
2. Explain why: a plain <script> in the head blocks HTML parsing while it downloads and runs, delaying rendering, and any code that queries elements fails because those elements do not exist yet.
3. Contrast defer and async: defer downloads in parallel and runs after parsing in document order; async runs as soon as it downloads, in no guaranteed order, which suits independent scripts such as analytics; type="module" scripts are deferred by default.
4. Mention the external-file benefits: browser caching across pages, separation of markup and behaviour, and easier maintenance.
5. Cover the edge case: if code must run early but touch the DOM, wrap it in a DOMContentLoaded listener.

Follow-up

• What is the difference between async and defer?
• What happens if a script in the head calls document.getElementById for an element further down the page?
• When would inline JavaScript still be acceptable?

What is the most common interrupt signal used in microprocessors?

Medium · Web Development & Systems

Approach

1. Handle the ambiguity by naming the general-purpose answer: INTR, the maskable interrupt request line most peripherals use (present on the 8085 and 8086), acknowledged by the processor through INTA.
2. Show the classification around it: maskable vs non-maskable (NMI on the 8086, TRAP on the 8085), hardware vs software interrupts (INT n, RST n), vectored vs non-vectored.
3. Give the 8085 priority order as a concrete detail: TRAP, then RST 7.5, RST 6.5, RST 5.5, and INTR lowest; on the 8086 the interrupt vector table holds 256 four-byte entries in the first 1 KB of memory.
4. Walk through servicing an interrupt: finish the current instruction, check the interrupt line, acknowledge, push the program counter (and flags on the 8086), jump to the service routine, then return and restore state. Tie the return to the processor: RET on the 8085, which has no RETI, and IRET on the 8086; RETI belongs to the 8051 and Z80.
5. Close with the trade-off against polling: interrupts avoid wasting CPU cycles checking devices, at the cost of context-switch overhead and latency concerns for very frequent events.

Follow-up

• What is the difference between a maskable and a non-maskable interrupt, and what would you use NMI for?
• Why is TRAP given the highest priority on the 8085?
• When would polling be a better choice than interrupts?

One log partition stops advancing while the others drain

Easy · poison message · head-of-line blocking · consumer lag

Search results for a subset of tenants are hours stale; the rest are current. The projection consumer reports lag of zero on 15 of 16 partitions and 400,000 on one. Its error rate is flat and its CPU is idle. outbox_event has no pending rows older than a second, so the relay has published everything it holds. Identify the mechanism, give the ordered checks, and state what you do in the first ten minutes versus what you change permanently.

Approach

1. Read the lag distribution first. A slow consumer lags everywhere; zero on fifteen partitions and 400,000 on one is not throughput. Idle CPU on the stuck partition means the consumer is not advancing its offset at all, which points at one message it cannot get past rather than at a rate problem.
2. Exonerate the producer before touching the consumer. No pending outbox rows older than a second means the relay published, so the event exists in the log. This separates never sent from sent and never applied, which are different code paths and usually different owners.
3. Read the message at the stuck offset and the handler's log lines for its event_id. A flat error rate with no progress has two explanations and you must distinguish them: the handler is throwing and the retry loop is swallowing it, or the handler is blocking on something and never returning. Idle CPU with no error lines favours the second.
4. Mitigate before diagnosing further. Move the offending event to a dead-letter store and commit the offset past it. Adding consumers does nothing here, because a partition is consumed by exactly one member of the group, and the blast radius is every aggregate hashed to that partition, not only the aggregate that produced the bad event.

Follow-up

• The dead-lettered event carried aggregate_version 7 and the projection had applied 6. What must the replay do differently if 8 and 9 landed in the meantime?
• How do you show staleness to the user while the partition is behind, given the API already returns the projection's watermark?

Suggested practice checklist

Each day targets one cluster of the reported questions or one reported stage, ending with something you can speak or show. Digital logic comes first because it is the least familiar ground for most software candidates.

Day 1 — Combinational and sequential logic

• Write truth tables and gate diagrams for a half adder, full adder and 4-to-1 multiplexer.
• Write the state table and flip-flop equations for a 2-bit synchronous counter, and label it Mealy or Moore.
• Answer the combinational vs sequential question aloud using the four layers: definition, examples, timing difference, edge case.

Deliverable: Hand-drawn adder, multiplexer and counter designs plus a recorded spoken answer on combinational vs sequential circuits.

Day 2 — Latches, flip-flops, timing and VLSI basics

• Draw SR latches in NOR and NAND form with truth tables, then a gated D latch and a master-slave D flip-flop.
• Write a comparison of SR, JK, D and T flip-flops, including the forbidden state and toggle behaviour.
• Explain setup time, hold time and metastability, and why a two-flip-flop synchronizer helps.
• Cover VLSI fundamentals: draw a CMOS inverter and NAND/NOR gates at transistor level, then explain static vs dynamic power and noise margin.

Deliverable: A one-page latch and flip-flop sheet with diagrams, a CMOS gate sketch with power and noise-margin notes, and a spoken latch vs flip-flop answer that covers metastability.

Day 3 — Programming fundamentals: call semantics and OOP

• Write swap in C with values and with pointers, and in C++ with references; run them and note which change the caller.
• Write a short Java or Python example proving that object references are passed by value.
• Implement a Shape hierarchy showing encapsulation, abstraction, inheritance, overloading and overriding, and explain each in one sentence.

Deliverable: Three runnable swap programs, a pass-by-value proof snippet and a Shape class hierarchy with a spoken OOP explanation.

Day 4 — SQL and JavaScript placement

• Create a students, courses and enrollments schema and write joins, GROUP BY with HAVING, a LEFT JOIN for courses with no students, and a second-highest enrollment count query.
• Work the window-function practice question on version gaps and relay lag as a stretch exercise.
• Build a small HTML page that loads one script in the head without defer, one with defer and one with async, and note when each runs and which can access the DOM.

Deliverable: A SQL file with five working queries, a window-function solution and an HTML test page with notes on script execution order.

Day 5 — Microprocessor interrupts and aptitude speed

• Write the 8085 interrupt priority order, the 8086 NMI and INTR pins and the interrupt vector table layout from memory, then check them.
• Write the step-by-step interrupt service sequence and a comparison of polling vs interrupts.
• Complete a timed mixed aptitude set (quantitative and logical reasoning) and log every missed problem by type.

Deliverable: An interrupt summary sheet, a spoken answer on the most common interrupt signal and an aptitude error log by problem type.

Day 6 — Hand coding and debugging for the one-on-one interview

• Solve basic data structures problems by hand (array reversal, string palindrome, linked list reversal, balanced parentheses with a stack) and state complexity for each.
• Work the rolling failure-rate practice question and explain how you would make it faster or use less memory.
• Write your project debugging story: symptom, narrowing steps, root cause, fix, verification.

Deliverable: Four handwritten solutions with complexity notes, a rolling-window solution with an optimization note and a written debugging story.

Day 7 — Resume, education, motivation and a mock group discussion

• Rehearse the resume walkthrough aloud with two or three projects, each showing your contribution and one technical decision.
• Write factual answers on your highest education and on what draws you to this role, tied to the track you applied for.
• Run a mock technical group discussion with friends on one topic from this week and practise an opening point, a build-on and a summary.

Deliverable: A recorded resume walkthrough, written education and motivation answers, and notes from one mock group discussion.

Behavioural preparation

The behavioral and resume questions candidates report focus on your projects, your education and your reasons for wanting the role, and candidates report that project answers often lead straight into technical questions. Prepare stories where your own contribution is clear and where you can go one level deeper on the technology involved.

1. Describe a time you encountered a bug in a project and how you debugged it.

Can you walk me through your resume and the projects you contributed to?

Medium · Behavioral & Resume-Based

Approach

1. Structure the walkthrough: one line on education, then two or three projects in order of relevance, then one sentence linking them to the track you applied for.
2. For each project cover the problem, what you personally built (say 'I'), the stack, one hard technical decision and its alternative, and a measurable result.
3. Prepare one level deeper on every technology you mention, because candidates report that projects are used as a springboard for technical questions.
4. Keep a debugging story ready from one project: symptom, how you narrowed it down, root cause, fix and how you verified it.
5. The mistake that sinks this answer is a list of tools with no visible ownership, or a group project where you cannot separate your part from the team's.

Follow-up

• Why did you choose that database or framework over the alternatives?
• Describe a bug you hit in that project and how you debugged it.
• What would you change if you rebuilt it today?

What is your highest level of education?

Medium · Behavioral & Resume-Based

Approach

1. Answer the fact first and precisely: degree, specialization, institution and year of completion (or expected completion).
2. Add one or two items that connect your education to the role: relevant coursework (digital design, microprocessors, DBMS, web technologies), a thesis or a final-year project.
3. If you hold a postgraduate degree, summarize the thesis problem and your result in plain terms; if you do not, point to relevant project experience, since candidates report that a postgraduate degree or relevant project experience is considered helpful for more senior work.
4. Explain any gap or change of field briefly and factually, without apologizing, and make sure dates match your CV.

Follow-up

• Tell me about your final-year project or thesis.
• Do you plan to pursue further study, and how would it fit with this role?
• Why did you choose that specialization?

What excites you about working at Amrita University?

Medium · Behavioral & Resume-Based

Approach

1. Name the specific work you want, tied to the role as candidates describe it: systems used by students, faculty and administrative staff, research data management, or the 5G software and digital circuit design tracks.
2. Connect it to evidence from your own background: a project, course or internship that shows you have already done related work.
3. Say what you would contribute in the first months, for example stabilizing an existing web system or documenting an architecture, rather than only what you would gain.
4. Avoid answers built on reputation or convenience alone; they fit any employer and say nothing about you.

Follow-up

• Which department or track interests you most, and why?
• How would you work with faculty who are not engineers?
• Where do you see yourself in a few years in this role?