# João Moura (2022-01-31)

## Presentation and getting to know about candidate (Total: 7m)
- Thank you for your time!
- We present ourselves
- Candidate presents himself.

- ISEP -> JAVA
- I2S -> .net + Angular + ionic
- Critical -> Node, Docker, Azure, SQL Server, MySQL, PHP

## Technical interview (Part 1) (Total: 1h15m)

A new product requirement states that all Talkdesk calls should be registered in a centralized system. A call has always two participants, a customer and an agent, and it can be either inbound (started by the contact) or outbound (started by the agent). The system must fulfill the following use cases:
- Ability to register a new call
- Ability to mark a call as finished
- Ability to retrieve the data associated with a given call
- Ability to list calls matching a given criteria. It should be possible to filter by:
-- Start and end dates
-- Status (in progress / finished)
-- Contact number

Clients should be able to interact with this system through a REST API. Each call pertains to a specific tenant (and a tenant can only access calls belonging to it), it must have an unique identifier and a new record must include the following information:
- Start date
- Source number
- Destination number
- Direction (inbound/outbound)

When a call is marked as finished, the record must also include the corresponding end date.

### 1. Try to keep it under 15 minutes

#### Basic Topics: Be attentive to the resource model the candidate proposes:

- Resource name (URI path) - did she opted for a plural or singular name? And did she assume a versioning schema from the beginning? If so, why?
- Chosen media type(s) (e.g. application/json or application/hal+json) and how that’s communicated (content-type and accept headers)
- Which HTTP methods did she opted for each operation (particularly the one to mark a call as finished)?
- Which status codes did she considered? (e.g. 201 for success creation, or doesn’t make any distinction between “successful” status codes?)
- Pagination of results on the endpoint that retrieves a list of calls
- How did the candidate dealt with the “multi-tenancy” requirement? Did she opted for having the tenant-id encoded in the payload or in the URI path? Did she assume the tenant-id is encoded on a JWT for instance?

#### Advanced topics

- How did the candidate designed the filter by “Contact number” operation? Contact number is not part of the resource representation, so a valid approach would be to allow ODATA like queries such as `?filter=source_number eq '<contact number>' or destination_number eq '<contact number>'` or any other strategy to specify filter queries.
- HATEOAS, especially on the endpoint that retrieve a list of calls
- Did the candidate mentioned how requests would be authorized? If so, evolve a bit around the topic of authentication/authorization (Basic Auth, OAUTH, etc)

> Notes: (sem grande know how acerca de REST API)
> - Usa headers over query string?
> - Hard limit para resultados / fazer paginação :cool:
>
> POST /chamada/iniciar
> Header??
> - numero de destino
> Status code:
> - 200 (:boom:)
> - 400 (não sabe os codigo de http)
> - 5xx (erro de servidor)
> POST /
> GET /chamada/status
> TOKEN da chamada? :thinking_face:
> POST ou PUT para terminar a call

--------------

### Try to keep it under 20 minutes.

#### What programming language would you choose for this implementation? And which application architectural style would you advise?

The intention here is to understand whether the candidate acknowledges the benefits of having a well defined structure to guide the application development (easier to build, change, maintain and test).
- Usually candidates will describe a layered architecture, and that’s fine. (Controller ↔︎ Application ↔︎ Persistence). How to change the persistence layer independently, for instance? Is is simple to test each layer’s components in isolation? (Dependency injection principle)
- If the candidate mentions other architectural styles such as Hexagonal (or any of its variants) or Clean Architecture that’s a plus.
- Important to ask which testing strategy she would apply (kind of related with the architectural proposal). Unit tests? Integration tests? E2E?

> Notes:
> - Message Broker para gerir os pedidos (rabbitMQ). REST via messages
> - backoffice para gerir requests?
> -
> - .NET (não tem grande ideia de arquitetura)
> - Camada do contacto :thinking_face: (entities?) -> properties? Contacto, Call, Direction
> - Confusao entre camadas, entidades e API parameters
> - "O controller iria chamar um factory". Mas a logica nao ficava no controller, ficava > na -
> - Usar entity framework para guardar
> - DI lifecycle :+-:
> - High Availability + Loadbalencers
> - MongoDB (mais simples)
> - Testing:
> - Testes aos requests - Sucesso / Falha (quais são os tipo de tests? mencionou unit tests)
> - Cria mocks (simular da realidade do cliente???)
> - Não precisa de testes de UI

--------------

### Try to keep it under 20 minutes.

#### We want this information to be durable and highly available. Which database would you recommend to store calls data?

The idea is to assess the rational behind the decision. Questions regarding durability, consistency and availability requirements from the candidate are signs of maturity, and thus should be seen as a plus. Keep in mind that the workload of the app consists mostly on writing new calls.
- RDBMS vs NoSQL? Why?
- If NoSQL is chosen, then what data model (document vs rows vs key-value) would suit better?
- What “ACID” guarantees each engine provides?
- Which indexes would the candidate suggest? (it’s a plus if she can provide an explanation of how indexes are implemented)
- How can we achieve High Availability (replication)?
- Tradeoffs of the different main approaches to replication (single-leader, multi-leader, leaderless) is a plus.

> Notes:

> :boom: (why?)
> - Usava SQL Server e Load Balancer
> - Master/slave sql server
> - No NOSQL knowledge
> - Caching dos identificadores?
> - Got lack of indexes but not composite indexes

----
> (deviamos forcar os candidatos a documentar os endpoints)
Possível action item: Fazer um template para isto :point_up_2:

--------------

### Try to keep it under 20 minutes.

#### We now have a MVP almost ready to go to production 🤘. How do we ensure it can cope with the expected traffic? And how can we protect the application from customer spikes?

- How does the candidate understand the current “state” of the application? (Monitoring) How can we assess where’s the “tipping point”?
- It’s expected that the candidate knows the different application scaling options: vertical and horizontal. What constraints should the system have in order to scale horizontally? (stateless applications)
- Does it make sense to apply rate limiting? What to do with requests that are shedded? (Ideally, the API should never loose any writes, so if the candidate suggests something in the lines of queueing requests to be processed asyncronously, that would be a strong plus).
- What options can we consider when the dataset grows to the extend that a single machine is no longer capable of storing and processing it? (partitioning/sharding - how?)
- Would the candidate change the database provider considering the above-mentioned non-functional requirement?

> Notes:
NA
--------------

## Technical interview (Part 2)

Product evolves with time and now there’s a new requirement: the API should return the contact information associated with a given call, so that it’s possible to feed an UI console with all calls and corresponding contacts. There’s a Contacts API where all the contacts' information is accessible.

The team is yet to define how to integrate the Calls API with the Contacts API. So far, the following approaches are on the table:

Shared DB

Rest Service Invocation

Message Passing Dataflow

### Try to keep it under 20 minutes. (Total: 0h30m)

#### Which integration option would you advise?

The idea is explore the tradeoffs of each integration “pattern”. It’s perfectly fine if the candidate suggests yet another approach or a “mix” of the proposed options.
- Shared database, although is arguably the simplest approach to get running, breaks the micro-services “shared nothing” principle and creates a huge coupling between the two systems.
- Intercommunication through the REST API allows both systems to evolve independently and does not break Contacts API encapsulation (the way data is structured is an implementation detail). However, it is a synchronous communication protocol which means that Calls API threads will spend a fairly amount of time waiting for replies from Contacts API (“Synchronous calls are particularly vicious amplifiers that facilitate cascading effects”, Michael T Nygard). So the candidate should be able to describe a few stability patterns to be applied on this integration point (timeout, circuit breaker, error handling). If she suggests caching, we should ask whether it’s distributed or in-process, how to ensure it doesn’t grow indefinitely and also which mechanisms HTTP support to enable resource caching.
- Leveraging a Message broker is the option that guarantees more decoupling between the systems. However, it’s not the most straightforward approach as it requires a consumer and a process to transform and store contacts data in the Calls API database. Also, all contacts data must be “backfilled” somehow (how would the candidate suggest to do that?)

> Notes:

DB access: nao se deve fazer, facil de partir a integraçåo
Event sourcing: dificil manter dados consistentes. mencionou que escolhia esta se os dados de contactos nao fossem alterados frequentemente

- possibility of degradation, nao incluindo o nome
- ter timeout?
- ter cache
- circuit breaker um pouco ao lado

Terminamos a entrevista? ok, sure

backwards compatability :sweat_smile:

--------------

### Try to keep it under 10 minutes.

#### The application must publish domain events to the org Message Broker whenever a call is created or when a call is marked as finished. How can we ensure at least once semantics?

Understand if the candidate is aware of the possible “semantics” (exactly once, at least once, at most once) and of strategies to guarantee them.
- Outbox pattern, where the “events” are persisted in the Calls API DB and there’s a worker whose responsibility is to fetch all non-published events and emit them. The key here is that the persistence of the event must be performed in the same “transaction” as the one that inserts/updates the call data.
- What are the consequences of at least once semantics? (duplication of events)

> Notes:

--------------