Anara Software Engineer Interview Guide

The 60-second brief

Anara is described to candidates as an energy company. The Software Engineer role centres on firmware and embedded software for energy storage and power-management products: battery management systems, motor controls and power electronics, used in consumer, industrial and aerospace settings. In practice that means C code that runs close to the hardware, reads sensors, drives actuators and relays, and reports state such as charge and battery health. The role description also lists work alongside electrical engineers, hardware designers and quality assurance teams, plus design reviews, documentation written to industry standards, and analysis of performance data from systems already deployed.

This guide is for candidates applying to Anara as a Software Engineer, from recent graduates (often hired as Graduate Engineer Trainees) to mid-level engineers with a few years in embedded or firmware work. It covers the four reported rounds, the Embedded C and hardware-interface questions, the battery, power and motor questions, the project deep dive, and the HR and Personal Interview.

Candidates report four rounds over about 3-5 weeks: application review, an online written test, a technical interview, and an HR and Personal Interview. The technical and HR stages are reported to run over one or two days, either virtually or face to face.

Focus areas

• Electrical Engineering Core Concepts
• Embedded C
• Written Tests (Technical + Aptitude)

Overview

The Software Engineer role at Anara is firmware work on energy hardware, not web or mobile development. The requirements candidates describe put Embedded C first, then microcontroller architecture, hardware-software interfacing, basic circuits, battery behaviour and energy use. Battery management systems, power electronics, control systems and motor starting methods are listed as nice-to-have. So you are preparing to explain code in terms of what it does to a battery, a motor or a sensor, not only what it does to memory.

The reported questions fall into four groups. Embedded C and hardware interfacing covers the volatile keyword, memory leaks on a small microcontroller, configuring an ADC, SPI versus I2C, and a hardware-or-software debugging story. Battery technology and power systems covers how a battery works, types of energy storage, monitoring an industrial backup power system, motor starting methods, and control systems that regulate power output. The project deep dive covers your most complex embedded project or internship, its technical challenges, applying a college project to industry, aerospace technology such as ISRO, and how standards and auditing shape the way you write software. The HR group covers your background, why Anara, explaining a technical idea to a non-technical person, career goals and pressure. None of the reported questions is an algorithm puzzle, so depth in C and in the physical system will serve you better than grinding generic coding problems.

The reported example scenarios show the style to practise: write a program that watches a battery cell voltage and raises an alert below a threshold, compare polling and interrupts on a power-constrained device, explain how a motor starting method changes the initial power draw and what software could do about it, name the metrics you would track for a remote energy storage facility, and compare battery requirements for aerospace and for automotive use. In each, finish by saying what your choice does to the whole system: battery life, heat, safety. Candidates also report an online written test with technical, logical-reasoning and quantitative-aptitude questions before any interview, so schedule time for aptitude practice as well as for C.

The Anara interview process

Candidates describe four stages, from an online application through a written test and a technical interview to an HR and Personal Interview. Each entry below says what is reported for that stage and how to prepare for it.

Application Review

Reported as an online application followed by a resume screen. Nothing more is reported for this stage, so the resume carries your whole case. The role description stresses Embedded C, microcontrollers, circuits and battery basics, and candidates report that the later technical stage goes through past projects, so write each bullet so that it can survive follow-up questions.

What to demonstrate

• The qualifications your resume shows at a glance
• How clearly your embedded, firmware or electronics experience is stated

How to prepare

• Rewrite each project bullet to name the microcontroller, the peripherals or protocols you used, and what you personally built.
• Move Embedded C, interfacing and any battery, motor or power-electronics exposure near the top, since those are the listed must-have and nice-to-have skills.
• Remove any tool or topic you could not discuss for five minutes of questions.

Written Test

After the resume screen, candidates report an online test that mixes subject questions with reasoning and aptitude. The subject part is described as electrical, electronics and software basics, partly in multiple-choice form, alongside logical-reasoning and quantitative sections. Practise fast recall of fundamentals and clean arithmetic.

What to demonstrate

• Basic electrical, electronics and software engineering knowledge
• Logical reasoning: patterns, sequences and deduction
• Quantitative speed and accuracy

How to prepare

• Revise Ohm's law, power as voltage times current, series and parallel networks, and basic battery capacity arithmetic, then solve a mixed set without a calculator where you can.
• Practise number series, pattern puzzles, percentages, ratios and work-rate problems, and keep an error log of what you got wrong and why.
• Review C output-prediction items on operator precedence, integer promotion and sign extension, sizeof on an array versus a pointer, and shift-and-mask results; leave volatile for the Day 3 snippets.
• Practise full sets in one sitting so that speed and accuracy are trained together.

Technical Interview

Once past the written test, candidates move to the core interviews, which they report taking place over one or two days, online or in person. The reported topics are the projects on your resume, engineering fundamentals, embedded systems, batteries and how the technology is used in practice. Candidates also list Embedded C, microcontroller interrupts and timers, buses such as I2C, SPI and UART, motor basics, and awareness topics such as aerospace technology, standards and auditing among the areas covered.

What to demonstrate

• Embedded C and microcontroller fundamentals
• Understanding of batteries, motors and basic power systems
• Depth of knowledge about your own projects and the decisions behind them
• Ability to connect textbook concepts to industrial use

How to prepare

• Practise the reported Embedded C topics aloud: volatile, avoiding memory leaks on a small microcontroller, ADC configuration, and SPI versus I2C.
• Prepare one-page answers for the battery, energy storage, backup power, motor starting and control-system topics, each ending with an industrial example.
• Build a fact sheet for every resume project: goal, hardware, your contribution, the hardest problem, the fix, and how it would scale to an industrial setting.
• Read up briefly on high-reliability systems, aerospace use and how standards and audits change coding and documentation habits, so a niche question does not stall you.

HR and Personal Interview

The last stage is the HR and Personal Interview. Reported topics include communication, motivation, strengths, family background and what you know about the company's industry, alongside personality and fit. Candidates report that results often arrive within a few days of this round. Treat it as a speaking exercise: short, structured answers with specific examples.

What to demonstrate

• Communication: explaining ideas simply
• Career motivation and goals
• Fit with the team and the role as you describe it

How to prepare

• Write and rehearse a self-introduction that moves from background to embedded projects to what you want next, with a short, factual line on family background.
• Prepare a why-Anara answer built on what you can state accurately about firmware for battery and power systems, matched to your own experience.
• Rehearse one story each for explaining a technical idea to a non-technical person, a hardware-or-software debugging case, and working under a deadline.
• Practise out loud, since written notes rarely survive contact with a live conversation.

Where candidates lose points

Describing a project at headline level, with no microcontroller, peripheral, protocol or personal contribution named

Candidates report that the technical stage works through resume projects. For each project write a fact sheet: hardware, the interfaces used, what you built, the hardest problem and its fix, and what you would change. Remove any bullet you cannot defend in detail.

Treating the role as pure software and answering Embedded C questions without mentioning the hardware effect

For a battery-voltage monitor, talk about sensor noise, debouncing, hysteresis around the threshold and what the alert does to the system. For polling versus interrupts, bring in power consumption. End each answer with the effect on battery life, heat or safety.

Reciting textbook definitions of volatile, SPI versus I2C or how a battery works, with no use case

Pair every definition with an example: a status register or an interrupt flag for volatile, a sensor bus choice for SPI versus I2C, a backup power system for the battery question. A definition plus a decision you made shows understanding.

Skipping preparation for the online written test, which comes before any interview

Practise mixed sets of basic electrical, electronics and C questions plus number series, logical reasoning and quantitative aptitude, and review your error log. Failing this stage means the technical stage never happens.

Giving a generic answer to the HR group: a rambling family background, or a why-Anara answer that fits any employer

Rehearse a short self-introduction that ends on your embedded work, a family line that stays factual and brief, and a why-Anara answer tied to firmware for battery and power systems and one thing you have built that matches.

Questions & practice

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?

Collapse a redelivered event batch into per-aggregate high-water marks

Easy · hashing · at-least-once · aggregation

You drain a batch of up to 5,000,000 events, each (aggregate_id BIGINT, aggregate_version INT, event_type, payload). The log guarantees order within one aggregate only; the batch merges 64 partitions, and a relay failover has redelivered a range, so an older version for an aggregate can appear after a newer one. Given a map of last_applied_version per aggregate, produce the events worth applying, at most one per (aggregate_id, version), plus the count discarded. Target O(n) time. State the memory for 2,000,000 distinct aggregates and what you do when it does not fit.

Approach

1. One pass, one hash map from aggregate_id to the highest version kept, and a discard counter. An event whose version is at or below last_applied_version for its aggregate is dropped without further work, which is the whole reason the event carries its version rather than a delta. O(n) expected time, O(d) space in distinct aggregates.
2. Keep the maximum, never the last occurrence. The redelivered range means the final appearance of an aggregate in the batch can be an older version than one seen earlier in the same batch, so last-wins applies stale state over newer state and the projection regresses with no error anywhere.
3. Cost the memory instead of calling it large: an 8-byte key plus a 4-byte version is 12 bytes of payload, and an open-addressed table held at a 0.7 load factor costs roughly 17 bytes per entry before per-slot metadata, so 2,000,000 aggregates is tens of megabytes in a native layout and several times that in a runtime that boxes both key and value.
4. If the distinct set exceeds memory, partition on hash(aggregate_id) mod P and reduce each partition independently. Every event for one aggregate hashes to the same partition, so the per-partition result is exact and the merge is concatenation rather than a second reduction.

Follow-up

• The payload is a patch rather than a snapshot, so applying only the highest version loses the intermediate changes. What changes in your reduction?
• How do you detect that version 7 arrived while version 6 was never delivered, and what should the consumer do about the gap?

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?

Explain why the owner filter ignores the listing index

Medium · composite index · query plans · sort elimination

The only index on resource is (tenant_id, status, updated_at DESC, resource_id DESC). A new endpoint returns one user's resources across all statuses, newest created first: WHERE tenant_id = $1 AND owner_user_id = $2 ORDER BY created_at DESC LIMIT 20. On a tenant with 2M rows it takes 900 ms and EXPLAIN shows a sort above a large scan. Explain precisely why the existing index cannot serve it, give the index that can, and state which of these the new index still will not help: owner_user_id alone across tenants; the same query ordered by updated_at. PostgreSQL 16.

Approach

1. Separate the two jobs an index does. For filtering, a composite btree is seekable only on a left prefix, so with no predicate on status the scan can at best range over tenant_id and test owner_user_id per row; PostgreSQL 16 has no btree skip scan to jump the unconstrained column.
2. For ordering, the index is sorted by (status, updated_at) within a tenant and not by created_at, so the LIMIT cannot stop early: every matching row is read and then sorted. That is the 'Sort Method: top-N heapsort' line, and it is why the plan reads 2M rows to answer with 20.
3. Derive the replacement from the access path — equality, equality, then the ordering column: CREATE INDEX CONCURRENTLY ON resource (tenant_id, owner_user_id, created_at DESC). The scan seeks to the (tenant, owner) range and walks 20 entries in order, so the Sort node disappears along with the row-read.
4. Treat INCLUDE (title, status) as conditional, not free. An index-only scan still visits the heap for any row whose page is not marked all-visible, so on a table taking 1.2k writes/second the win depends on autovacuum keeping the visibility map current, and the wider index costs more on every insert.

Follow-up

• 90% of rows are status='active'. Would a partial index WHERE status = 'active' change your answer, and for which of the three queries?
• A dashboard runs this for 40 owners in one page load. What changes about the design?

Keep soft-deleted accounts from blocking re-registration

Easy · soft delete · unique constraints · engine differences

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

Approach

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

Follow-up

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

Explain the use of the volatile keyword in Embedded C.

Medium · Embedded C and Hardware Interfacing

Approach

1. Define it precisely: volatile tells the compiler that every read and write of the object is an observable side effect, so it must reload the value from memory on each access and may not cache it in a register, merge accesses or delete them.
2. Give the three classic uses: memory-mapped peripheral registers (status and data registers that hardware changes), flags shared between an ISR and the main loop, and buffers written by DMA or another core. On a core with a data cache, volatile does not make a DMA buffer coherent: the CPU can still read stale cache lines, so the buffer also needs a cache clean before a DMA transmit and an invalidate after a DMA receive (for example around a DMA-fed ADC buffer), or it must sit in a non-cacheable memory region.
3. Show the bug it prevents: with a plain bool done set in an ISR, while (!done) {} can compile at -O2 into an infinite loop because the compiler hoists the read out of the loop; declaring volatile bool done forces a fresh read each pass.
4. State what it does NOT do: it gives no atomicity and no memory barrier. count++ on a volatile is still a separate read, modify and write that an interrupt can split, and a 16-bit or 32-bit read on an 8-bit MCU can tear; guard those with a brief interrupt disable or an atomic primitive.
5. Cover the declarations: volatile uint32_t *reg is a pointer to a volatile register, uint32_t * volatile p is a volatile pointer, and const volatile fits a read-only status register that software must not write but hardware changes.

Follow-up

• Can a variable be both const and volatile, and where would you use that?
• Is a volatile flag enough to share data safely between an ISR and the main loop? What else do you need?
• Why might adding volatile to a variable fix a bug that only shows up when optimisation is turned on?

Walk me through the process of configuring an ADC (Analog-to-Digital Converter) to read a sensor value.

Medium · Embedded C and Hardware Interfacing

Approach

1. Walk the sequence in order: enable the ADC and GPIO clocks, put the pin in analog mode, set the ADC clock prescaler within the datasheet maximum, choose resolution and reference voltage, select the channel, set the sampling time, run the vendor calibration if the part has one, then enable the ADC.
2. Explain the sampling time: the sample-and-hold capacitor must settle through the source impedance, so a high-impedance source such as a resistor divider on a battery needs a longer sampling time or a buffer op-amp, otherwise readings come out low and noisy.
3. Choose how conversions start and finish: software trigger with polling of the end-of-conversion flag for a one-off reading, an EOC interrupt for occasional reads, or a timer-triggered scan with DMA into a circular buffer for periodic multi-channel sampling with almost no CPU cost.
4. Convert counts to a physical value: for a 12-bit converter, V = raw x Vref / 4096 (some references use 4095; the difference is one LSB), then apply the sensor transfer function, e.g. for a divider Vbat = Vadc x (R1 + R2) / R2.
5. Name the edge cases: Vref drift (measure the internal reference channel and correct), input above Vref or below ground (clamp and protect), noise (RC anti-aliasing filter below half the sample rate, plus averaging), and calibrate gain and offset against a known voltage.

Follow-up

• How would you sample eight channels every millisecond without loading the CPU?
• Your readings jitter by several counts. What would you check, in what order?
• How does oversampling raise effective resolution, and what does it cost?

What are the differences between SPI and I2C, and when would you choose one over the other?

Medium · Embedded C and Hardware Interfacing

Approach

1. Lay out SPI: SCLK, MOSI, MISO and one chip-select per device, push-pull lines, full duplex, no addressing and no acknowledge, a single controller, clock rates commonly in the tens of MHz, and four clock modes set by CPOL and CPHA that must match the device.
2. Lay out I2C: two open-drain lines (SDA, SCL) with pull-up resistors, 7-bit (or 10-bit) addresses, an ACK or NACK after every byte, half duplex, multi-controller arbitration, clock stretching, and speed grades of 100 kHz, 400 kHz, 1 MHz (Fast-mode Plus) and 3.4 MHz (High-speed).
3. Give the decision rule: SPI for throughput or tight timing (flash memory, displays, fast external ADCs); I2C when many slow devices must share two pins (temperature sensors, EEPROMs, fuel-gauge chips), accepting lower speed and the protocol overhead.
4. Cover the physical limits: I2C rise time depends on pull-up value against bus capacitance (400 pF is the standard limit), so long cables or many devices need stronger pull-ups or a bus buffer; SPI needs an extra GPIO per device unless the parts support daisy-chaining.
5. Mention failure handling: I2C can hang if a device holds SDA low after a mid-transfer reset, and the standard recovery is to clock SCL up to nine times until SDA releases and then issue a STOP; SPI has no ACK, so data integrity needs a CRC or a read-back check.

Follow-up

• How do you choose the pull-up resistor value on an I2C bus?
• How would you recover an I2C bus that is stuck with SDA held low?
• Where does UART fit compared with SPI and I2C?

What is a battery, and how does it fundamentally work?

Medium · Battery Technology and Power Systems

Approach

1. Define it: a battery is one or more electrochemical cells that convert stored chemical energy into electrical energy; each cell has a negative electrode (anode on discharge), a positive electrode (cathode), an electrolyte that carries ions and a separator that blocks electrons.
2. Describe discharge: oxidation at the anode releases electrons that flow through the external circuit to the cathode, where reduction takes them up, while ions move through the electrolyte to keep charge balanced; charging a rechargeable (secondary) cell drives the reactions in reverse.
3. Tie voltage to chemistry: cell voltage comes from the difference in electrode potentials, which is why nominal values differ: about 2.0 V for lead-acid, 1.2 V for NiMH, roughly 3.6-3.7 V for common lithium-ion and about 3.2 V for LFP.
4. Give the quantities firmware works with: capacity in Ah, energy in Wh (Ah x nominal V), C-rate, state of charge, state of health, and internal resistance, which makes terminal voltage sag under load (V = OCV - I x R) and rises with age and cold.
5. Close with the software view of a Li-ion cell: constant-current then constant-voltage charging, strict upper and lower voltage limits and a temperature window, because overcharge or charging below freezing can cause lithium plating and, in the worst case, thermal runaway.

Follow-up

• How would you estimate state of charge in firmware, and why is voltage alone unreliable?
• Why does a series pack need cell balancing?
• What happens inside a lithium-ion cell if it is overcharged?

Can you explain the different types of energy storage and their primary use cases?

Medium · Battery Technology and Power Systems

Approach

1. Group the types: electrochemical (lead-acid, lithium-ion and its LFP variant, NiMH, flow batteries), mechanical (pumped hydro, flywheels, compressed air), electrical (supercapacitors), thermal (molten salt, chilled water or ice) and chemical (hydrogen).
2. Compare on the properties that drive the choice: energy density (Wh/kg), power density (W/kg), round-trip efficiency, cycle life, response time, self-discharge, safety and cost per kWh.
3. Map each to a use case: lead-acid for low-cost UPS banks and engine starting; lithium-ion for EVs and portable devices where weight matters; LFP where cycle life and thermal safety outweigh energy density; flow batteries for long-duration stationary storage because power and energy scale separately.
4. Cover the power-heavy options: supercapacitors and flywheels deliver short, high-power bursts with very high cycle counts (regenerative braking, ride-through until a generator starts, frequency regulation) but store little energy.
5. Finish with grid scale: pumped hydro holds most installed grid storage capacity worldwide, while hydrogen suits seasonal storage despite low round-trip efficiency; a hybrid of a battery and a supercapacitor is a common way to split energy and power duties.

Follow-up

• Why did EVs move from lead-acid and NiMH to lithium-ion?
• For a load that needs a few seconds of high power many times an hour, would you pick a battery or a supercapacitor, and why?
• What extra monitoring does a lithium-ion bank need compared with a lead-acid bank?

How is energy utilized and monitored in an industrial backup power system?

Medium · Battery Technology and Power Systems

Approach

1. Describe the energy path: utility feeds a UPS whose rectifier charges a battery bank (VRLA lead-acid or lithium-ion); on an outage the inverter carries the load from the battery until an automatic transfer switch moves it onto a diesel generator, and an online double-conversion UPS gives zero transfer time.
2. Show the runtime calculation: runtime = usable energy x inverter efficiency / load. For a 40 kWh bank at 80% usable depth of discharge, 95% efficiency and a 10 kW load: 40 x 0.8 x 0.95 / 10 = about 3.0 hours; for lead-acid, derate further for high discharge rates (Peukert effect) and low temperature.
3. List what to monitor: per-cell or per-block voltage, string current, temperature, float voltage, state of charge, and internal resistance or impedance trend, since a rising resistance is the usual early sign of a failing VRLA cell.
4. Explain the software side: sample at a fixed rate, compare against thresholds with hysteresis and debounce so alarms do not flap, log events with timestamps, and report upstream over a protocol such as Modbus or SNMP to a supervisory system.
5. Add the operational checks: periodic capacity or discharge tests, generator start tests, and load shedding of non-critical circuits so the protected load stays within the bank's rated runtime.

Follow-up

• Which single measurement best predicts that a VRLA string will fail its next outage?
• How would you set alarm thresholds so they catch real faults without nuisance alarms?
• What changes in the monitoring if the bank is lithium-ion instead of lead-acid?

Explain the different starting methods for industrial motors.

Medium · Battery Technology and Power Systems

Approach

1. Frame the problem: an induction motor started direct-on-line draws a large inrush, commonly quoted at about 5-8 times rated current, which dips supply voltage and stresses the mechanics; every starting method trades starting torque against that inrush.
2. Direct-on-line: one contactor plus overload relay, full starting torque, highest inrush; used for small motors on a stiff supply. Star-delta: start in star so each winding sees 1/sqrt(3) of line voltage, cutting line current and torque to one third of DOL, then switch to delta; needs six leads and causes a transient at changeover.
3. Autotransformer: reduced voltage from selectable taps; line current and torque both scale with the square of the tap ratio, so it gives more torque per amp drawn than a resistor start. Rotor-resistance starting applies to slip-ring (wound-rotor) motors and gives high torque at low current.
4. Soft starter: thyristors phase-control the voltage up a ramp, then a bypass contactor takes over; it smooths current and torque but cannot give full torque at low speed. A VFD varies frequency and voltage together (V/f or vector control), starts at near-rated current with full torque and adds speed control, at higher cost and with harmonics to manage.
5. Connect it to software: sequencing and interlocks, ramp profiles, overload and phase-loss protection, and staggering motor starts so a generator or battery-backed bus never sees several inrushes at once.

Follow-up

• Why does starting torque fall with the square of the applied voltage on an induction motor?
• When would you pick a soft starter over a VFD?
• How would firmware sequence several motor starts on a generator-backed supply?

How does a control system regulate power output in an unpredictable environment?

Medium · Battery Technology and Power Systems

Approach

1. Describe the loop: sensors measure output voltage or current, the ADC samples them, the controller compares the measurement with a setpoint, and the controller output sets an actuator, typically the PWM duty cycle of a DC-DC converter or inverter; load steps, input swings and temperature are the disturbances.
2. Explain PID in that setting: proportional action reacts to present error, integral action removes steady-state error, derivative action adds damping. In discrete form it runs at a fixed sample rate well above the closed-loop bandwidth (typically 10-20x), so the sample period is short compared with the loop's response time; take the derivative on the measurement and filter it to avoid amplifying noise.
3. Handle the real-world issues: anti-windup (stop integrating or back-calculate when the output saturates), output and slew-rate limits, and feedforward from a measured disturbance such as input voltage so the loop does not wait for an error to build up.
4. Use structure for robustness: a fast inner current loop under a slower outer voltage loop, gain scheduling when plant behaviour changes with operating point, and maximum power point tracking (for example perturb-and-observe) when the source is solar.
5. Cover safety and verification: sensor plausibility checks, a defined fail-safe state on sensor loss or out-of-range readings, and tuning checked by step-response tests and stability margins rather than trial and error alone.

Follow-up

• What is integrator windup, and how would you prevent it in code?
• How would you choose the control loop's sample rate?
• What should the controller do if the voltage sensor fails or reads a frozen value?

Walk me through the most complex embedded project or internship on your resume.

Medium · Project Deep Dive and Real-World Applica

Approach

1. Open with the problem and the constraints in a few sentences: what the system had to do, the MCU and its clock and memory, power budget, timing requirements, and what was hard about it.
2. Sketch the architecture as a block diagram you can draw from memory: sensors, interfaces (ADC, SPI, I2C, UART), the firmware structure (super-loop, interrupts, RTOS tasks), actuators and any host or cloud link.
3. Make your own part explicit in first person: "I wrote the ADC sampling and filtering and the UART protocol", not a team summary, and be ready to explain every line of the resume entry.
4. Pick one decision and defend it with its trade-off: polling versus interrupts, a protocol choice, a sample rate, an MCU choice, and say what the alternative would have cost.
5. End with measured results and limits: accuracy achieved, response time, power draw, what failed in testing and what you would change, connecting it to battery or power systems only where that link is real.

Follow-up

• Why did you choose that microcontroller and that communication protocol?
• How did you test the system, and what did testing miss?
• If you rebuilt it for production, what would you change first?

What were the specific technical challenges you faced in that project, and how did you overcome them?

Medium · Project Deep Dive and Real-World Applica

Approach

1. Choose one or two real problems with a clear symptom, such as noisy ADC readings, an I2C bus that hung, a race between an ISR and the main loop, a stack overflow or a missed timing deadline.
2. Tell each as a debugging sequence: symptom, first hypothesis, the measurement used to test it (oscilloscope, logic analyser, debugger breakpoints, UART logging), what that ruled out, and the root cause you confirmed.
3. State the fix and why it addressed the cause rather than the symptom, e.g. "I moved the shared counter update into a critical section" instead of "I added a delay and it stopped".
4. Show verification: how you reproduced the fault, confirmed it no longer occurred (soak test, repeated runs, scope capture) and what you added to catch it earlier next time.
5. Be honest about anything left unsolved and what you would try next; a precise account of a partial fix holds up better under follow-up questions than a vague claim of complete success.

Follow-up

• How did you know you had found the root cause and not a coincidence?
• What process or tooling would have caught this earlier?
• Was there a challenge you did not fully solve? What would you try now?

How would you apply the technology you used in your college project to a real-life industrial application?

Medium · Project Deep Dive and Real-World Applica

Approach

1. Restate the project in one line, then name a specific industrial setting it maps to, e.g. a temperature and voltage logger becoming a battery-room or substation monitor; a vague answer about "industry" says nothing.
2. List what changes in hardware: industrial temperature-rated parts, EMI and surge protection, isolated interfaces, robust buses such as RS-485 or CAN instead of breadboard wiring, and enclosures rated for dust and moisture.
3. List what changes in firmware: watchdog timer, brown-out detection, a defined safe state on any fault, input validation, persistent event logs, and a field update path with a fallback image so a failed update cannot brick the unit.
4. Add scale and lifecycle concerns: device identity and configuration across many units, remote monitoring through a protocol such as Modbus, calibration in production, and the applicable safety or compliance standards.
5. Close with the main risk and how you would test it: environmental and long-duration soak tests, fault injection (pull a sensor, drop the supply) and a check that the system fails safe.

Follow-up

• Which single change matters most for safety, and why?
• How would you update firmware on hundreds of deployed units without bricking any?
• What tests would you run before the first field installation?

Let's talk about advanced engineering—what do you know about the technologies used in ISRO or similar aerospac

Medium · Project Deep Dive and Real-World Applica

Let's talk about advanced engineering—what do you know about the technologies used in ISRO or similar aerospace applications?

Approach

1. Be honest about the depth of your knowledge and anchor on something concrete you have read about, such as the PSLV launcher or the Chandrayaan-3 lunar landing, then move to the engineering principles that carry across aerospace.
2. Cover the environment: radiation causes single-event upsets (bit flips) and latch-up, so spacecraft electronics use radiation-tolerant parts, ECC or EDAC memory, memory scrubbing, triple modular redundancy with majority voting, and watchdogs; thermal cycling and vacuum add their own constraints.
3. Cover power: solar arrays charge batteries that carry the spacecraft through eclipses; a low Earth orbit of about 90 minutes means roughly 15-16 charge-discharge cycles per day, so depth of discharge is kept shallow to reach the required cycle life, and mass makes energy density matter.
4. Compare with automotive: automotive packs face fewer, deeper cycles, high peak power and cost pressure, while aerospace prioritises reliability, mass and qualification testing and accepts far higher cost per kWh.
5. Mention the software discipline: strict coding rules (MISRA C, or rule sets such as JPL's "Power of Ten"), no dynamic allocation after start-up, extensive simulation and hardware-in-the-loop testing, and full traceability from requirement to test.

Follow-up

• How would firmware detect and correct a bit flip in RAM?
• How do battery requirements for a satellite differ from those for an electric car?
• What is triple modular redundancy, and what does it cost?

How do industry standards and auditing impact the way you write software?

Medium · Project Deep Dive and Real-World Applica

Approach

1. Name the relevant standards accurately: IEC 61508 for general functional safety, ISO 26262 for road vehicles, DO-178C for airborne software, and coding standards such as MISRA C enforced by static analysis.
2. Explain the effect on day-to-day coding: a restricted language subset, no dynamic allocation, bounded loops and recursion, every return value checked, defensive handling of out-of-range inputs, and deterministic timing.
3. Explain traceability: each requirement links to the design, the code that implements it and the tests that verify it, so a change shows exactly which tests must be rerun; version control and change requests record why every change was made.
4. Describe verification evidence: documented code reviews, unit and integration tests with coverage targets (DO-178C Level A, for example, requires MC/DC coverage), static analysis reports, and deviation records whenever a coding rule is knowingly broken.
5. Explain auditing: an auditor checks that the documented process was actually followed, so the evidence trail matters as much as the code; cutting it to save time creates both safety and legal or financial exposure if a product fails in the field.

Follow-up

• Give an example of a MISRA C rule and the defect it prevents.
• What is MC/DC coverage, and why is it stricter than branch coverage?
• How would you keep compliance documentation from slowing every small change?

How do you prevent memory leaks in a resource-constrained microcontroller environment?

Medium · Embedded C and Hardware Interfacing

Approach

1. Start with the design rule: allocate everything statically or once at start-up and never call free in the running system; MISRA C:2012 Rule 21.3 bans the stdlib malloc and free for this reason, because a leak or fragmentation failure may only appear after days of uptime.
2. When runtime allocation is unavoidable, use fixed-size block pools: allocation and release are O(1), there is no external fragmentation, and pool exhaustion is a countable, testable condition instead of a random failure.
3. Make ownership explicit: one module owns each buffer and releases it, and every error path goes through a single cleanup label so an early return cannot skip the release; the same discipline applies to RTOS objects such as queues, semaphores and task stacks.
4. Separate a leak from fragmentation and from stack overflow: under FreeRTOS, for example, xPortGetMinimumEverFreeHeapSize tracks heap headroom and uxTaskGetStackHighWaterMark tracks stack use, so I would log both and alarm on a falling trend.
5. Prove it: wrap the allocator to count outstanding blocks, run a long soak test with that counter logged, and unit-test the portable logic on a PC under AddressSanitizer or Valgrind, which cannot run on the target itself.

Follow-up

• What is the difference between a memory leak and heap fragmentation, and which one does a block pool solve?
• How would you detect a stack overflow on a small MCU without an MMU?
• When, if ever, would you accept dynamic allocation in firmware?

Suggested practice checklist

The plan follows the reported loop: the written test and fundamentals first, then Embedded C, then battery and power topics, then the project deep dive, and last the HR conversation. Days 3 to 7 point at the reported questions for hands-on practice.

Day 1 — Map the loop and audit your resume

• Write the four reported rounds in order and mark which one you are least ready for.
• For each resume project, write a fact sheet: board or microcontroller, peripherals and protocols, your own contribution, the hardest problem and the fix.
• Cut or rewrite any bullet you could not discuss in detail.

Deliverable: A one-page loop map plus one fact sheet per resume project, with weak bullets rewritten or removed.

Day 2 — Written test: electrical basics, aptitude and reasoning

• Solve a mixed set on Ohm's law, power, series and parallel networks, and battery capacity arithmetic.
• Work a set of number series, pattern, percentage, ratio and work-rate problems in one sitting.
• Do C output-prediction problems on operator precedence, integer promotion and sign extension, sizeof on arrays versus pointers, and shift-and-mask results.

Deliverable: An error log listing every missed problem with the correct method and a one-line rule to remember.

Day 3 — Embedded C core: volatile, memory, ADC, SPI and I2C

• Write short C snippets for polling a hardware status register and sharing a flag between an interrupt handler and main code, with and without volatile.
• Write a fixed-size static buffer pool and explain why avoiding dynamic allocation addresses the memory-leak question on a small microcontroller.
• List the ADC configuration steps (clock, pin mode, reference, resolution, sampling time, start, read, scale to volts), then a table comparing SPI and I2C on wires, speed, addressing and multi-device use.

Deliverable: Three annotated C snippets and a one-page ADC and SPI versus I2C summary that you can speak from.

Day 4 — Battery voltage monitor, interrupts and the debugging story

• Write a C function that reads a cell voltage, applies a threshold with hysteresis and debouncing, and raises an alert.
• Explain polling versus interrupts for a power-constrained device, including timers and sleep modes.
• Outline your hardware-or-software debugging story with the isolation steps and the evidence that settled it.

Deliverable: A working-style C monitor function, a spoken polling-versus-interrupts answer, and a written outline of the debugging story.

Day 5 — Batteries, storage, motors and control systems

• Explain a battery in terms of electrodes, electrolyte and charge and discharge cycles, and compare lead-acid with lithium-ion.
• List what you would monitor in an industrial backup power system and in a remote storage facility, and why.
• Summarise motor starting methods (direct-on-line, star-delta, autotransformer, rotor-resistance for slip-ring motors, soft starter, variable frequency drive) with their effect on starting current and torque, and describe a feedback loop that holds output steady against disturbances.

Deliverable: A cheat sheet with one spoken-ready answer for each battery, storage, backup power, motor starting and control-system topic.

Day 6 — Project deep dive, industry and standards

• Rehearse the full walkthrough of your most complex embedded project, then the technical challenges and how you overcame them.
• Write how your college project would change in an industrial deployment: reliability, safety, cost and maintenance.
• Prepare short notes on high-reliability and aerospace systems and on how standards, reviews and audits change the way you write and document code.

Deliverable: A spoken project walkthrough, a one-page industrial-adaptation note and a short notes page on aerospace, standards and auditing.

Day 7 — HR and Personal Interview rehearsal

• Write and rehearse your self-introduction with a brief, factual family-background line.
• Write your why-Anara and long-term-goals answers, each tied to firmware for battery and power systems.
• Prepare stories for explaining a technical concept simply and for working under a tight deadline, then run the full loop aloud.

Deliverable: Four rehearsed answers (self-introduction, why Anara, career goals, deadline story) and an explanation story, spoken end to end.

HR and project-story preparation

Candidates report that the HR and Personal Interview covers personality, communication, career aspirations, strengths and family background, and that the technical stage goes through your projects. For this role, your stories should show clear communication between software and hardware people, honest debugging across that boundary, and calm planning under a deadline.

Describe a time you had to debug a complex issue where you weren't sure if the bug was in the hardware or the

Medium · Embedded C and Hardware Interfacing

Describe a time you had to debug a complex issue where you weren't sure if the bug was in the hardware or the software.

Approach

1. Choose a bug where the symptom could not be pinned on either side at first: intermittent sensor readings, stale data from a peripheral, or resets under load. Say at the start how you framed the two hypotheses.
2. Describe isolation in order: make it reproducible, check supply and ground and the reset cause, put a logic analyzer or oscilloscope on the bus lines (SPI, I2C or UART) to see whether signals match the datasheet timing, then run a minimal firmware that exercises only that peripheral, or swap in a known-good board.
3. Name the evidence that settled it, for example a missing pull-up or noisy supply that pointed at hardware, or a shared variable written in an interrupt without volatile that pointed at software, and say who you brought in and how you handed over the finding.
4. Close with the fix, how you verified it across many runs and under load or temperature changes, and the safeguard you added afterwards, such as an assertion, a test point or a logging counter. The mistake that sinks this story is blaming the other side without a measurement.

Follow-up

• How did you decide which side to rule out first?
• What would you have done without an oscilloscope or logic analyzer?
• How did you present the finding to the hardware engineer?

Tell me about yourself and your family background.

Medium · HR and Behavioral

Approach

1. Use a present, past, future shape: where you are now, two or three projects that relate to embedded or firmware work (name the board or domain), and the kind of role you want next.
2. Answer the family-background part briefly and factually: where you come from, what your family does, and one sentence on how it shaped your interest in engineering if it did. Then return to your own path rather than dwelling on it.
3. End on a project you would like to be asked about, so the next question lands on ground you know well.
4. Keep every statement consistent with your resume, because any detail you mention can be followed up. The mistake is reciting the resume in order, or telling a long family story with no link to the job.

Follow-up

• Which of those projects are you proudest of, and why?
• What first interested you in embedded systems?
• What would you name as a strength, and what do you still need to work on?

Why do you want to work at Anara, and why should we hire you over the other candidates?

Medium · HR and Behavioral

Approach

1. Build the why-Anara half only from facts you can state accurately: the role is firmware and embedded software for battery, motor-control and power-electronics products. Then say which part of that attracts you and ties to something you have already built.
2. Back it with evidence from the listed requirements: Embedded C, microcontroller interfacing, circuits and battery basics. Give one concrete example for each that applies to you.
3. For why you over other candidates, name one differentiator with proof, such as a hardware-and-software debugging case or a finished project on real hardware. Do not compare yourself with other people or run them down.
4. If you do not know something about the company or industry, say what you do know and what you would want to learn. The mistake is praise that would fit any employer, or claims about products you cannot discuss.

Follow-up

• What do you know about energy storage in industry beyond this company?
• What would you need to learn first in this role?
• Which of your experiences is closest to the work in the role description?

Describe a time you had to explain a complex technical concept to a non-technical stakeholder.

Medium · HR and Behavioral

Approach

1. Pick a concept from your own embedded work where the listener had to make a decision: why battery voltage alone does not give state of charge, why a sensor reading needs filtering or calibration, or why a firmware update needs a rollback path. Name the audience, for example a product manager or a customer.
2. State the technique: open with the decision or outcome they care about, use one analogy such as a fuel gauge or a water tank, give one number, define each unavoidable term, and ask them to restate the trade-off to check understanding.
3. Report the result: what they decided or changed because of your explanation, such as approving extra testing or accepting a feature cut. The mistake is a story where you only used simpler words and cannot show the listener understood or acted.

Follow-up

• How did you know they had understood?
• How would the explanation change for an electrical engineer?
• What did you leave out on purpose, and why?

What are your long-term career goals, and how does this role fit into them?

Medium · HR and Behavioral

Approach

1. Give a two-stage arc. First, deepen your skills in the area the role covers: embedded firmware, hardware-software integration, and battery or power-electronics systems. Later, widen toward system design or technical ownership.
2. Tie it to the role as described to candidates: working with electrical engineers and hardware teams, debugging integration issues, writing documentation to standards, and analysing data from deployed systems. Say which of those builds the skill you want.
3. Show that you are already moving in that direction, with a course, a personal project or self-study such as RTOS basics or firmware update mechanisms.
4. Keep the goal compatible with the job. The mistake is a goal that leaves the field, or one so vague that nothing in the role connects to it. Do not promise a particular promotion path.

Follow-up

• Which skill will you build first, and how?
• What if your early work were mostly testing and validation?
• How does a move toward the hardware side of the work fit your plan?

How do you handle high-pressure situations or tight project deadlines?

Medium · HR and Behavioral

Approach

1. Choose one real deadline with something at stake, such as a release, a validation run or a demo, and state the situation in two sentences before moving to what you did.
2. Show triage: list what had to work and what could slip, agree the scope cut with the owner, tell the team and the hardware counterpart early, and split the work into checkable pieces.
3. For embedded or battery-related work, show you protected verification of the safety-relevant path, such as threshold alerts and cut-offs, and cut a nice-to-have instead.
4. Give the outcome and what you changed afterwards, such as earlier estimates or smaller increments. The mistake is a hero story of unplanned overtime that shows no planning, or a general statement about staying calm with no example.

Follow-up

• What did you decide not to do, and who agreed to that?
• How do you tell a teammate that a date is unrealistic?
• Tell me about a deadline you missed and what you learned.