Q1. What is the UiPath platform architecture (Studio, Robot, Orchestrator)?
Short answer: Studio builds automations, Robots run them, Orchestrator manages and schedules.
Strong answer: UiPath Studio is the IDE for designing workflows; Robots (attended/unattended) execute them on machines; Orchestrator is the central server for deploying, scheduling, monitoring, queue management and credential storage. This separation lets you build once and manage/scale execution centrally.
Likely follow-up: What is the difference between attended and unattended robots?
What the interviewer is checking: Platform fundamentals.
Common mistake: Confusing the roles of Studio, Robot and Orchestrator.
Q2. What is the REFramework and why use it?
Short answer: A robust enterprise template with state machine, config, logging and exception handling.
Strong answer: The Robotic Enterprise Framework is UiPath’s template built on a state machine (Init, Get Transaction, Process, End) with centralized configuration, queue-based transactions, retry logic, robust exception handling and logging. It provides a reliable, maintainable foundation for production automations instead of ad-hoc sequences.
Likely follow-up: What are the states in the REFramework?
What the interviewer is checking: Enterprise automation practice.
Common mistake: Building production bots as fragile linear sequences.
Q3. How do you handle exceptions in UiPath?
Short answer: Distinguish business vs application exceptions; use Try-Catch, retries and logging.
Strong answer: Application/system exceptions (element not found, app crash) are typically retried; business exceptions (invalid data per rules) are logged and skipped, not retried. Use Try-Catch, the REFramework’s exception handling, retry scopes, screenshots and clear logging. Correctly categorizing exceptions is key to reliable automation.
Likely follow-up: Why retry application exceptions but not business exceptions?
What the interviewer is checking: Robust bot design.
Common mistake: Treating all exceptions the same and retrying business errors.
Q4. What are queues in Orchestrator and when do you use them?
Short answer: Queues hold transaction items for scalable, resilient, distributed processing.
Strong answer: Orchestrator queues store transaction items that robots process one by one, enabling load distribution across multiple robots, automatic retries, status tracking and resilience (work isn’t lost if a bot fails). They’re central to the REFramework’s transactional model for high-volume, reliable automation.
Likely follow-up: How do queues enable multiple robots to share work?
What the interviewer is checking: Scalable automation design.
Common mistake: Processing high volumes without queues, losing resilience.
Q5. What are selectors and how do you make them reliable?
Short answer: XML fragments identifying UI elements; use stable attributes and dynamic selectors.
Strong answer: Selectors identify UI elements via attributes. Reliable automation uses stable, unique attributes, avoids volatile ones (indexes, dynamic IDs), and uses wildcards/variables for dynamic parts. Anchors and UI frameworks (UIAutomation) help. Fragile selectors are the top cause of bot breakage.
Likely follow-up: How do you handle a selector attribute that changes each run?
What the interviewer is checking: Practical automation reliability.
Common mistake: Relying on brittle, index-based selectors.
Q6. How do you manage credentials and configuration securely?
Short answer: Store credentials in Orchestrator assets/credential stores; config in assets/config file.
Strong answer: Keep credentials in Orchestrator credential assets or an integrated credential store (never hardcoded), and keep environment-specific settings in Orchestrator assets or the REFramework config file so bots move between environments cleanly. This secures secrets and makes automations maintainable.
Likely follow-up: Why never hardcode passwords in a workflow?
What the interviewer is checking: Security and maintainability.
Common mistake: Hardcoding credentials or config in the workflow.