CEO - eMobility.Careers
A complete EV interview question bank — 50 questions across battery, motor & power electronics, charging, software & systems and the behavioural round, each with a detailed model answer written for the Indian EV industry. Read the answer, make sure you understand the why behind it, then rehearse it in your own words. Tight, concrete answers beat long-winded ones.
Battery — 10 questions
Q1. Explain the difference between LFP and NMC chemistries.
LFP (lithium iron phosphate, LiFePO4) and NMC (lithium nickel manganese cobalt oxide) differ mainly at the cathode. LFP uses an olivine structure that is intrinsically more thermally stable, with a higher decomposition onset (around 250-270 deg C versus roughly 150-200 deg C for NMC) and no cobalt, making it cheaper, longer-cycling (often 3000-5000+ cycles) and far more resistant to thermal runaway. The trade-off is lower energy density: LFP cells sit around 90-160 Wh/kg at cell level versus 200-280 Wh/kg for NMC, and LFP's very flat voltage plateau (~3.2 V nominal) makes mid-range SOC estimation harder, plus it has weaker cold-temperature performance. NMC (e.g. NMC 622, 811) gives more range per kg and better low-temperature behaviour, which is why it dominates premium long-range cars. LFP has become the default for mass-market 2W/3W and standard-range 4Ws in India because of its cost, safety and calendar life. Fundamentally, nickel content drives capacity but reduces stability, so chemistry choice is an energy-density-versus-safety-and-cost decision. For Indian conditions with high ambient temperatures and strong price sensitivity, LFP is frequently the pragmatic choice despite its weight penalty.
Q2. What's the SEI layer and why does it matter for cycle life?
The SEI (Solid Electrolyte Interphase) is a thin passivation film that forms on the anode surface, mostly during the first few charge cycles, when the electrolyte reductively decomposes because graphite operates below the electrolyte's stability window. It matters because a good SEI is electronically insulating yet conductive to lithium ions, so it protects the anode from continuous electrolyte decomposition while still letting Li+ pass; without it the cell would self-destruct in a few cycles. Each time the SEI forms it consumes cyclable lithium and electrolyte, which is exactly why the first-cycle irreversible capacity loss (often 5-10%) occurs. Over the cell's life the SEI keeps slowly growing and re-forming as it cracks during expansion and contraction, and this ongoing lithium and electrolyte consumption is a primary driver of capacity fade and impedance rise, reducing both cycle and calendar life. High temperatures and high charge rates accelerate SEI growth, whereas a well-engineered SEI (via electrolyte additives like FEC or VC and a controlled formation step) is thin, uniform and mechanically robust. This is also why silicon anodes are challenging: their large volume change repeatedly cracks the SEI, causing rapid lithium loss unless mitigated.
Q3. How would you size a 60-kWh pack for a 4W EV?
Sizing starts from the energy delivered at the battery terminals and the target vehicle consumption, not just raw cell capacity. First fix the system voltage and series count: a 4W typically uses a ~350-400 V pack, so with ~3.6-3.7 V NMC cells you need roughly 96 cells in series (96s, ~355 V nominal). Decide nameplate versus usable energy: if you want ~60 kWh usable at about 90% usable window, the nameplate should be ~66-67 kWh to protect cycle life and reserve end-of-life capacity. Capacity per string Ah = total Wh / pack nominal voltage; for 60 kWh on a 96s ~355 V pack that is about 169 Ah, so with ~5 Ah cells you parallel ~34 cells (96s34p), or use larger-format cells with fewer in parallel. Then verify C-rate: peak discharge for acceleration and peak charge for DC fast charging must stay within cell and thermal limits (for example a 1.5C discharge on 169 Ah is ~253 A, which busbars, contactors and the BMS must handle). Add margins for the usable window, temperature derating, balancing overhead and end-of-life (size so range still holds near 80% SOH). Finally cross-check against vehicle consumption (a 4W is often ~150-180 Wh/km), so 60 kWh usable maps to roughly 330-400 km real-world range, and confirm pack mass, volume and enclosure constraints fit the platform.
Q4. What's thermal runaway and how do you prevent propagation?
Thermal runaway is a self-accelerating exothermic chain reaction inside a cell: an initiating event (an internal short from a dendrite or defect, overcharge, external heat, or mechanical crush) raises temperature, which triggers SEI breakdown, then electrolyte decomposition, anode-electrolyte and cathode reactions, and oxygen release from the cathode, each adding more heat in a positive-feedback loop until the cell vents flammable gas and can ignite. At pack level the key danger is propagation, where one cell's heat drives its neighbours into runaway, so prevention works on two layers: stopping a single cell from entering runaway, and stopping cell-to-cell spread. Cell-level prevention includes a robust BMS guarding against overcharge, over-discharge and over-temperature, current-interrupt devices and vents, and tight quality control to minimise internal defects. Propagation prevention is mainly thermal and mechanical: inter-cell spacing and barriers (mica, aerogel or intumescent materials), potting and firewalls between modules, adequate cooling such as liquid cold plates, directed venting paths and flame arrestors so hot gases exit without igniting neighbours, and fusing to isolate a faulted string. Chemistry choice matters too, since LFP has a much higher and gentler runaway onset than NMC. In India, AIS-156 Amendment 3 mandates a thermal propagation test requiring early occupant warning before any cabin hazard, which directly drives these barrier-and-venting designs.
Q5. Walk through AIS 156 propagation test requirements.
AIS-156 is the Indian standard for EV traction batteries, broadly aligned with UN R100 and GTR 20 thinking, and its amendments (notably Amendment 3) added a thermal propagation requirement to protect occupants. In the test a single cell inside the pack is deliberately forced into thermal runaway using a defined trigger (such as an internal heater, nail penetration, or single-cell overcharge), and the test observes whether that event propagates to the rest of the pack and whether it endangers occupants. The pass criterion is occupant-protection focused: the system must give an advance warning signal to occupants at least 5 minutes before any hazardous situation reaches the passenger compartment, allowing time to evacuate. So the manufacturer must show either that propagation does not occur, or that even if it does, the warning-and-egress time is met and no flame or explosion enters the cabin within that window. It is verified with instrumentation such as cell thermocouples and smoke, gas and flame monitoring, plus the defined trigger method. In practice it forces inter-cell thermal barriers, robust venting, and BMS early detection of runaway precursors (a sudden voltage drop, rapid temperature rise, gas sensing) together with the warning telltale. AIS-156 also covers vibration, thermal shock, overcharge, over-discharge, short circuit and mechanical integrity, but the propagation clause specifically targets the cascading-fire failure mode behind several EV fires in India.
Q6. What's the role of formation cycling in cell manufacturing?
Formation cycling is the first set of controlled charge/discharge cycles a freshly assembled cell undergoes before it leaves the factory, and its main purpose is to grow a stable, high-quality SEI layer on the anode. During formation the cell is charged slowly (often at low C-rates, sometimes with controlled temperature and stepped voltages) so the electrolyte decomposes into a uniform, dense film rather than a ragged one, and this SEI quality directly sets the cell's cycle life, safety and self-discharge behaviour. Formation is also where the irreversible first-cycle capacity loss occurs and where the cell is effectively activated. It doubles as a screening step: cells are graded and any showing abnormal voltage, capacity or self-discharge (signs of internal defects or contamination) are caught and rejected here. Because it must be slow and well controlled, formation is one of the most time- and capital-intensive steps in cell manufacturing, sometimes taking many hours to days and needing large banks of cyclers, making it a major cost and throughput driver in gigafactories. After formation, cells typically go through aging and OCV/self-discharge testing for further quality binning. In short, formation trades production time and cost for long-term reliability, and getting it wrong shows up as poor cycle life, higher impedance and safety risk in the field.
Q7. Explain SOC, SOH and SOP — and how a BMS computes each.
SOC (State of Charge) is the present available charge as a percentage of current usable capacity, like a fuel gauge; SOH (State of Health) is how much the cell has degraded versus new, usually present full capacity divided by rated capacity (with end-of-life often defined at 80%) or tracked via internal resistance growth; SOP (State of Power) is the instantaneous power the pack can safely deliver or accept right now given SOC, temperature, voltage limits and resistance. A BMS computes SOC mainly by fusing two methods: coulomb counting (integrating measured current over time, accurate short-term but prone to drift from sensor offset) corrected by OCV (open-circuit voltage) lookups when the pack rests, typically combined in a model-based estimator such as an extended Kalman filter using an equivalent-circuit cell model. SOH is estimated by tracking capacity fade (Ah throughput between known SOC points) and resistance rise over time and temperature, sometimes aided by incremental capacity analysis. SOP is derived in real time from the cell model and present limits: the BMS predicts how much current it can pull or push for a given duration without violating voltage or temperature limits, then converts that to power. The complexity is driven by chemistry: LFP's flat OCV curve makes voltage-based SOC unreliable in the mid-range, so coulomb counting and good models matter more, while NMC's sloped curve helps OCV correction. Accurate SOC, SOH and SOP are essential for range display, charge control, warranty and second-life decisions, and for delivering acceleration and regen power safely.
Q8. What's the trade-off between energy density and safety?
Energy density (Wh/kg or Wh/L) and safety pull in opposite directions because the same features that store more energy also make a cell more reactive when it fails. Pushing nickel content higher in NMC (622 to 811 and beyond) raises capacity but lowers thermal stability and the runaway onset temperature, releasing more oxygen and heat during failure; thinner separators, denser electrode packing and aggressive fast-charge capability similarly raise energy and power but increase internal-short and lithium-plating risk. Conversely, the safest chemistries and designs (LFP, thicker separators, more thermal barriers, narrower usable SOC windows) cost weight, volume and range. The engineering job is to manage this trade-off, not eliminate it: you buy back safety at higher energy density through BMS protection, robust mechanical and thermal design, cell-to-cell barriers, venting and conservative operating windows. India-specific factors tilt the balance toward safety, since high ambient temperatures, fast-charging stress and several high-profile 2W fires led to AIS-156 amendments mandating propagation protection. So the practical answer is to choose the lowest energy density that still meets range and packaging needs, because every extra Wh/kg generally costs safety margin that must then be re-engineered back in. This is also why LFP, despite lower density, won large share in cost- and safety-sensitive Indian segments while NMC stays in long-range premium vehicles.
Q9. How does silicon-graphite anode improve over pure graphite?
Silicon can host far more lithium than graphite (its specific capacity is around 3500-4200 mAh/g versus graphite's ~372 mAh/g), so adding even a modest fraction of silicon to a graphite anode raises the anode's capacity and lets the cell store more energy in the same weight and volume, improving energy density. Pure silicon is impractical because lithiation causes roughly 300% volume expansion, which pulverises the particles, repeatedly cracks the SEI, and consumes lithium and electrolyte, causing fast capacity fade and swelling. Blending a small percentage of silicon (often as SiOx or nano-silicon/silicon-carbon composites) into graphite is the practical compromise: you get a meaningful energy-density boost (commonly single-digit to low-double-digit percent depending on silicon content) while the graphite matrix buffers expansion and maintains conductivity and cycle life. Engineering enablers include nanostructuring, carbon coatings, void/buffer architectures and electrolyte additives like FEC to stabilise the SEI on silicon. The trade-offs remain real: more silicon means more swelling (complicating pack mechanical design and pressure management), higher first-cycle loss, and shorter cycle life unless mitigated. So silicon-graphite is an incremental, well-controlled path to higher energy density that the industry keeps increasing, rather than a wholesale jump to pure silicon.
Q10. What's the typical pack cost split between cells, BMS, thermal and enclosure?
The cell is by far the dominant cost in a battery pack, typically around 55-75% of total pack cost, because it carries the active materials, with the cathode (especially nickel and cobalt in NMC) the single biggest material cost. The remaining pack-level costs are split among the BMS and electronics, the thermal management system, the mechanical enclosure and structure, plus busbars, wiring, connectors, contactors, fuses and assembly labour. As rough industry orders of magnitude: cells ~55-70%, BMS and electrical/electronics ~5-12%, thermal management ~5-12%, and enclosure/mechanical/structure plus interconnects and assembly making up the rest (~10-20%). The split shifts with chemistry, format and architecture; for example LFP lowers the cell cost share (no cobalt, cheaper cathode), which raises the relative share of BMS, thermal and enclosure, and a liquid-cooled performance pack spends more on thermal than an air-cooled commuter pack. Cell-to-pack (CTP) and structural-pack designs cut enclosure and interconnect overhead, improving pack-to-cell cost and energy efficiency. The key takeaway is that because cells dominate, the biggest cost levers are chemistry selection, cell sourcing and scale, and minimising inactive mass, while BMS, thermal and enclosure optimisation yield smaller but still meaningful savings. For India this is why domestic cell manufacturing (the PLI ACC scheme) is the strategic priority, since localising the largest cost block has the most impact on affordability.
Motor & power electronics — 10 questions
Q11. Compare PMSM, induction and switched-reluctance motors for EVs.
PMSM (permanent-magnet synchronous) dominates EV traction because rare-earth magnets (NdFeB) give the highest torque density and peak efficiency, typically 95-97%, with excellent low-speed torque and a compact package ideal for transaxle layouts. Its drawbacks are cost and supply risk of rare-earths, demagnetization risk at high temperature (NdFeB grades typically derate from ~150 degC, with high-temperature grades pushing higher), and spin/drag losses at high speed because the magnet flux is always present. Induction motors (used in the early Tesla Model S) need no magnets, are robust and cheap, tolerate field weakening well for sustained high-speed cruising, and have no no-load magnet loss, but they run a few points lower in peak efficiency due to rotor I2R (slip) losses and need rotor cooling. Switched-reluctance motors are cheap and rugged, magnet-free and fault-tolerant with a simple iron rotor, but suffer high torque ripple, acoustic noise, and demand a non-standard converter and precise control, which has kept them mostly out of mainstream cars. The industry trend, including on Indian platforms, is PMSM (often interior-PM/IPM) for two- and three-wheelers and most passenger EVs where efficiency drives range, with some OEMs pairing an induction motor on one axle and a PMSM on the other to balance efficiency and cost. For a given application I'd weigh efficiency-driven range against magnet cost and availability, the required speed range, NVH targets, and thermal limits.
Q12. What's FOC and why is it the dominant control strategy?
Field-Oriented Control (FOC), also called vector control, transforms the three-phase stator currents into a rotor-aligned two-axis frame using Clarke and Park transforms, giving a flux-producing d-axis current and a torque-producing q-axis current that can be controlled independently like a separately excited DC machine. This decoupling is the key: by regulating Id and Iq with separate PI loops you get smooth, near-instantaneous torque control, fast dynamic response, and the ability to do field weakening (negative Id) and MTPA, which scalar V/f control cannot deliver. The controller needs accurate rotor position (from a resolver, encoder, or sensorless estimator) for the Park transform, then an inverse Park plus space-vector PWM generates the gate signals. FOC maximizes torque-per-amp, which directly improves efficiency and range, and it keeps the current sinusoidal, reducing torque ripple and acoustic noise. It dominates because EVs demand high torque at zero speed (for launch and hill-hold), precise regen, and wide constant-power operation, all of which scalar control handles poorly. The cost is computational load plus the need for good current sensing and position feedback, but modern automotive MCUs running current loops at 10-20 kHz handle this easily.
Q13. Why use SiC over Si for traction inverters?
Silicon carbide is a wide-bandgap semiconductor (~3.3 eV vs ~1.1 eV for Si) with roughly 10x higher critical breakdown field, so an 800 V-class SiC MOSFET has a much thinner, more lightly doped drift region and far lower on-resistance per unit area than a comparable Si IGBT. The big payoff is switching loss: SiC MOSFETs switch faster with negligible tail current (no minority-carrier turn-off tail like an IGBT), cutting switching losses by roughly 50-70% and allowing higher switching frequencies, which shrinks filters, magnetics, and DC-link sizing. Lower total losses translate to a few percent of range improvement at the system level and enable smaller cooling, which is why 800 V architectures (Porsche Taycan, Hyundai E-GMP) pair naturally with SiC. SiC also tolerates higher junction temperatures and conducts heat better, easing thermal design. The trade-offs are higher device cost, sensitivity to gate-drive design (tight Vgs window and a need for negative turn-off bias to avoid spurious turn-on), and faster dV/dt that worsens EMI and stresses motor insulation and bearings. The decision hinges on voltage class and duty cycle: SiC wins clearly at 800 V and in efficiency-critical highway driving, while Si IGBTs can still be cost-effective at 400 V in lower-cost applications.
Q14. What's field weakening and when is it active?
Field weakening injects a negative d-axis current to oppose and reduce the rotor's effective flux, lowering the back-EMF so the machine can run above its base speed without the back-EMF exceeding the available DC-link voltage. A motor has a base speed where, at rated torque, the inverter output voltage hits its ceiling (set by Vdc and the modulation index); beyond that point you trade torque for speed and enter the constant-power region. It activates automatically in FOC when the voltage command saturates, i.e. when sqrt(Vd^2+Vq^2) approaches the voltage limit, so the controller commands negative Id to extend the speed range. This is essential in EVs for highway cruising where the motor spins well above base speed (often 2-4x) and the battery voltage may also sag at low SoC. The cost is that negative Id produces no torque but adds copper loss and reduces efficiency, and excessive demagnetizing current risks irreversibly demagnetizing a PMSM's magnets, so it must be bounded. Induction motors handle field weakening gracefully over a wide range because flux is fully controllable and there is no demagnetization limit, one reason they were favored for high-speed operation. A key safety concern is that at high speed an inverter or gate-drive fault can let uncontrolled back-EMF drive a damaging regen overvoltage, so designs must include active short-circuit or other fail-safe handling.
Q15. How do you size DC-link capacitance?
DC-link capacitance is sized primarily to absorb the high-frequency ripple current the inverter draws, hold the bus-voltage ripple within limits, and provide a low-inductance local energy buffer so switching transients don't spike the bus. The dominant driver is RMS ripple-current capability, not just the capacitance value: a three-phase inverter's ripple current peaks near 50% modulation and depends on load current and power factor, often reaching a large fraction of the phase RMS current, so the cap must carry that ripple without overheating. You then size for an acceptable voltage ripple (commonly on the order of 1-5% of Vbus), accounting for switching frequency, ESR/ESL, and the di/dt of the commutation loop. Automotive designs almost universally use film capacitors (metallized polypropylene) rather than electrolytics because they handle high ripple current, self-heal, last over a -40 to +105/125 degC range, and fail benignly. You also account for transient overvoltage during regen and load dump, hold-up energy, and resonance with the battery-cable inductance. The practical trade-off is size, cost, and weight versus ripple performance and lifetime, and you validate the final value against worst-case ripple heating and the device safe operating area, confirming with thermal and EMC testing.
Q16. What's MTPA and why does it matter?
MTPA (Maximum Torque Per Ampere) is the control strategy of choosing the Id/Iq split that produces a given torque with the minimum stator current magnitude, thereby minimizing copper (I2R) losses. It matters most for interior-PM (IPM) and reluctance machines because their saliency (Ld not equal to Lq) adds a reluctance torque component, so torque comes from both magnet and reluctance terms; the optimum then uses a slightly negative Id rather than the pure Id=0 case used for surface-PM motors. By following the MTPA trajectory the controller maximizes efficiency, reduces inverter and motor heating, and lowers cooling demand, which extends range and reduces thermal derating. Implementations use precomputed lookup tables (Id, Iq versus torque, mapped from FEA or dyno characterization) or online estimators, because the optimal locus shifts with magnetic saturation and temperature. MTPA applies below base speed; above it the control transitions into field weakening and eventually MTPV (max torque per volt), where the voltage limit rather than current becomes the constraint. The trade-off is the need for accurate parameters, since errors in Ld, Lq, and flux linkage push you off the true optimum, making MTPA one of the highest-leverage levers for real-world EV efficiency.
Q17. Explain gate-driver dead-time and ringing.
Dead-time is a deliberate short delay inserted between turning off one switch and turning on the complementary switch in the same half-bridge, ensuring both never conduct at once and cause a destructive shoot-through across the DC link. It must exceed the worst-case turn-off delay plus margin, typically a few hundred nanoseconds for IGBTs and down to tens of nanoseconds for fast SiC, and it is a trade-off: too little risks shoot-through, while too much distorts the output voltage, causing torque ripple, low-order harmonics, and reduced low-speed accuracy that often needs dead-time compensation in software. Ringing is the high-frequency oscillation seen on the switch-node and gate during fast transitions, caused by parasitic loop inductance (PCB, busbar, package) resonating with device output capacitance (Coss) under high dV/dt and di/dt. Ringing produces voltage overshoot that can exceed the device rating, raises EMI, and can falsely turn on the off-side device through Miller coupling, where dV/dt across Cgd injects current into the gate. Mitigations include minimizing the commutation-loop area and inductance, adding a gate resistor to slow di/dt, using a negative turn-off bias (especially for SiC), active Miller clamps in the driver, and sometimes RC snubbers or ferrite beads. The engineering balance is switching speed and efficiency versus overshoot, EMI, and reliability, and you verify it with double-pulse testing on the actual layout.
Q18. What's the difference between sensored and sensorless control?
Sensored control uses a physical rotor-position sensor, a resolver, encoder, or Hall sensors, to feed exact angle and speed to the FOC algorithm, giving reliable torque control from standstill, smooth launch, and accurate hill-hold, which is why traction drives that must produce full torque at zero speed almost always use a resolver or high-resolution encoder. Sensorless control instead estimates rotor position from measured currents and voltages, using back-EMF or flux observers (often sliding-mode) at medium-to-high speed and high-frequency signal injection that exploits machine saliency near zero speed. Its advantages are lower cost, no sensor wiring or connector, fewer failure points, and no sensor mounting or alignment, which is attractive for pumps, compressors, and cost-sensitive two-wheelers. The drawbacks are weak or unreliable estimation at very low and zero speed (back-EMF vanishes), sensitivity to parameter drift (resistance, inductance, flux) with temperature, and degraded transient and startup robustness. Most EV traction keeps a resolver because functional-safety (ISO 26262) torque-accuracy and fail-safe requirements are hard to meet with estimation alone, and a wrong-direction or runaway torque is a serious hazard. A common practical approach is a hybrid: HF-injection or sensored operation at low speed transitioning to observer-based estimation at high speed, with sensorless increasingly used as a redundant backup to the primary sensor for fault tolerance.
Q19. How do you mitigate EMI in a 75-kHz switching inverter?
EMI mitigation starts at the source: control the switching transients, since EMI scales with dV/dt and di/dt, so tuning gate resistance to slow the edges (trading some switching loss), minimizing commutation-loop inductance with tight busbar and PCB layout, and adding snubbers reduces the ringing energy that radiates and conducts at 75 kHz and its harmonics up into the MHz range. Conducted EMI on the DC and AC lines is suppressed with an input EMI filter using common-mode chokes plus X- and Y-capacitors, with the Y-cap value bounded to stay within leakage and isolation-resistance limits. The dominant common-mode source is the high-dV/dt switch node coupling through parasitic capacitance to chassis and through the motor windings to the frame, so you add a low-inductance ground/return plane, a chassis-referenced enclosure, and sometimes a common-mode choke or shaft-grounding rings to suppress bearing currents. Shielding and cable management matter: shielded, 360-degree-terminated motor cables, separation of power and signal routing, and twisted pairs for sense lines. Spread-spectrum PWM (dithering the carrier) smears the spectral peaks to ease narrowband emission limits. For Indian and automotive compliance you design against CISPR 25 (and the harmonized AIS-004 Part 3) for emissions plus ISO 11452 immunity and ISO 7637 transient requirements, and verify with conducted, radiated, and immunity testing. The overarching trade-off is EMI versus efficiency and cost, since slower edges and bigger filters cut emissions but add loss, size, and weight, so you optimize at the system level.
Q20. Walk through inverter efficiency at low vs high torque.
At low torque (light load, e.g. city cruising) the inverter draws small currents, so conduction losses (I2R in the switches) are low, but switching losses are roughly fixed per switching event and the gate-drive and controller overhead are constant, so these near-constant losses become a large fraction of the small output power and efficiency drops, often markedly below ~10-20% load. As torque rises into the mid-range, output power grows faster than losses and efficiency climbs to its peak (commonly 97-99% for the inverter alone) near the rated continuous operating point where the device is well utilized but not yet at thermal or current extremes. At high torque (hard acceleration, hill climbing) conduction losses dominate because they scale with current squared, junction temperatures rise (further increasing Rds(on) or Vce), and efficiency rolls off again, with possible current limiting or thermal derating. This U-shaped inverter curve combined with the motor's own efficiency map is why the real-world operating point matters so much, and OEMs gear and size the machine so typical driving sits near the high-efficiency island. The design trade-off is that optimizing devices and switching frequency for light-load efficiency can hurt high-load thermal headroom, and vice versa. Strategies like reducing switching frequency at light load, discontinuous PWM, MTPA, and using SiC to cut switching loss all flatten the curve and improve the light-load region where most urban Indian driving actually happens.
Charging — 8 questions
Q21. What's the difference between CCS-2, CHAdeMO and MCS?
CCS-2 (Combined Charging System Type 2) is the dominant DC fast-charging standard in India and Europe, and is the reference DC connector for four-wheelers under IS 17017 (India's adoption of IEC 61851/62196). It combines the IEC 62196 Type 2 AC inlet with two added high-current DC pins in a single connector and uses PLC (HomePlug Green PHY) over the control-pilot line for high-layer communication per DIN 70121/ISO 15118, scaling today to roughly 350-400 kW. CHAdeMO is the older Japanese standard that uses a separate dedicated DC connector and CAN bus for signalling rather than PLC, typically tops out around 50-100 kW in deployed units, and is largely absent from new Indian public infrastructure as it is phased out except for legacy fleets. MCS (Megawatt Charging System) targets heavy commercial vehicles such as e-trucks and buses, supporting currents up to ~3000 A and roughly 3.75 MW (1250 V x 3000 A in the original spec), with a physically larger, liquid-cooled connector and an ISO 15118-derived communication stack, now standardised under IEC TS 63379. The key trade-offs are ecosystem and power ceiling: CCS-2 won on its single-connector design and PLC-based smart-charging support, CHAdeMO offered early V2G maturity but lost on power scaling and connector duplication, and MCS exists because no light-vehicle connector can thermally handle the megawatt currents needed to recharge a long-haul truck during a statutory driver rest break. For India, the safe answer is CCS-2 for cars and CCS-2/MCS for the emerging e-bus and e-truck segment.
Q22. Explain how OCPP 1.6 differs from 2.0.1.
OCPP (Open Charge Point Protocol) is the open application-layer protocol between a charge point and a central management system, and the move from 1.6 to 2.0.1 is a substantial redesign rather than an increment. OCPP 1.6 runs as JSON over WebSocket (or SOAP) with a flat message set and a loosely structured configuration model; it handles basic start/stop, metering, and remote control well, and its huge installed base keeps 1.6J the de-facto deployment standard in India today. OCPP 2.0.1 introduces a structured device model (components and variables) so the CSMS can discover and configure a charger's capabilities generically, far richer security (mutual TLS, certificate management, secure firmware updates, and security event logging via defined security profiles), and native ISO 15118 Plug-and-Charge support including contract-certificate handling. It also unifies transaction handling under a single TransactionEvent message, improves smart charging, and adds device monitoring, diagnostics, and driver display/messaging. The trade-off is complexity and migration cost: 2.0.1 demands more capable firmware and a more sophisticated CSMS, so many CPOs run 1.6J now and plan 2.0.1 for new hardware where Plug-and-Charge, stronger cybersecurity, and granular smart charging justify it. A key practical point is that you cannot deliver end-to-end ISO 15118 Plug-and-Charge on bare 1.6, and that requirement alone drives many operators toward 2.0.1.
Q23. What does ISO 15118 plug-and-charge enable?
ISO 15118 Plug-and-Charge (PnC) lets a driver simply plug in and have the session authenticate, authorise, bill, and start automatically, with no RFID card, app, or QR scan. It works by establishing a TLS-secured high-layer communication channel over the control pilot (via PLC), where the vehicle presents a digitally signed contract certificate provisioned by its e-mobility service provider; the charger validates the certificate chain against a trusted PKI, links it to the correct billing account, and authorises energy delivery cryptographically. The benefit is twofold: a frictionless user experience, especially valuable for fleets and public chargers, and stronger anti-fraud security, because X.509 certificate-based mutual authentication is far harder to spoof than an RFID UID. ISO 15118-2 defines PnC with this PKI model, while ISO 15118-20 extends it with stronger crypto, bidirectional power transfer (V2G), and wireless/ACD use cases. The main trade-offs are PKI complexity (certificate provisioning, root-of-trust management, revocation, and cross-operator roaming all require a working contract-certificate ecosystem) plus the need for compatible firmware on both EV and EVSE and a CSMS speaking OCPP 2.0.1 to relay certificates. In India this is still emerging; most public charging uses app or RFID authentication today, but PnC is the clear direction for seamless, interoperable roaming.
Q24. Walk through the AC charging sequence from EV to charger.
When the connector is inserted, the EV and EVSE establish a physical connection that the charger detects via the proximity pilot (PP) resistor, which also encodes the cable's current rating so neither side exceeds its ampacity. State signalling then runs over the control pilot (CP): the EVSE applies a 1 kHz PWM signal oscillating to +/-12 V, whose duty cycle advertises the maximum available current (per IEC 61851/SAE J1772, roughly 10% to 96% duty corresponds to about 6 A up to the station's limit, with I = duty x 0.6 A over the main range). The vehicle responds by switching resistors that pull the CP high level down through defined states: State A (not connected, ~12 V), State B (connected, vehicle ready, ~9 V), State C (charging, ~6 V), and State D for ventilation-required charging; only when the vehicle signals State C does the EVSE close its contactor to energise the AC line. The onboard charger (OBC) then rectifies the incoming AC to DC and draws current up to the lower of the PWM-advertised limit and the OBC's own rating, with the BMS governing pack current and tapering as the pack approaches full. Throughout, protective-earth continuity and the CP/PP handshake are continuously monitored, and any fault (loss of CP, earth fault, over-temperature) opens the contactor. The key concept is that the car, not the AC charger, controls and limits the actual current within the envelope the EVSE advertises; the AC EVSE is essentially a smart, protected switch, and IS 17017 aligns India's AC charging with this IEC 61851 control-pilot scheme.
Q25. What's the role of a CMS in a charging network?
A CMS (Charging Management System, called the CSMS in OCPP terms) is the cloud backend that orchestrates a fleet of charge points and the business around them; it is the brain of a charging network. Its core functions are remote monitoring and control of every charger (status, faults, firmware updates), authentication and authorisation of users (RFID, app, or Plug-and-Charge certificates), session and transaction management, and metering-data collection for accurate billing and settlement. It also handles smart charging and load management, distributing limited grid or transformer capacity across connectors, scheduling to off-peak tariffs, and enforcing per-site power caps so a depot does not trip its sanctioned load. Commercially it manages tariffs, payments, invoicing, and roaming so a user from one network can charge on another (via interfaces like OCPI between operators), plus reporting, analytics, and the uptime tracking that matters for government- and FAME-supported public chargers in India. It typically talks to chargers southbound over OCPP (1.6J widely, 2.0.1 for newer security and PnC features) and northbound to payment, CRM, and grid/DISCOM systems. The point is that hardware alone cannot run a commercial, interoperable, reliable network: the CMS turns boxes on the wall into a managed, billable, observable service, and its uptime monitoring is exactly how operators meet public-charging availability mandates.
Q26. How do you size a DC fast charger for a fleet depot?
Sizing a DC fast charger for a fleet depot starts from the duty cycle, not just the vehicle: you analyse the number of vehicles, their battery capacities, the daily energy each needs (km/day divided by efficiency), and crucially the available dwell windows, since depots usually charge overnight or between shifts and can often use lower per-charger power with more units and smart sequencing. You compute total daily energy demand, then divide by available charging hours and acceptable simultaneity to derive aggregate power; for example, 30 buses each needing 200 kWh over an 8-hour overnight window is about 750 kW of managed average power, far less than 30 chargers running flat out. Per-charger power is chosen against each vehicle's maximum accepted C-rate and connector limit (commonly 60-240 kW DC for buses and LCVs on CCS-2), and you almost always deploy a smart load-management/CMS layer so simultaneous draw stays within the sanctioned transformer/grid capacity rather than sizing the connection for worst-case peak. Key trade-offs include power-sharing architecture (a few high-power dispensers sharing a power cabinet versus many fixed-power units), the cost of upgrading the DISCOM connection and transformer, demand-charge exposure on the tariff, and redundancy (N+1) so one failure does not strand a vehicle. You also factor in future fleet growth, derating for high Indian ambient temperatures (which reduce cabinet output and battery acceptance), and whether to add solar or battery buffering to shave peak demand. The disciplined approach is energy-and-dwell-window-driven sizing with managed charging, not naive max-power times number-of-vehicles.
Q27. Explain V2G architecture at hardware + software level.
At the hardware level, V2G requires a bidirectional power converter so energy can flow both grid-to-vehicle and vehicle-to-grid; this is usually a bidirectional off-board DC charger (the inverter sits in the EVSE) or, less commonly, a bidirectional onboard charger in the vehicle. The EV's battery and BMS must support and be warranted for discharge cycling, the inverter must synchronise phase, frequency, and voltage with the grid and meet anti-islanding and power-quality requirements, and protection includes islanding detection, earth-fault and over/under-voltage and frequency trips, and a revenue-grade bidirectional meter. At the software and communication level, ISO 15118-20 is the enabling standard because it formally defines bidirectional power transfer and the negotiation of charge/discharge schedules, layered with OCPP between charger and CSMS, and above that an aggregator or VPP platform that bids the fleet's flexibility into grid-services markets and sends dispatch setpoints. The control hierarchy is therefore grid/DSO or aggregator signal, then CSMS, then EVSE, then ISO 15118 negotiation with the EV's BMS, which always retains the final say on how much it discharges based on state-of-charge limits and the driver's departure requirements. The major trade-offs are battery degradation from extra cycling (managed by limiting depth-of-discharge and cycle count), converter cost and round-trip efficiency losses, and significant metering, grid-code, and interconnection hurdles, since in India net-metering and DISCOM approval for export are still maturing. The closing point is that V2G economics hinge on the value of grid services exceeding the marginal degradation cost, which is why most early deployments are fleet/depot V2G or vehicle-to-building (V2B) rather than residential.
Q28. What are the safety interlocks in a public DC charger?
A public DC fast charger uses multiple layered safety interlocks because it handles high DC voltages (up to ~1000 V) and large currents that are lethal and can sustain arcs. First is connector and contactor sequencing: the charger closes its main DC contactors only after a valid digital handshake (DIN 70121/ISO 15118) and proximity/control-pilot confirmation that the connector is fully latched, and it locks the connector during the session so it cannot be unplugged under load, de-energising before the lock releases. Second is insulation monitoring: before energising it runs an isolation test (IMD check) on the isolated DC output relative to ground and aborts if isolation resistance is too low, then continuously watches for ground faults during the session. Third are protective-earth continuity monitoring, over-voltage/over-current/over-temperature protection on the connector pins and power electronics (pin temperature sensing is critical at high currents, and many DC connectors are liquid-cooled), plus emergency-stop buttons that immediately open the contactors. Fourth is cooperative shutdown with the vehicle BMS over the communication link, where either side can command a graceful current ramp-down and contactor opening, and loss of communication or control-pilot triggers an automatic safe shutdown. These interlocks reflect a safety-lifecycle mindset, governed in India by IS 17017/IEC 61851-1 and 61851-23 for the EVSE (with ISO 26262 applying to the in-vehicle controllers), and the unifying principle is fail-safe: the default state is de-energised with contactors open, and the connector is live only when every interlock is simultaneously satisfied.
Software & systems — 10 questions
Q29. Explain AUTOSAR Classic architecture.
AUTOSAR Classic is a layered, standardized software architecture for deeply embedded automotive ECUs running on a statically configured RTOS, typically on microcontrollers like Infineon AURIX or NXP S32. It has three main layers: the Basic Software (BSW), the Runtime Environment (RTE), and the Application layer of Software Components (SWCs). The BSW is sub-layered into the Microcontroller Abstraction Layer (MCAL) that touches hardware registers, the ECU Abstraction Layer, the Services Layer (OS, communication stack, diagnostics, NVM and memory management), and Complex Device Drivers for timing-critical exceptions that bypass the standard stack. The RTE is the key abstraction: it acts as middleware that decouples SWCs from the hardware and from each other, so a component communicates only through standardized Ports and Interfaces (sender-receiver or client-server), making components portable across ECUs and suppliers. The whole system is configured offline via ARXML files, and the OS is OSEK/AUTOSAR-OS based with fixed-priority preemptive scheduling, giving deterministic timing suited to hard-real-time control loops like motor control or a BMS. The trade-off is that this static, configuration-heavy model delivers determinism and safety (it pairs naturally with ISO 26262 up to ASIL D) but is rigid and heavyweight compared with the newer AUTOSAR Adaptive platform (POSIX/C++, service-oriented, dynamic) used for high-compute domains. In an EV context, Classic AUTOSAR fits the VCU, BMS and motor-control ECUs that need microsecond determinism and functional safety, while Adaptive handles connected/gateway and OTA-heavy nodes.
Q30. What's ISO 26262 and the ASIL classification?
ISO 26262 is the international functional-safety standard for road vehicles, adapted from the generic IEC 61508, covering the full safety lifecycle of electrical/electronic systems from concept through development, production, operation, service and decommissioning. Its purpose is to manage the risk of both systematic faults (design/development errors) and random hardware faults so that malfunctions cannot lead to unreasonable harm. Its central mechanism is the ASIL (Automotive Safety Integrity Level), assigned to each hazard during the Hazard Analysis and Risk Assessment (HARA) from three parameters: Severity (S0-S3, how badly someone could be hurt), Exposure (E0-E4, how often the operating situation occurs), and Controllability (C0-C3, whether the driver or others can avoid the harm). The combination yields QM (quality management, no specific safety requirement) or ASIL A through ASIL D, with ASIL D being the most stringent. Higher ASILs drive stronger requirements such as quantified hardware metrics (SPFM and LFM targets and a PMHF on the order of 10^-8 failures per hour for ASIL D), redundancy, freedom from interference, and more rigorous verification. A practical technique is ASIL decomposition, where one high-ASIL requirement is split across two sufficiently independent elements (e.g. ASIL D into B(D)+B(D), or D into ASIL C(D)+A(D)) to relax per-element requirements while preserving the overall integrity. In an EV, functions like traction-battery overvoltage/overcurrent protection, contactor control and unintended-acceleration prevention are commonly rated ASIL C or D, which is why the BMS and VCU receive the most safety scrutiny.
Q31. Walk through a CAN frame structure.
A classic CAN frame (CAN 2.0) is a serial message on a two-wire differential bus made up of well-defined fields. It opens with a single dominant Start-of-Frame bit for synchronization, followed by the Arbitration field carrying the identifier: 11 bits in a standard frame or 29 bits in an extended frame, plus the RTR bit that distinguishes a data frame from a remote request. The identifier doubles as message priority because CAN uses non-destructive bitwise arbitration, where a dominant 0 overrides a recessive 1, so the lowest numeric ID wins the bus without any message being corrupted. Next is the Control field, containing the IDE bit, a reserved bit and a 4-bit DLC (Data Length Code) specifying 0 to 8 data bytes, then the Data field itself. The CRC field is a 15-bit cyclic redundancy check plus a delimiter for error detection, followed by the ACK slot in which any receiver that validated the frame asserts a dominant bit, and finally the 7-bit End-of-Frame. Bit stuffing (a complementary bit inserted after five identical consecutive bits) keeps receivers synchronized. The key trade-off is that classic CAN caps payload at 8 bytes and runs up to 1 Mbit/s, which is why CAN FD was introduced to allow up to 64-byte payloads and a faster data-phase bit rate; in Indian EVs CAN is the backbone for BMS-to-VCU communication, while CCS-2 fast charging uses ISO 15118 PLC over the Control Pilot line rather than CAN.
Q32. How would you design an OTA flow that survives a half-flashed update?
The cardinal rule is that an OTA update to a safety- or drive-critical ECU must be atomic and fully recoverable, so a power loss or corrupted download mid-flash never bricks the vehicle. The standard solution is an A/B (dual-bank) scheme: the new image is downloaded and written entirely to the inactive bank while the vehicle keeps running on the active bank, the image is cryptographically verified end-to-end before it is ever booted, and only then does the bootloader switch the active pointer. Integrity and authenticity are enforced with a signature check (e.g. RSA or ECDSA over a SHA-256 hash), so a half-written or tampered image fails verification and is rejected; this aligns with secure-boot expectations and the software-update management of ISO/SAE 21434 and UNECE R156. After the switch you boot the new image with a watchdog-backed health check and a rollback counter, and if it fails to confirm a successful boot within N attempts the bootloader automatically reverts to the known-good bank. For the half-flashed case specifically, you must never erase or overwrite the running bank, you should resume interrupted downloads via chunked transfer with per-chunk checksums, and you should gate activation behind preconditions like vehicle parked, handbrake engaged, and sufficient SoC (commonly 20-30 percent or charger connected). On the backend, the OEM cloud or telematics platform manages campaign rollout, staged deployment and signing keys. The trade-off is that A/B doubles flash cost and complicates orchestration across many ECUs behind a gateway, but it is the only robust way to guarantee fail-safe updates on a large fleet.
Q33. What's ASPICE compliance?
ASPICE (Automotive SPICE) is a process-assessment and process-improvement framework, based on ISO/IEC 33000 (formerly ISO/IEC 15504), that OEMs use to evaluate the maturity and capability of a supplier's software and systems engineering processes. It is process-focused rather than product-focused: it does not test the software itself but assesses how disciplined, managed and repeatable the development process is. Its hallmark is V-model traceability expressed through scope processes such as SYS.1-SYS.5 (system requirements, architecture, integration and qualification) and SWE.1-SWE.6 (software requirements through software qualification testing), where every requirement must trace bidirectionally down to design and code and back up through unit, integration and qualification tests. Each process is rated on a capability level from 0 (Incomplete) to 5 (Optimizing), with Level 1 meaning performed, Level 2 managed, and Level 3 established as a standard organizational process; most OEMs contractually require suppliers to reach Level 2 or 3. The reason it matters is that ASPICE gives the OEM confidence the supplier can deliver consistent, traceable, well-verified software, and it pairs naturally with ISO 26262, whose safety arguments rely on exactly the requirements traceability and verification rigour ASPICE enforces. The trade-off is significant process and documentation overhead, which can feel heavy for smaller Indian EV startups, but it is increasingly a gate to winning Tier-1 and OEM contracts.
Q34. Explain a Kalman filter in the BMS state-estimation context.
A Kalman filter is a recursive state estimator that optimally fuses a model-based prediction with noisy measurements to estimate states that cannot be measured directly, which is exactly the BMS problem: State of Charge cannot be sensed directly, only inferred. In a BMS it typically estimates SoC (and often polarization voltages, or capacity for SoH) by combining two information sources: a prediction step using Coulomb counting (integrating measured current over time) together with an equivalent-circuit cell model (an OCV-SoC curve plus RC branches for the cell's dynamics), and an update step that compares the model's predicted terminal voltage against the measured cell voltage and corrects the SoC estimate by the Kalman gain. The Kalman gain mathematically balances how much to trust the model versus the measurement, based on the process-noise and measurement-noise covariances. Because the OCV-SoC relationship and cell behaviour are non-linear, BMS implementations use the Extended Kalman Filter (EKF), which linearizes around the operating point, or the Unscented Kalman Filter (UKF) for better accuracy with strong non-linearities. The big advantage over plain Coulomb counting is robustness: pure integration accumulates drift from current-sensor offset and SoC initialization error, whereas the voltage-based correction continuously pulls the estimate back toward truth, typically achieving SoC error within a few percent. The trade-offs are computational load on the BMS microcontroller, the need for accurate temperature- and age-dependent model parameters, and tuning of the noise covariances; LFP chemistry (dominant in Indian EVs and e-rickshaws) is especially challenging because its very flat OCV plateau gives weak observability mid-range, often pushing designs toward UKF or hybrid methods.
Q35. How do you partition safety-relevant code from non-safety?
Partitioning safety-relevant code from non-safety code is required by ISO 26262 under the principle of 'freedom from interference', meaning a lower-criticality (or QM) component must not be able to corrupt or starve a higher-ASIL safety function. The three dimensions of interference to protect against are memory (one task overwriting another's data), timing/execution (a task hogging CPU or blocking a safety task), and communication (corrupted, lost or stale data crossing between partitions). The primary mechanism is spatial isolation enforced by a hardware Memory Protection Unit (MPU/MMU): each partition gets its own protected region so a QM task cannot write into ASIL-D memory, with violations trapping to a safe-state handler. Temporal isolation is enforced by the RTOS scheduler using time partitioning or execution-budget monitoring plus a hardware watchdog, so a runaway task cannot deny CPU to the safety task; AUTOSAR OS provides exactly these via OS-Applications, timing protection and memory protection. For communication, data crossing the boundary is guarded by end-to-end (E2E) protection (CRC, sequence and alive counters) so corruption or loss is detected by the receiver. The recommended architectural approach is to keep the safety partition as small and simple as possible to minimize the code that must meet the high ASIL, and then either develop everything to the highest ASIL present (conservative but costly) or rigorously argue the partitioning so QM code can coexist on the same ECU. In practice on an EV VCU or BMS, you might run ASIL-D battery-protection logic in an isolated MPU-protected partition while telematics and logging run as QM, with the watchdog and E2E guarding the boundary.
Q36. What's UDS and how is it used in service?
UDS (Unified Diagnostic Services), defined by ISO 14229, is the standardized application-layer diagnostic protocol that lets a diagnostic tester or service tool communicate with an ECU, most commonly transported over CAN via ISO-TP (ISO 15765-2), which segments messages longer than 8 bytes, and increasingly over DoIP (Diagnostics over IP, ISO 13400) on Ethernet for high-bandwidth ECUs. It is a request/response protocol organized around Service IDs (SIDs): key services include 0x10 DiagnosticSessionControl to switch between default, programming and extended sessions; 0x22 ReadDataByIdentifier and 0x2E WriteDataByIdentifier to read/write parameters by DID; 0x14 ClearDiagnosticInformation and 0x19 ReadDTCInformation for Diagnostic Trouble Codes (DTCs); 0x31 RoutineControl to trigger actuator tests or self-checks; 0x27 SecurityAccess, a seed-and-key challenge that unlocks protected functions; and 0x34/0x36/0x37 RequestDownload/TransferData/RequestTransferExit used for reprogramming. In an EV workshop, a technician plugs into the diagnostic connector and uses UDS to read DTCs from the BMS, VCU, motor controller or charger, view live data (cell voltages, temperatures, SoC, insulation resistance), run actuator routines like contactor or cooling-pump tests, reset adaptations and reflash firmware after a recall or update. The value is that UDS gives one uniform protocol across all ECUs and suppliers, which makes both factory end-of-line testing and field service feasible. SecurityAccess and authenticated diagnostics matter especially for EVs, because unlocking or flashing high-voltage control functions must be protected against tampering.
Q37. Describe a HIL test setup.
A Hardware-in-the-Loop (HIL) setup validates a real ECU (the Device Under Test, such as a BMS, VCU or motor controller) by surrounding it with a real-time simulator that emulates the rest of the vehicle, so the ECU behaves as if it were in a real car. The core is a real-time computer (e.g. dSPACE, NI VeriStand, or Typhoon HIL for power electronics) running plant models of the battery pack, electric machine, vehicle dynamics and environment at a fixed, deterministic step (sub-millisecond, down to microseconds for power-electronics models). The simulator connects to the ECU through an I/O layer that physically generates and reads the real electrical signals the ECU expects: analog sensor emulation (cell voltages, temperatures, current-sensor outputs), digital I/O, PWM, and bus communication over CAN/CAN-FD/LIN/Ethernet, plus fault-injection hardware that can open or short wires or inject out-of-range signals. A battery-cell emulator, for instance, can present any SoC, cell-imbalance or over/under-voltage condition to a BMS on demand. The decisive benefit is safety: HIL lets you test dangerous and rare scenarios (over-current, contactor weld, sensor failure, thermal-runaway signatures) repeatably and automatically without risking a real high-voltage pack, and it enables overnight regression runs of thousands of automated cases, central to ISO 26262 verification and ASPICE qualification. The trade-offs are high cost and dependence on plant-model fidelity, since results are only as good as the simulation; HIL therefore complements, rather than replaces, MIL/SIL, bench and real-vehicle testing. For Indian EV makers it is the standard way to validate BMS and VCU logic across the full operating envelope before committing to expensive vehicle-level trials.
Q38. What's MISRA-C and why does it matter?
MISRA-C is a set of coding guidelines for the C language (most cited is MISRA C:2012, with later amendments) created to promote safe, secure, reliable and portable code in safety-critical embedded systems, where C's flexibility can otherwise lead to dangerous undefined or implementation-defined behaviour. It matters because C, though ideal for resource-constrained automotive microcontrollers, has many pitfalls (pointer arithmetic, implicit type conversions, unspecified order of evaluation, uninitialized variables) that can cause field failures that are costly or unsafe in a vehicle. Its rules are classified as Mandatory, Required and Advisory, and they ban or constrain risky constructs: examples include forbidding dynamic memory allocation (malloc/free) in safety contexts, prohibiting recursion, requiring explicit casts and avoiding implicit narrowing conversions, restricting goto, and requiring every switch statement to have a default clause. Compliance is enforced largely by static-analysis tools (e.g. Polyspace, LDRA, Coverity, PC-lint) in the build pipeline, with any deviations formally documented and justified rather than silently ignored. In the EV/automotive world, MISRA-C is effectively expected evidence for ISO 26262 functional safety and supports ASPICE quality goals, because it reduces the likelihood of systematic software faults in code that controls a high-voltage battery, motor or vehicle motion. The trade-off is that strict compliance can feel restrictive and occasionally needs justified deviations for legitimate low-level hardware access, but for any ASIL-rated EV firmware (BMS, VCU, charger control) it is essentially non-negotiable.
Behavioural — 12 questions
Q39. Why EV? Why now?
EVs are where India's energy, mobility, and manufacturing ambitions converge, and the timing is structural rather than hype-driven. When I started tracking the sector, two-wheeler EV penetration was in low single digits; today it has crossed roughly 6 percent and electric now makes up well over half of new three-wheeler sales, which told me adoption had moved past early adopters into genuine unit economics. I deliberately shifted my skilling toward battery systems and powertrain because that is where the value and the hiring are migrating as the PLI scheme and the move from FAME-II through EMPS to PM E-DRIVE pull localisation deeper. That means I am entering an industry that is still being built, not maintained, where an engineer's decisions actually shape the product. Now is the right moment because falling cell prices, a maturing charging layer, and government de-risking have aligned at the same time, and that alignment rarely repeats. I want to be inside that S-curve, not watching it.
Q40. Why this specific company?
I looked closely at how this company actually operates rather than its marketing, and three things convinced me. First, your decision to localise the BMS and not just assemble imported packs signals that you are building real IP, which is exactly where I want to grow technically. Second, two people I spoke to in your supply-chain and R&D teams independently described a culture where field-failure data flows back to design weekly, which matches how I like to work. When I checked your warranty and range claims against your service-network footprint the numbers were internally consistent, and that honesty is rare in a sector where overpromising is common. I also map well to your near-term roadmap of moving from city two-wheelers into higher-voltage platforms, because that is the exact transition I have been preparing for. So this is not a generic application; it is the one company where my battery-systems focus and your trajectory genuinely overlap.
Q41. Tell me about a project you led end-to-end.
At my last role I owned a swappable battery pack for a last-mile delivery fleet end-to-end, from requirements to field rollout, because the fixed-battery model was costing operators about four hours of daily downtime. I started by riding along with delivery riders in Bengaluru for a week to quantify the real duty cycle, then defined the cell configuration, BMS logic, and mechanical latching spec, and built a small pod of one mechanical, one firmware, and one test engineer. When our single connector supplier slipped, I qualified a second vendor in parallel rather than waiting, which protected the timeline. We ran a 40-vehicle pilot for eight weeks, instrumented every swap, and iterated the latch twice after thermal data showed contact heating. Rider downtime dropped from four hours to under fifteen minutes per shift, and the pilot converted into a 300-unit order. The biggest lesson was that owning something end-to-end means owning the field-data loop, not just the design.
Q42. Tell me about a time you failed and what you learned.
Early in my career I led thermal validation for a battery pack and signed off after bench-testing it in our lab, which was air-conditioned at 24 degrees. We shipped to a fleet operating in Nagpur during peak summer, and within three weeks we saw BMS over-temperature shutdowns we had never reproduced. I had failed to test against the actual ambient envelope the product would live in, and I owned that openly with my manager rather than blaming the cell vendor. We ran a controlled chamber retest at 45 degrees ambient, found our derating curve was too aggressive, and added a forced-convection vent plus a revised thermal model that recovered the deployments. The lasting outcome was a personal rule I have kept since: validate against the harshest realistic field condition, not the comfortable lab one. Now I start every test plan by asking what the worst Indian operating environment for that product actually looks like.
Q43. Describe a conflict with a manager and how you resolved it.
On a charging-infrastructure project my manager wanted every site standardised on a single high-power connector to simplify procurement, but my survey data showed half our locations served two-wheeler customers who would never need that and would be priced out. Rather than pushing back in the review meeting, I asked for two days to build the case properly. I made a simple cost-per-charge model showing that a mix of slower and fast points improved utilisation and payback at the smaller sites, and I walked him through it privately first so he was not surprised in front of the team. I had initially dismissed his procurement concern, which was legitimate, so we compromised on two standard SKUs instead of one. We rolled out the mixed model and utilisation came in about 30 percent higher at the tier-two sites than his original plan would have allowed. What I learned is that resolving conflict with a manager is mostly about understanding the constraint they are actually optimising for, then arguing with evidence rather than opinion.
Q44. How do you handle ambiguous requirements?
I treat ambiguous requirements as a signal that the underlying problem is not yet understood, so my first move is to turn vagueness into testable assumptions. On a project where the brief was simply make the scooter feel faster, I defined three measurable interpretations: improve 0-to-40 time, improve throttle responsiveness, or improve perceived acceleration through tuning. I wrote those down, took them back to the product lead, and we agreed perceived responsiveness mattered most for our target rider. From there I built a quick throttle-map prototype and put it in front of five riders within a week rather than debating in a room. We shipped a torque-curve change that riders rated noticeably peppier without touching the hardware, which would not have happened if I had built to my own guess. My rule is to make the ambiguity explicit early, get the smallest real thing in front of a user, and let evidence collapse the options.
Q45. Walk me through a difficult technical decision you made.
We had to choose between a 48-volt and a 60-volt architecture for a new commercial three-wheeler, and it was hard because the paths diverged on cost, component availability, and regulatory classification. I laid out the trade-offs honestly: 48 volts kept us in a simpler safety regime with cheaper off-the-shelf controllers, while 60 volts gave the gradeability customers needed for loaded hill starts. Instead of relying on intuition, I ran a drive-cycle simulation on actual loaded-route data and showed that 48 volts would leave us thermally stressed on the worst gradients. The higher-voltage supply chain was thinner in India at the time, so I de-risked the schedule by qualifying a backup controller vendor before committing. We chose 60 volts but staged procurement to manage that risk, and the vehicle met its gradeability spec with thermal margin to spare. The decision taught me to make hard technical calls on simulated real-world data plus supply-chain reality, not just the spec sheet.
Q46. How do you stay current with EV industry developments?
I keep a deliberate mix of sources because the EV industry moves on policy, chemistry, and field data at the same time. For policy I track Ministry of Heavy Industries notifications and the Vahan registration dashboard directly, because secondary reporting often lags or distorts the numbers. For technology I follow cell-maker roadmaps and teardown analyses, and I keep a small circle of working engineers on WhatsApp and LinkedIn where we share field failures candidly, which is faster than any publication. Recently the shift in LFP versus sodium-ion economics surfaced in that group weeks before mainstream coverage and changed how I think about cost roadmaps. I also attend at least one industry event a year and walk the supplier booths, because you learn more about real localisation from a connector vendor than from a press release. My discipline is to separate signal from noise by always checking a claim against registration data or a primary source.
Q47. What's your view on India's EV trajectory over the next 5 years?
I expect strong but uneven growth, with two- and three-wheelers continuing to lead while passenger cars accelerate from a low base as more sub-15-lakh models arrive. Two-wheeler penetration should plausibly move from the mid-single digits today toward the high teens or low twenties by the early 2030s, driven by total cost of ownership crossing over for daily commuters rather than by subsidies. The real swing factor is charging and battery confidence in tier-two and tier-three towns, since metro adoption is already proving itself. I am cautious about the most aggressive forecasts because grid readiness, fleet-buyer financing, and a still-maturing service ecosystem are genuine brakes that optimists underweight. The structural story I am most confident about is cell localisation through the PLI push, because it changes the cost curve permanently rather than temporarily. So I am bullish on the direction but realistic that it will be lumpy across segments and geographies rather than a smooth line.
Q48. What's a strong opinion you hold loosely about EVs?
I hold loosely the view that swappable batteries will eventually dominate the commercial and last-mile segments. The logic is strong: swapping kills downtime for fleet operators and decouples the costly battery from the vehicle, which transforms the financing math for gig riders. I have seen this work in delivery pilots where uptime mattered more than anything else, so I lean toward it. But I hold it loosely because standardisation is genuinely hard, OEMs have real incentives to lock in their own packs, and fast charging keeps improving and eroding the swap advantage every year. If charging gets cheap and quick enough, the case for maintaining a swap-station network could weaken faster than I expect. So I would advocate swapping in fleet contexts today while staying ready to be proven wrong by charging economics, and I would not bet a whole company on it as a universal answer.
Q49. Tell me about a time you had to learn something fast.
When my team adopted a new BMS chipset, I had about ten days to come up to speed on its CAN-based diagnostics before a customer integration, despite never having used that protocol stack. I started with the datasheet and reference firmware, then built a minimal bench rig so I could send real CAN frames and watch the responses instead of just reading documentation. I deliberately reached out to the chip vendor's field application engineer with targeted questions about the cell-balancing registers, which saved me days of trial and error. Within a week I had a working diagnostic harness that could read pack faults live, and I documented it so the rest of the team could use it. We hit the integration deadline, and the harness later became our standard debug tool for that platform. My way of learning fast is to get hands on a working example immediately and learn by probing it, rather than trying to understand everything before touching anything.
Q50. Where do you see yourself in 5 years?
In five years I want to be the technical owner of a battery or powertrain subsystem, the person whose judgement a team relies on when a hard architecture call has to be made. To get there I plan to deepen my systems expertise over the next two to three years, then take on more cross-functional ownership where I coordinate design, test, and field feedback rather than just executing my own piece. I am drawn to the technical-depth track more than pure management, though I want to be the kind of senior engineer who also mentors and unblocks others. Given how fast Indian EV platforms are evolving, the specific technology I will be deepest in may shift, so I am committing to a domain, battery and powertrain, rather than a single chemistry. I see this role as the right environment for that growth because your roadmap into higher-voltage platforms creates exactly the hard problems I want to grow on. My goal is to still be here, having grown with the platform rather than jumped for a title.
Where to go from here
Pick the 20 most relevant questions for your specific role and rehearse 60-second answers for each. Time yourself — most candidates over-explain. Use the detailed answers above to get the technical depth right, then compress to the points that matter.
Make this real: create a free emobility.careers account to match with EV jobs, see live salary medians and unlock 200+ JD templates. Want hands-on training? Check out the AICTE-approved EV programs at DIYguru — the largest EV academy in India with placement support across OEMs, charging operators and Tier-1 suppliers.