Skip to content

πŸš— Maruti Suzuki Interview Experience

⬅️ Back Role: Software Electronic Control System
Mode: Online
Rounds: 2 Technical + 1 Managerial

JD Focus:
The role required strong experience in Model-Based Development (MBD) with Simulink, Stateflow, AUTOSAR layered architecture knowledge, integration of software with MCAL modules, and understanding of low-level communication protocols.


Topics Covered: - Simulink & Stateflow modeling - Code generation & optimization - Model verification and testing

Sample Questions:

  1. Explain how you structure your Simulink model for automotive applications.
    Expected answer: Usage of atomic subsystems, configuration sets, bus structures, readability, and hierarchy.

  2. How do you integrate Stateflow logic within Simulink control models?

  3. What is the purpose of TLC files in code generation, and how have you customized them?

  4. What is the difference between Fixed-step and Variable-step solvers? Which one do you prefer and why?

  5. Have you implemented any design patterns to ensure modularity and reuse in your Simulink models?

  6. What are your strategies for MIL and SIL testing? How do you validate requirements through models?


🧱 Technical Round 2: AUTOSAR & Software Architecture

Topics Covered: - AUTOSAR Classic layered architecture - RTE and SWC design - Integration with MCAL - Interfaces and system communication

Sample Questions:

  1. Can you explain the AUTOSAR Classic Architecture?
    Expected structure:
  2. Application Layer: SWCs
  3. RTE (Runtime Environment)
  4. BSW Layer: Services, ECUs Abstraction, MCAL
  5. MCAL: Direct hardware access abstraction for drivers like DIO, PWM, CAN, etc.

  6. How do SWCs communicate via Sender-Receiver vs Client-Server?

  7. What is RTE, and what’s its purpose?

  8. RTE acts as a middleware between Application Layer (SWCs) and BSW. It maps ports/signals at compile time.

  9. How do you configure an SWC interface for CAN communication?

  10. How do you test and integrate an application model with RTE and BSW components?


βš™οΈ Technical Round 3: MCAL & Base Layer Protocols

Topics Covered: - MCAL and low-level driver abstraction - CAN, LIN, SPI protocol knowledge - Diagnostics and bootloaders - Integration challenges

Sample Questions:

  1. What is MCAL, and why is it critical in AUTOSAR?
  2. MCAL (Microcontroller Abstraction Layer) contains low-level drivers for peripherals and abstracts the hardware to upper layers like ECU Abstraction.

  3. Which MCAL modules have you worked with (e.g., DIO, ADC, PWM, CAN)? Describe your experience.

  4. Explain CAN protocol: frame structure, bit stuffing, and error handling.

  5. How does the LIN protocol differ from CAN, and where is it used?

  6. In which layer does the PDU Router reside, and what is its function?

  7. Have you handled integration of CAN stack with application layers in Simulink? How did you simulate the bus?


πŸ‘₯ Managerial Round

This round was more about your: - Long-term interest in automotive software - Experience working in agile or V-cycle environments - Your ability to manage change requests, documentation, and communication with cross-functional teams


πŸ“ Final Notes:

  • Maruti Suzuki’s interviews were technically deep, especially around MBD tools + AUTOSAR understanding.
  • They prefer candidates who not only model but understand the code it generates and how it fits in the software stack.
  • If you understand the flow from top-level models to MCAL drivers, you’ll make a great impression.

πŸ’‘ Quick Summary of What to Prepare

Topic Keywords / Focus Areas
Simulink Modeling Atomic subsystems, Buses, TLC, Configuration
Stateflow Logic Conditions, Transitions, Events
Code Generation Fixed vs variable step, TLC customization
AUTOSAR Layers SWC, RTE, Services, MCAL
MCAL Drivers DIO, ADC, PWM, CAN, SPI
Protocols CAN (bit-level), LIN (master-slave), Diagnostics
System Testing MIL, SIL, RTE integration, Polyspace

πŸ”§ Tip: Be ready to not just explain tools, but explain flow:
Model β†’ Code β†’ RTE Mapping β†’ MCAL Driver Access β†’ Hardware Signal Handling