Dependency Injection (DI)

Q1: What is Dependency Injection?

A design pattern where dependencies are injected via constructor instead of created manually.

Q2: Which file configures DI?

di.xml file.

Q3: What is preference?

Used to override a class or interface globally.

Q4: What is virtualType?

Used to change constructor arguments without modifying original class.

Q5: What is shared="false"?

Creates a new instance every time.

Q6: What is Object Manager?

Magento’s dependency injection container.

Q7: Should Object Manager be used directly?

No, except in rare cases.

“We avoid direct ObjectManager usage because it breaks dependency injection principles, reduces testability, hides dependencies, and creates tightly coupled code. Constructor dependency injection is the recommended Magento approach.”

Q8: What is constructor injection?

Injecting dependencies via constructor.

Q9: What is factory?

Used to create new instances dynamically.

Q10: What is proxy?

Used for lazy loading heavy classes.

Plugins (Interceptors)

Q11: What is a plugin?

Allows modification of public methods without overriding.

Q12: Types of plugins?

before, after, around.

Q13: before plugin?

Executes before original method.

Q14: after plugin?

Executes after method.

Q15: around plugin?

Wraps method and controls execution.

Q16: What is $proceed?

Calls original method.

Q17: If $proceed not called?

Original method will not execute.

Q18: What is sortOrder?

Defines plugin execution order.

Q19: Can plugins modify return value?

Yes.

Q20: Plugin limitation?

Cannot be applied on private/final methods.

Events & Observers

Q21: What is event?

A trigger point in Magento.

Q22: What is observer?

Executes logic when event is fired.

Q23: File for events?

events.xml

Q24: Custom event?

Use dispatch method.

Q25: Plugin vs Observer?

Plugin modifies methods, observer listens to events.

Q26: Can multiple observers exist?

Yes.

Q27: Can observer stop execution?

No.

Q28: Event payload?

Data passed with event.

Q29: Event scope?

Global, frontend, adminhtml.

Q30: Performance?

Observers are lighter than plugins.

Service Contracts

Q31: What is service contract?

Set of interfaces for APIs.

Q32: Repository?

Handles CRUD operations.

Q33: Data interface?

Defines getters/setters.

Q34: Why service contracts?

For API stability.

Q35: Extension attributes?

Used to extend data interfaces.

Q36: SearchCriteria?

Used to filter collections.

Q37: get() vs getList()?

get() returns single, getList() returns multiple.

Q38: API interface?

Defines contract for service.

Q39: REST API?

HTTP-based API.

Q40: SOAP API?

XML-based API.

Database & Models

Q41: Model?

Represents data.

Q42: ResourceModel?

Handles DB operations.

Q43: Collection?

Fetches multiple records.

Q44: load()?

Loads single record.

Q45: save()?

Saves data to DB.

Q46: entity_id?

Primary key.

Q47: CRUD?

Create, Read, Update, Delete.

Q48: Schema patch?

Used for DB structure changes.

Q49: Data patch?

Used for data changes.

Q50: Declarative schema?

XML-based DB structure management.

EAV Model

Q51: What is EAV?

Entity Attribute Value model.

Q52: Used for?

Products, customers.

Q53: Attribute?

Property of entity.

Q54: backend_type?

Defines storage type.

Q55: Attribute set?

Group of attributes.

Q56: Value table?

Stores attribute values.

Q57: Static attribute?

Stored in main table.

Q58: Dynamic attribute?

Stored in value table.

Q59: EAV advantage?

Flexibility.

Q60: Disadvantage?

Complex queries.

Layout & UI

Q61: Layout XML?

Defines page structure.

Q62: Block?

PHP class for UI logic.

Q63: Container?

Holds blocks.

Q64: Template?

PHTML file.

Q65: referenceBlock?

Modify existing block.

Q66: UI component?

JS-based UI system.

Q67: Knockout.js?

Used for data binding.

Q68: Handle?

Layout identifier.

Q69: XML merging?

Combines layout files.

Q70: Override layout?

Use custom XML.

Indexing & Cache

Q71: Indexer?

Improves query performance.

Q72: Cache?

Stores data for speed.

Q73: Full page cache?

Caches full HTML page.

Q74: Cache types?

Config, layout, block, full_page etc.

Q75: Cache flush?

Clears all cache.

Q76: Cache clean?

Clears selected cache.

Q77: Reindex?

Rebuild index tables.

Q78: Cache invalidation?

Marks cache outdated.

Q79: Index vs Cache?

Index optimizes DB, cache stores output.

Q80: Performance?

Both improve speed.

CLI & Deployment

Q81: setup:upgrade?

Runs DB updates.

Q82: di:compile?

Generates DI classes.

Q83: static-content deploy?

Deploys frontend assets.

Q84: production mode?

Optimized performance mode.

Q85: developer mode?

Debugging mode.

Q86: maintenance mode?

Disables frontend access.

Q87: env.php?

Environment config.

Q88: config.php?

Module config.

Q89: cron?

Scheduled tasks.

Q90: run cron?

bin/magento cron:run

Miscellaneous

Q91: module.xml?

Defines module.

Q92: registration.php?

Registers module.

Q93: routes.xml?

Defines routes.

Q94: webapi.xml?

Defines APIs.

Q95: system.xml?

Admin config.

Q96: ACL?

Access control.

Q97: GraphQL?

Query-based API.

Q98: Message Queue?

Async processing.

Q99: RequireJS?

JS module loader.

Q100: Theme inheritance?

Extending themes.

Q101: Magento 2 Request Flow (Frontend Request Lifecycle)

Magento request starts from pub/index.php, bootstrap initializes the framework, FrontController dispatches request through routers to controller action, controller interacts with service/model layer, layout system renders blocks and templates, response is cached and returned to browser.

Browser
   ↓
Apache/Nginx
   ↓
pub/index.php
   ↓
Bootstrap
   ↓
Object Manager
   ↓
App\Http
   ↓
FrontController
   ↓
Routers
   ↓
Controller Action
   ↓
Service Layer / Models
   ↓
Layout XML Merge
   ↓
Blocks
   ↓
PHTML Templates
   ↓
HTML Response
   ↓
Cache
   ↓
Browser

Q102: Constructor DI in Magento 2?

Constructor DI in Magento 2 injects dependencies automatically through Object Manager based on type hints and di.xml configuration.

Q103: Preference in Magento 2?

Preference in Magento 2 is a dependency injection mechanism used to globally override or replace a class/interface implementation with a custom class through di.xml.

Plugins are generally preferred over preferences because preferences completely replace the class behavior globally.

Q104: Virtual Types?

Virtual Types are lightweight dependency injection configurations used to reuse a class with modified dependencies, improving flexibility and reducing unnecessary class inheritance.

Virtual Types do not create physical PHP classes; they only exist in Magento’s DI configuration layer.

Q105: Proxy in Magento 2?

Proxy in Magento 2 is a lazy-loading mechanism that delays the instantiation of heavy objects until they are actually needed.

Proxies improve performance and reduce memory consumption by replacing expensive dependencies with lightweight generated classes that initialize the real object only on first usage.

Q106: Mview in Magento 2?

MView (Materialized View) in Magento 2 is a change-tracking mechanism used for incremental indexing, where database triggers capture entity changes and update indexers asynchronously.

MView enables partial reindexing by monitoring database table changes through changelog tables, improving performance compared to full reindex operations.

Entity Table Change
   ↓
MySQL Trigger
   ↓
*_cl (changelog table)
   ↓
Indexer Reads Changes
   ↓
Partial Reindex

Q107: How do you design Adobe Commerce Cloud architecture for multi-store, multilingual and high-traffic storefronts?

I start with concrete business constraints: number of storefronts, languages, geographies, and traffic patterns. For Adobe Commerce Cloud/Magento 2, I design around Magento’s multi-store capabilities early—store views, locales, currencies, and catalog structure—so the later customization doesn’t fight the foundation. I then define the integration boundaries. Catalog, inventory, pricing, and customer data flow get mapped to APIs/feeds or event-driven sync. I ensure the architecture supports both admin operations and storefront rendering efficiently. Next, I plan the backend/frontend split using REST APIs and GraphQL where it adds value. GraphQL helps reduce over-fetching and powers dynamic storefront experiences. I also align module structure so the platform customization stays modular and maintainable. For performance, I design for caching and static content deployment. I review hot paths like category listing, product details, search results, and cart/checkout. I also apply indexing strategy, query optimization on MySQL, and caching layers so response times stay stable during peak periods. I incorporate resilience and security from day one: least-privilege access for integration credentials, input validation, and safe handling of customer/order data. Payment and third-party extensions are integrated through well-defined interfaces to reduce coupling. Finally, I establish delivery and operational architecture: logging, monitoring hooks, deployment strategy, and rollback planning. I lead code reviews and enforce standards so the system is production-safe while remaining flexible for modernization later.

Q108: Describe your hands-on approach to optimizing GraphQL and Rest APIs for enterprise integrations?

I treat APIs as products: I define schemas, contract boundaries, and error behaviors up front. For Adobe Commerce Cloud, I design REST endpoints and GraphQL queries/mutations to match real client needs and minimize payload size and latency. On GraphQL, I focus on preventing N+1 problems by designing resolvers and data fetch paths carefully. I ensure fields are backed by efficient model/resource usage, and I validate that the resolver doesn’t trigger repeated database calls per item. For REST, I standardize request/response structures and implement consistent status codes. I also document pagination and filtering conventions, because enterprise systems rely heavily on predictable query semantics for order exports, customer sync, and catalog updates. Performance-wise, I optimize MySQL queries supporting the API layer—indexes, join patterns, and query plans. When needed, I introduce caching for computed responses, while respecting data freshness requirements. For enterprise integration, I design mapping layers for payload transformations. In my work, I’ve integrated order data flows and enterprise systems, and I ensure idempotency so repeated requests don’t duplicate records. I also handle webhooks and scheduled jobs with controlled retries. I implement security controls such as input validation, authentication/authorization for API consumers, and safe logging (no sensitive data in logs). I coordinate with teams on versioning strategies and rollout plans so integrations stay stable across releases.

Q109: How would you lead module and them customization in Adobe commerce cloud while keeping code review standards?

• I lead customization by enforcing a strong modular design. I break features into dedicated modules or plugins rather than changing core behavior broadly. This keeps upgrades smoother for Adobe Commerce Cloud/Magento 2 and prevents “tight coupling” that becomes painful later.
• During design, I identify the Magento extension points—events/observers, plugins, UI components, and layout/theme overrides—and select the least invasive path that meets the requirement. For example, when I need to adjust checkout or cart behavior, I prefer configuration and targeted overrides where possible.
• I also establish code review expectations early: consistent coding standards, proper namespacing, clear separation of concerns, and unit/integration testing where feasible. I review for performance regressions too—bad SQL patterns, excessive collection loads, and missing cache considerations.
• For frontend changes, I align themes and UI components to avoid fragile selectors. I use JavaScript patterns such as Knockout.js and AJAX for partial updates, ensuring that dynamic elements remain stable across browser variations.
• Third-party extension integration is another area I handle carefully. I validate extension compatibility, check installation/config steps, and isolate custom logic around the extension so future updates don’t break our behavior.
• Because I’ve coordinated development teams of 4–5 members, I run structured PR workflows, define acceptance criteria, and ensure each change has measurable outcomes (performance, UX, functional correctness). That keeps delivery predictable and production-ready.

Q110: Explain your strategy for caching, Elasticsearch/search and database query tuning in Enterprise Ecommerce?

• I approach performance as a system: caching strategy, search/indexing strategy, and database efficiency working together. I start by profiling key user journeys—category navigation, product listing, search, PDP, cart, and checkout—to locate bottlenecks.
• For caching, I decide what can be cached and for how long based on data volatility. In Magento/Adobe Commerce contexts, I focus on full page caching, block caching, and targeted cache for expensive computations. I also ensure cache invalidation doesn’t cause stale pricing or incorrect availability.
• For search, I’m comfortable with Elasticsearch/OpenSearch-style indexing. I treat mapping and relevance tuning as critical, not optional. I ensure the index pipeline is consistent with catalog updates and that the platform queries search backends efficiently.
• On database performance, I optimize MySQL queries by improving indexing, reviewing joins, and reducing unnecessary collection loads. I also work with stored procedures and functions when it improves batch operations and data exports, especially for enterprise synchronization scenarios.
• For high-traffic pages, I reduce server-side load by using proper pagination and limiting selected fields. I validate that API responses and GraphQL queries align with UI needs, because inefficient data fetching often becomes a hidden DB bottleneck.
• Finally, I ensure operational observability. I use logs and monitoring signals to detect slow queries, cache hit-rate issues, and search lag, then iterate. This approach helps maintain stable performance during campaigns and peak order periods.