EN

#

Technical Interview Guide

This guide was created to help you prepare for QuintoAndar's technical interviews, with detailed tips, study suggestions, examples, and free resources.

# Engineering

Here you will find tips and guidance that we have prepared for technical interviews in the field of Engineering.

Choose where to start or review everything at your own pace. Happy reading and happy preparing!

Code Interview

In this stage, we want to understand how you solve logic and programming problems. It’s a conversation to assess your reasoning, code structure, knowledge of algorithms, and communication skills.

A reminder: We understand if this is your first technical interview or if you’re returning after some time. The most important thing is to show your thought process and how you solve problems. And you can be sure: we’re rooting for you to do well! 🚀

  • What we expect:

    • Structured reasoning, with a clear explanation of what you are thinking.
    • The ability to break down a large problem into smaller parts.
    • Practical knowledge of data structures and algorithms.
    • Open and fluid communication with the interviewer.

  • ✅ Best practices in the interview:

    • Read and validate the problem with the interviewer.
    • Start with a simple solution and optimize it later.
    • Test your code with different inputs.
    • Name variables clearly.
    • Take a minute to think if you need to — this is completely normal and necessary!

  • 💻 Platforms for practice:

      Programming Language:

      Our coding interviews take place on the Codility platform and utilize the languages used by Grupo QuintoAndar. Check out some important guidelines to prepare effectively!

      Programming Languages We Use:

      • Java
      • Kotlin
      • Python
      • JavaScript/TypeScript
      • Dart
      • Go
      • C++
      • C#

      It’s important to know:

      • Declare variables and functions with ease.
      • Repeat with for, while, forEach, etc.
      • Manipulate arrays, stringsmaps/dictionaries
      • To write simple tests to validate outputs and think about edge cases

      📌 Example: “How does my function handle an empty list? What if all the numbers are the same?”

      Data Structures:

      Fluency in the following structures, their applications, and associated algorithms is essential:

      • Lists
      • Batteries
      • Rows
      • Sets
      • Hashmaps
      • Linked Lists
      • Trees (BST, AVL, Heaps)
      • Graphs

      Algorithms:

      • Ordering: bubble, insertion, merge, quicksort — entenda when to use each one;
      • Binary Search:
      • Recursion and Backtracking
      • Dynamic Programming (DP): subproblems,memorization tabulation

      Complexity:

      • Understand Big-O notation(time and space)
      • Evaluate the cost of your solution.
      • Compare approaches and explain the reason for your choice.

      📌 Example: “This solution runs in O(n²), but we can use a HashMap and reduce it to O(n).”

      Checklist – Code Interview

      To help you prepare with more confidence, we’ve put together a checklist of everything worth reviewing before the interview. Check off the items as you progress through your studies and practice!

      ✅ I chose a programming language in which I am fluent.

      ✅ I understand and can apply loop logic, conditionals, and recursion.

      ✅ I know how to structure my code using good practices (readability, modularity).

      ✅ I studied the basics of data structures: Arrays, HashMaps, Stacks, Queues, Trees, Graphs, and Linked Lists.

      ✅ I have studied and have knowledge of fundamental algorithms: Linear Search and Binary Search, Sorting Algorithms (Insertion, Merge, QuickSort), Recursion and Backtracking, basic Dynamic Programming (DP).

      ✅I understand what Big-O notation is.

      ✅ I know how to calculate the time and space required for my solutions.

      ✅I can compare alternatives and justify which one I chose.

      ✅I practiced explaining my reasoning out loud.

      ✅I tested my code with different cases (valid and edge cases).

System Design

In this stage, we’ll discuss system architecture, scalable solutions, reliability, and decision-making in complex scenarios. The goal is to see how you think about, structure, and evolve a solution.

The most important thing at this stage is to show how you think. There isn’t always a single “right” solution. What counts is clarity, well-justified choices, and your ability to discuss the trade-offs in depth.

  • What we expect:

    • Structured and layered reasoning (from macro to micro).
    • Trade-off analysis: the “why” behind your choices.
    • Proper use of components such as caching, queues, databases, and CDNs.
    • Quick estimates of capacity and performance (“napkin math”).
    • An open collaboration with the interviewer.

  • 💻 Sources for study:

  • 📚 How to prepare:

    Steps to guide your response:

    • Understand the problem: align scope, users, and objectives with the interviewer.
    • Start from the top level: think about the user journey → request → response.
    • Identify the components: frontend, API gateway, backend, database, cache, external services.
    • Details regarding interactions: protocols, latency, scalability, synchronization.
    • Make estimates: requests per second, payload size, data volume.
    • Explore alternativas: fila vs. polling, monolito vs. microsserviços, sync vs. async.
    • Consider failures: retry, timeout, circuit breaker, fallback. Understand the problem.Align scope, users, and objectives with the interviewer.
    📌 Example: “If the queue is unavailable, what happens to the messages? Do we need to retry? Do we need to guarantee ordering?”

      Tools for sketching your architecture:

      • I am a fig.— more visual, ideal for interactive workflows.

      Key concepts and techniques:

      • Load Balancing: round-robin, least connections, health checks.
      • Caching: Redis, CDN, TTL, cache stampede, cache warming.
      • ShardingandPartitioning: by ID,rangegeography, consistency.
      • Messaging: Kafka, RabbitMQ, SQS — ideal for decoupled systems.
      • CAP Theorem: trade-offbetween consistency, availability, and partition tolerance.
      • Scalability: vertical vs. horizontalauto-scaling.
      • Fault tolerance:fallback, retry, timeout, resilience.
      • Observability: metrics,logsstructured,tracingdistributed.
      • Align scope, users, and objectives with the interviewer.

      📌Tip: Practice explaining clearly why you chose or discarded these techniques in each scenario.

      Checklist – System Design

      Want to make sure you haven’t forgotten anything? We’ll help you with this handy checklist to review the key points:

      ✅ I can start with a high-level view (users → frontend → backend).

      ✅ I know how to divide the system into components and explain their responsibilities.

      ✅ I can estimate data volume, requests per second (QPS), etc.

      ✅ I am able to discuss trade-offs between different technical decisions.

      ✅ I studied the concepts ofLoad Balancing (Round-Robin, Least Connection), Cache (Redis, TTL, cache stampede), Messaging (RabbitMQ, Kafka), Database Sharding and Partitioning, CDNand content distribution strategies,Logging, monitoring e observability, Fault toleranceRetry, timeout, circuit breaker; NoSQL vs SQL, read vs write, eventual consistency.

      ✅ I practiced creating diagrams in tools like Excalidraw or FigJam.

      ✅ I have read or watched at least two case studies on system design.

      ✅ I solved problems in LeetCode, HackerRank, and NeetCode.

      ✅ I consulted the QuintoAndar blog or the blogs of tech companies.

      ✅ I participated in mock interviews or practiced with colleagues.

Attitudes that make a difference

An interview is a two-way street. We don’t expect perfect answers, but clarity of thought, good choices, and a constructive attitude. Here are some valuable tips to help you do well:

      Show your reasoning:

      • Speak out loud what you’re thinking, even if you’re still unsure.
      • Explain why you chose one path or discarded another.
      • If you’re stuck, share your thoughts: “I’m torn between two approaches and considering the implications of each…”
      • Did you make a mistake? No problem! Show us how you would adjust the solution.

      📌 Extra tip: Use terms like “my hypothesis is,” “considering the computational cost,” “I will prioritize clarity first and then optimize.”

      This demonstrates clarity, logic, and technical maturity, and avoids simply presenting the final answer without building a collaborative approach with the interviewer.

      Communicate clearly:

      • Summarize your reasoning in blocks: context → decision → next steps.
      • Validate the problem statement before you start coding: “Let me confirm that I understand the problem correctly…”.
      • If your mind goes blank, breathe, think for ten seconds, and then continue—it’s normal!
      • Engage the interviewer in the conversation with questions like, “Do you want me to optimize now, or can we proceed with the initial solution?”
      • Did you make a mistake? No problem! Show us how you would adjust the solution.

      📌 Extra tip: Speaking less is also a superpower — practice conciseness.

      This demonstrates good communication and builds trust and clarity in the process. Avoid long, uninterrupted answers—organization makes all the difference.

      Cooperate with the person interviewing you:

      • Demonstrate openness with phrases like: “That’s my initial idea, but I’m very open to suggestions.”
      • Listen carefully and avoid interrupting.

      📌 Extra tip: Show that you view the interview as a collaborative process, not a technical monologue.

      This demonstrates partnership and a willingness to learn. Avoid adopting a defensive stance or trying to appear “infallible.”

      Show self-awareness and progress:

      • Talk about what you’ve been studying or practicing lately.
      • Share real-world lessons learned, even if they’re simple.
      • Name a technical or interpersonal challenge that helped you grow.
      • If you don’t know something, that’s okay: “I don’t know it that well, but I would try to solve it thinking this way…”.

      📌 Extra tip: Give a concrete example that shows your evolution, such as: “I used to solve it this way, but today I would do it differently because of…”

      This demonstrates reflection, growth, and adaptation. Avoid generic answers or assuming that you “have no areas to develop.”

      Connecting with QuintoAndar makes a difference:

      • Tell us what attracts you to the product, the team, or the culture.
      • Show that you’ve done your research and are curious: “I saw a technical article of yours about X, I thought it was really cool!”
      • Talk about what you’re looking for in your career and how that connects with the company.

      📌 Extra tip: Ask a genuine question at the end of the interview. This demonstrates intention, purpose, and fit with the team.