Preparación de entrevista — Full Stack Developer (Angular + .NET)

Memoriza esto — la estructura en una pantalla

El mismo guion de La prueba, comprimido a lo que de verdad tienes que traer en la cabeza el martes. El razonamiento completo de cada línea sigue viviendo allá — aquí solo el esqueleto y cómo clavarlo.

1 · El archivo, de arriba a abajo — tu mapa

Todo el ejercicio son 5 bloques que caen en el mismo orden siempre. Si memorizas el orden, cada bloque te recuerda al siguiente — es la misma "costura" que ya usas en SEUS (Interfaz→Service→Assembly→Promise), un peldaño más largo.

1. Encabezadotus 3 tablas comentadas + el hueco para las firmas del chat. Lo primero que escribes, sin pensar.
2. La consulta SQLen un bloque /* */, en español antes que en C#: SELECT → FROM+JOIN → WHERE → ORDER BY → OFFSET → COUNT. La pieza que decide.
3. El método de serviciomueves ese mismo SQL a un const string, abres conexión, QueryMultipleAsync, lees lista + total.
4. El endpoint[HttpGet], validas el rango (400), saneas paginación, delegas al servicio, Ok(result).
5. Los tiposal final, solo si no te los dieron por chat: el DTO de fila y el PagedResult<T>.

2 · La consulta, en 6 frases — tu retrieval practice

No memorices el SQL carácter por carácter. Memoriza estas 6 frases; el código sale solo de decir la frase en voz alta mientras tecleas — es exactamente la técnica de doble codificación (sección 4 abajo).

3 · Las 3 preguntas que SIEMPRE llegan después

4 · Cómo se queda pegado (esto sí es la clave, no el SQL)

La prueba — guion completo

Martes 8 sep, 8:00 am CDMX. Pantalla compartida, tu editor, un fichero suelto. No compila nada. Se valora el código y lo que dices mientras lo escribes.

[Order]    (OrderId PK, OrderDate datetime2, Status)
Product    (ProductId PK, Sku, Name)
OrderLine  (OrderLineId PK, OrderId FK→[Order], ProductId FK→Product, Quantity, UnitPrice)

Paso 0 · Antes de conectarte T-15 min

Paso 1 · El arranque primeros 2 min

// Prueba tecnica - reporte de lineas de pedido por rango de fechas, paginado
//
// Mis 3 tablas:
//   [Order]   (OrderId PK, OrderDate, Status)
//   Product   (ProductId PK, Sku, Name)
//   OrderLine (OrderLineId PK, OrderId -> [Order], ProductId -> Product, Quantity, UnitPrice)
//
// Firmas que me pasen por el chat:
//   (pegar aqui)

prueba.cs
├─ // encabezado: esquema + hueco para firmas   ← Paso 1.3 y 2.2
├─ /* ---- La consulta ----  ... ---- fin ---- */ ← Paso 3   (SQL a mano)
├─ using System.Data; using Dapper; ...          ← Paso 4.1
├─ public class OrderReportService(...) { ... }   ← Paso 4   (método de servicio)
├─ [ApiController] public class OrderReportController(...) { ... }  ← Paso 5  (endpoint)
└─ public record OrderLineRow(...);  public record PagedResult<T>(...);  ← al final (si no te dan los tipos)

Paso 2 · Las firmas por el chat clave

Las 3 piezas que siguen son un esqueleto invariante. Lo único que cambia con sus firmas son nombres y formas. Ese ajuste es la habilidad.

public record ReportQuery(DateTime From, DateTime ToExclusive, int Page, int Size);
public record OrderSummaryDto(int OrderId, DateTime OrderDate, string CustomerName, decimal Total);
public record Paged<T>(IReadOnlyList<T> Rows, long Count);
public interface IOrderReport { Task<Paged<OrderSummaryDto>> RunAsync(ReportQuery q); }

Si NO te dan firmas y dicen "estructúralo como lo harías": usas las tuyas (Paso 3–5) y explicas cada decisión. Prepárate para ambos.

Paso 3 · La consulta SQL pieza 1 — lo que decide

La escribes como SQL puro primero, en un bloque comentado, para pensarla sin pelear con el C#. Luego la mueves al método. La construyes por trozos, narrando.

/* ---- La consulta ----
SELECT
    ol.OrderLineId,
    o.OrderId,
    o.OrderDate,
    p.Name                       AS ProductName,
    ol.Quantity,
    ol.UnitPrice,
    ol.Quantity * ol.UnitPrice   AS LineTotal

FROM dbo.OrderLine AS ol
INNER JOIN dbo.[Order]  AS o ON o.OrderId   = ol.OrderId
INNER JOIN dbo.Product  AS p ON p.ProductId = ol.ProductId

WHERE o.OrderDate >= @fromDate
  AND o.OrderDate <  @toExclusive

ORDER BY o.OrderDate DESC, ol.OrderLineId DESC

OFFSET (@pageIndex * @pageSize) ROWS FETCH NEXT @pageSize ROWS ONLY;

SELECT COUNT(*)
FROM dbo.OrderLine AS ol
INNER JOIN dbo.[Order] AS o ON o.OrderId = ol.OrderId
WHERE o.OrderDate >= @fromDate
  AND o.OrderDate <  @toExclusive;
---- fin ---- */

Si preguntan por índices: "Un índice en [Order](OrderDate) para el filtro y el orden; y las FK de OrderLine (OrderId, ProductId) indexadas para el JOIN. Con eso no hay scan."

Paso 4 · El método de servicio pieza 2

using System.Data;
using Dapper;
using Microsoft.Data.SqlClient;

public class OrderReportService(string connectionString)
{
    public async Task<PagedResult<OrderLineRow>> GetOrderLinesAsync(
        DateTime fromDate, DateTime toExclusive, int pageIndex, int pageSize)
    {
    }
}

const string sql = @"
    SELECT ol.OrderLineId, o.OrderId, o.OrderDate,
           p.Name AS ProductName, ol.Quantity, ol.UnitPrice,
           ol.Quantity * ol.UnitPrice AS LineTotal
    FROM dbo.OrderLine AS ol
    INNER JOIN dbo.[Order] AS o ON o.OrderId   = ol.OrderId
    INNER JOIN dbo.Product AS p ON p.ProductId = ol.ProductId
    WHERE o.OrderDate >= @fromDate AND o.OrderDate < @toExclusive
    ORDER BY o.OrderDate DESC, ol.OrderLineId DESC
    OFFSET (@pageIndex * @pageSize) ROWS FETCH NEXT @pageSize ROWS ONLY;

    SELECT COUNT(*)
    FROM dbo.OrderLine AS ol
    INNER JOIN dbo.[Order] AS o ON o.OrderId = ol.OrderId
    WHERE o.OrderDate >= @fromDate AND o.OrderDate < @toExclusive;";

using var conn = new SqlConnection(connectionString);
using var grid = await conn.QueryMultipleAsync(sql,
    new { fromDate, toExclusive, pageIndex, pageSize });

    var items = (await grid.ReadAsync<OrderLineRow>()).ToList();
    var total = await grid.ReadSingleAsync<int>();

    return new PagedResult<OrderLineRow>(items, total, pageIndex, pageSize);

Paso 5 · El endpoint pieza 3

using Microsoft.AspNetCore.Mvc;

[ApiController]
[Route("api/reports")]
public class OrderReportController(OrderReportService service) : ControllerBase
{
    [HttpGet("order-lines")]
    public async Task<ActionResult<PagedResult<OrderLineRow>>> GetOrderLines(
        [FromQuery] DateTime fromDate,
        [FromQuery] DateTime toExclusive,
        [FromQuery] int pageIndex = 0,
        [FromQuery] int pageSize = 20)
    {
    }
}

if (toExclusive <= fromDate)
    return BadRequest("El rango de fechas no es valido.");

pageIndex = Math.Max(0, pageIndex);
pageSize  = Math.Clamp(pageSize, 1, 100);

var result = await service.GetOrderLinesAsync(fromDate, toExclusive, pageIndex, pageSize);
return Ok(result);

Paso 6 · Repaso en voz alta 30 s

Antes de decir "listo", recorre el código señalando en pantalla y recita:

• "Parámetros: todo parametrizado, nada concatenado."
• "Fechas: rango semiabierto, filtro SARGable."
• "Paginación: ORDER BY determinista que termina en columna única."
• "Recursos: using en conexión y grid."
• "Códigos: 200 con datos o lista vacía, 400 si el rango es inválido."
• "En un proyecto real le añadiría tests de integración del endpoint y logging; aquí lo dejo así por alcance."

Paso 7 · La transacción — te van a preguntar la otra mitad

Paso 8 · Angular (hablado)

Cómo respondes (aplica las 3 reglas de arriba): (1) directo, sin "creo/me parece"; (2) el núcleo técnico con el término exacto; (3) lo aterrizas en SEUS con un caso concreto — la tabla "Anclado a tu experiencia" te lo da hecho. Núcleo + término + ejemplo real = respuesta que convence.

Paso 9 · Cierre — tus preguntas

Cuando te pregunten "¿tienes dudas?", ten 2–3 listas. Muestran interés real:

• "¿Cómo está montado el acceso a datos hoy — Dapper directo, algún repositorio, una capa común?"
• "El frontend, ¿es un solo Angular o varios microfrontends con Native Federation ya en producción?"
• "¿Qué parte del roadmap tocaría este puesto los primeros meses?"
• "¿Cómo es el día a día del equipo — PRs, pair, ceremonias?"

Si te trabas recuperación

• No te quedes callado, pero tampoco te disculpes. "Voy a plantear las dos opciones" > "perdón, creo que…". Sin muletillas de duda (regla 1).
• No te quedes callado. "Estoy pensando cómo…" vale más que 20 s de silencio.
• Di la duda como opción. "Dudo entre poner el saneo de página en el controller o en el servicio; lo pongo en el controller porque es la frontera."
• Si olvidas sintaxis exacta (un método de Dapper, un atributo): dilo y sigue. "El método es QueryMultipleAsync o similar; la idea es leer dos result sets." No se mide memoria.
• Si un tipo de sus firmas no te cuadra: léelo en voz alta y pregunta. Nunca asumas.
• Si te quedas sin tiempo: "Me faltaría X; lo haría así:" y lo describes. Terminar el 80% explicando bien > el 100% en silencio.
• No sobre-ingenierices. Nada de repos genéricos, MediatR, Clean Architecture. Si lo mencionas: "para algo más grande metería X; aquí sobra".

Si el problema es otro preparado para todo

El esqueleto (Paso 3–5) no cambia — solo una cláusula o un método. Aquí, cada variante con el código y en qué parte del fichero va.

WHERE o.Status = @status

public async Task<PagedResult<OrderLineRow>> GetOrderLinesAsync(
    string status, int pageIndex, int pageSize)
{
    // ... mismo cuerpo ...
    new { status, pageIndex, pageSize }   // en QueryMultipleAsync
}

SELECT
    o.OrderId,
    o.OrderDate,
    COUNT(*)                        AS LineCount,
    SUM(ol.Quantity * ol.UnitPrice) AS OrderTotal
FROM dbo.OrderLine AS ol
INNER JOIN dbo.[Order] AS o ON o.OrderId = ol.OrderId
WHERE o.OrderDate >= @fromDate AND o.OrderDate < @toExclusive
GROUP BY o.OrderId, o.OrderDate
ORDER BY o.OrderDate DESC, o.OrderId DESC
OFFSET (@pageIndex * @pageSize) ROWS FETCH NEXT @pageSize ROWS ONLY;

SELECT COUNT(DISTINCT o.OrderId)
FROM dbo.OrderLine AS ol
INNER JOIN dbo.[Order] AS o ON o.OrderId = ol.OrderId
WHERE o.OrderDate >= @fromDate AND o.OrderDate < @toExclusive;

  AND (p.Name LIKE @term + '%' OR p.Sku LIKE @term + '%')

SELECT ol.OrderLineId, o.OrderId, o.OrderDate, p.Name AS ProductName,
       ol.Quantity, ol.UnitPrice, ol.Quantity * ol.UnitPrice AS LineTotal
FROM dbo.OrderLine AS ol
INNER JOIN dbo.[Order]  AS o ON o.OrderId   = ol.OrderId
INNER JOIN dbo.Product  AS p ON p.ProductId = ol.ProductId
WHERE ol.OrderLineId = @id;

public async Task<OrderLineRow?> GetByIdAsync(int id)
{
    using var conn = new SqlConnection(connectionString);
    return await conn.QuerySingleOrDefaultAsync<OrderLineRow>(sql, new { id });
}

[HttpGet("order-lines/{id:int}")]
public async Task<ActionResult<OrderLineRow>> GetById(int id)
    => await service.GetByIdAsync(id) is { } row ? Ok(row) : NotFound();

public async Task<int> CreateOrderAsync(NewOrder input)
{
    const string sql = @"
        INSERT INTO dbo.[Order] (OrderDate, Status)
        VALUES (@OrderDate, @Status);
        SELECT CAST(SCOPE_IDENTITY() AS int);";

    using var conn = new SqlConnection(connectionString);
    return await conn.ExecuteScalarAsync<int>(sql, input);
}

[HttpPost("orders")]
public async Task<ActionResult<int>> Create(NewOrder input)
{
    var id = await service.CreateOrderAsync(input);
    return CreatedAtAction(nameof(GetById), new { id }, id);
}

public async Task<int> CreateOrderWithLinesAsync(NewOrder order, IEnumerable<NewLine> lines)
{
    using var conn = new SqlConnection(connectionString);
    await conn.OpenAsync();
    using var tx = conn.BeginTransaction();
    try
    {
        var orderId = await conn.ExecuteScalarAsync<int>(
            @"INSERT INTO dbo.[Order] (OrderDate, Status) VALUES (@OrderDate, @Status);
              SELECT CAST(SCOPE_IDENTITY() AS int);",
            order, tx);

        foreach (var l in lines)
            await conn.ExecuteAsync(
                @"INSERT INTO dbo.OrderLine (OrderId, ProductId, Quantity, UnitPrice)
                  VALUES (@orderId, @ProductId, @Quantity, @UnitPrice);",
                new { orderId, l.ProductId, l.Quantity, l.UnitPrice }, tx);

        tx.Commit();
        return orderId;
    }
    catch
    {
        tx.Rollback();
        throw;
    }
}

WHERE o.OrderDate >= @fromDate AND o.OrderDate < @toExclusive
  AND (@lastDate IS NULL
       OR o.OrderDate < @lastDate
       OR (o.OrderDate = @lastDate AND ol.OrderLineId < @lastId))
ORDER BY o.OrderDate DESC, ol.OrderLineId DESC
OFFSET 0 ROWS FETCH NEXT @pageSize ROWS ONLY;

using var conn = new SqlConnection(connectionString);
await conn.OpenAsync();
using var cmd = new SqlCommand(sql, conn);
cmd.Parameters.AddWithValue("@fromDate", fromDate);
cmd.Parameters.AddWithValue("@toExclusive", toExclusive);
cmd.Parameters.AddWithValue("@pageIndex", pageIndex);
cmd.Parameters.AddWithValue("@pageSize", pageSize);

var items = new List<OrderLineRow>();
using var reader = await cmd.ExecuteReaderAsync();
while (await reader.ReadAsync())
    items.Add(new OrderLineRow(
        reader.GetInt32(0), reader.GetInt32(1), reader.GetDateTime(2),
        reader.GetString(3), reader.GetInt32(4),
        reader.GetDecimal(5), reader.GetDecimal(6)));

await reader.NextResultAsync();
await reader.ReadAsync();
var total = reader.GetInt32(0);

El archivo completo tu objetivo

Así queda prueba.cs al final. Practica tecleándolo entero, narrando, hasta que salga en ~12–15 min sin trabarte.

// Prueba tecnica - reporte de lineas de pedido por rango de fechas, paginado
//
// Mis 3 tablas:
//   [Order]   (OrderId PK, OrderDate, Status)
//   Product   (ProductId PK, Sku, Name)
//   OrderLine (OrderLineId PK, OrderId -> [Order], ProductId -> Product, Quantity, UnitPrice)
//
// Firmas del chat:  (aqui va lo que me peguen)

using System.Data;
using Dapper;
using Microsoft.Data.SqlClient;
using Microsoft.AspNetCore.Mvc;

// ---------- 1) El metodo de servicio ----------
public class OrderReportService(string connectionString)
{
    public async Task<PagedResult<OrderLineRow>> GetOrderLinesAsync(
        DateTime fromDate, DateTime toExclusive, int pageIndex, int pageSize)
    {
        const string sql = @"
            SELECT ol.OrderLineId, o.OrderId, o.OrderDate,
                   p.Name AS ProductName, ol.Quantity, ol.UnitPrice,
                   ol.Quantity * ol.UnitPrice AS LineTotal
            FROM dbo.OrderLine AS ol
            INNER JOIN dbo.[Order] AS o ON o.OrderId   = ol.OrderId
            INNER JOIN dbo.Product AS p ON p.ProductId = ol.ProductId
            WHERE o.OrderDate >= @fromDate AND o.OrderDate < @toExclusive
            ORDER BY o.OrderDate DESC, ol.OrderLineId DESC
            OFFSET (@pageIndex * @pageSize) ROWS FETCH NEXT @pageSize ROWS ONLY;

            SELECT COUNT(*)
            FROM dbo.OrderLine AS ol
            INNER JOIN dbo.[Order] AS o ON o.OrderId = ol.OrderId
            WHERE o.OrderDate >= @fromDate AND o.OrderDate < @toExclusive;";

        using var conn = new SqlConnection(connectionString);
        using var grid = await conn.QueryMultipleAsync(sql,
            new { fromDate, toExclusive, pageIndex, pageSize });

        var items = (await grid.ReadAsync<OrderLineRow>()).ToList();
        var total = await grid.ReadSingleAsync<int>();
        return new PagedResult<OrderLineRow>(items, total, pageIndex, pageSize);
    }
}

// ---------- 2) El endpoint ----------
[ApiController]
[Route("api/reports")]
public class OrderReportController(OrderReportService service) : ControllerBase
{
    [HttpGet("order-lines")]
    public async Task<ActionResult<PagedResult<OrderLineRow>>> GetOrderLines(
        [FromQuery] DateTime fromDate,
        [FromQuery] DateTime toExclusive,
        [FromQuery] int pageIndex = 0,
        [FromQuery] int pageSize = 20)
    {
        if (toExclusive <= fromDate)
            return BadRequest("El rango de fechas no es valido.");

        pageIndex = Math.Max(0, pageIndex);
        pageSize  = Math.Clamp(pageSize, 1, 100);

        var result = await service.GetOrderLinesAsync(fromDate, toExclusive, pageIndex, pageSize);
        return Ok(result);
    }
}

// ---------- Tipos (si no me los dan, los defino yo) ----------
public record OrderLineRow(
    int OrderLineId, int OrderId, DateTime OrderDate,
    string ProductName, int Quantity, decimal UnitPrice, decimal LineTotal);

public record PagedResult<T>(IReadOnlyList<T> Items, int Total, int PageIndex, int PageSize);

Dossier de la empresa

Qué es

NEWCO LLC es la razón social; la marca es Vita Tienda de Cocó March (VitaTienda): tienda en línea de salud, bienestar y cuidado personal — suplementos, vitaminas, probióticos, kits, skincare, limpieza natural. Cara de marca: Dra. Cocó March (naturópata; las fórmulas se presentan como diseñadas por ella; claim de marketing "más de 1 millón de mujeres").

Mercado: hispano de EE. UU. + Latinoamérica. Operación bilingüe español/inglés, atención toda la semana. Es una empresa de e-commerce con equipo de desarrollo interno — no una empresa de tecnología. Footprint pequeño (12 seguidores en Computrabajo, 5 vacantes, sin reseñas de empleados).

Modelo de negocio y arquitectura probable

• Storefront ES en store.dracocomarch.com/es/… → patrón de URL con id numérico = PrestaShop.
• Storefront EN/US en tienda.dracocomarch.com/en-us/collections/… → Shopify (mercado /en-us).
• Venden además en Amazon (tienda de marca CocóMarch) → de ahí el Amazon SP-API.
• Cobro con Stripe.

Lectura: lo más probable es que estén unificando PrestaShop + Shopify + Amazon detrás de un backend .NET propio (catálogo / inventario / pedidos como fuente de verdad), con Stripe para pago. "Integrar nuevos proveedores externos tomando ownership de toda la capa (back + front)" describe exactamente ese trabajo. Confírmalo preguntando (ver Preguntas → tus preguntas).

Stack (confirmado vs. inferido)

Valores declarados (para las conductuales)

"Calidad, servicio cercano al cliente, experiencia de compra confiable, innovación en producto, excelencia en servicio." Traducción práctica: equipo chico, customer-obsessed, no romper producción (18 módulos vivos), alto impacto individual, ownership de punta a punta.

Entrevistadores probables

Sin datos públicos de LinkedIn (empresa no indexada). Espera 1–2 personas: quien redactó las notas (perfil técnico senior / tech lead, escribe "guion" y "pruebas técnicas" — lleva el proceso) y posiblemente alguien de producto u operación. Trata las notas como si vinieran del tech lead que decidirá.

Huecos conocidos de este dossier

• Sin Glassdoor/Blind/LinkedIn (empresa pequeña). Compensado por las notas del entrevistador, que son señal directa.
• Sin banda de Levels.fyi útil para e-commerce chico en México — la pestaña Negociación usa estimación de mercado, marcada como tal.
• No se confirmó la librería de acceso a datos .NET (Dapper vs ADO.NET vs EF). Preparados los tres.

SQL Server — la pregunta que decide

"Escribe a mano un join de tres tablas con filtro por fecha y paginación, y explica la transacción." Practica hasta que salga sin pensar. Abajo: el modelo, luego cada concepto que te van a picar.

Esquema de práctica (móntalo en tu SQL Server local y siembra datos)

CREATE TABLE dbo.Customer (
    CustomerId  INT IDENTITY PRIMARY KEY,
    FullName    NVARCHAR(120) NOT NULL,
    Email       NVARCHAR(160) NOT NULL
);
CREATE TABLE dbo.Product (
    ProductId   INT IDENTITY PRIMARY KEY,
    Sku         VARCHAR(32) NOT NULL UNIQUE,
    Name        NVARCHAR(160) NOT NULL,
    Stock       INT NOT NULL CONSTRAINT CK_Product_Stock CHECK (Stock >= 0)
);
CREATE TABLE dbo.[Order] (
    OrderId     INT IDENTITY PRIMARY KEY,
    CustomerId  INT NOT NULL REFERENCES dbo.Customer(CustomerId),
    OrderDate   DATETIME2(0) NOT NULL,
    Status      VARCHAR(20) NOT NULL
);
CREATE TABLE dbo.OrderLine (
    OrderLineId INT IDENTITY PRIMARY KEY,
    OrderId     INT NOT NULL REFERENCES dbo.[Order](OrderId),
    ProductId   INT NOT NULL REFERENCES dbo.Product(ProductId),
    Quantity    INT NOT NULL,
    UnitPrice   DECIMAL(10,2) NOT NULL
);
-- índices que justifican el WHERE y el ORDER BY
CREATE INDEX IX_Order_Date       ON dbo.[Order](OrderDate DESC, OrderId DESC) INCLUDE (CustomerId, Status);
CREATE INDEX IX_OrderLine_Order  ON dbo.OrderLine(OrderId);
CREATE INDEX IX_OrderLine_Product ON dbo.OrderLine(ProductId);

El JOIN de 3 tablas + fecha + paginación — modelo a memorizar

-- Renglones de pedido de un rango de fechas, con cliente y producto, paginado.
SELECT
    o.OrderId,
    o.OrderDate,
    c.FullName                     AS CustomerName,
    p.Sku,
    p.Name                         AS ProductName,
    ol.Quantity,
    ol.UnitPrice,
    ol.Quantity * ol.UnitPrice     AS LineTotal
FROM dbo.OrderLine AS ol
INNER JOIN dbo.[Order]  AS o ON o.OrderId    = ol.OrderId
INNER JOIN dbo.Customer AS c ON c.CustomerId = o.CustomerId
INNER JOIN dbo.Product  AS p ON p.ProductId  = ol.ProductId
WHERE o.OrderDate >= @FromDate
  AND o.OrderDate <  @ToDateExclusive          -- intervalo semiabierto: NO uses BETWEEN
ORDER BY o.OrderDate DESC, o.OrderId DESC, ol.OrderLineId DESC   -- orden determinista
OFFSET (@PageIndex * @PageSize) ROWS
FETCH NEXT @PageSize ROWS ONLY;

Lo que TIENES que decir mientras lo escribes (esto es lo que califican)

• Intervalo de fecha semiabierto >= @From AND < @ToExclusive en vez de BETWEEN: si OrderDate tiene hora, BETWEEN '2026-01-01' AND '2026-01-31' pierde casi todo el día 31. Señal senior inmediata.
• Predicado SARGable: no envuelvas la columna en función (CAST(o.OrderDate AS date) = …) — mata el uso del índice. Filtra contra la columna cruda.
• ORDER BY determinista: OFFSET/FETCH exige ORDER BY, y si el orden no es único la paginación repite o se salta filas entre páginas. Siempre termina con una columna única de desempate (PK).
• OFFSET/FETCH (SQL Server 2012+) es el paginador estándar. @PageIndex base 0.
• Parámetros siempre (@FromDate), nunca concatenar strings: inyección SQL + reutilización de plan en caché.
• Índice: IX_Order_Date (OrderDate DESC, OrderId DESC) cubre filtro + orden; los FK de OrderLine evitan scans en los joins.
• INNER vs LEFT: si un producto puede estar borrado lógico y aun así quieres el renglón, LEFT JOIN dbo.Product. Decláralo como decisión, no por descuido.

-- Opción A: dos queries en el mismo request (recomendado para páginas profundas)
SELECT COUNT(*)
FROM dbo.OrderLine ol
JOIN dbo.[Order] o ON o.OrderId = ol.OrderId
WHERE o.OrderDate >= @FromDate AND o.OrderDate < @ToDateExclusive;

-- Opción B: en la misma query con ventana (cuesta un scan del set filtrado)
SELECT ..., COUNT(*) OVER() AS TotalRows
FROM ... WHERE ... ORDER BY ... OFFSET ... FETCH ...;

-- pasas el último (OrderDate, OrderId) de la página anterior
WHERE o.OrderDate >= @FromDate AND o.OrderDate < @ToDateExclusive
  AND (o.OrderDate < @LastDate
       OR (o.OrderDate = @LastDate AND o.OrderId < @LastOrderId))
ORDER BY o.OrderDate DESC, o.OrderId DESC
OFFSET 0 ROWS FETCH NEXT @PageSize ROWS ONLY;

La transacción — qué explicar

Lo más probable: una escritura de varios pasos (crear pedido + renglones + descontar stock), que es justo el tipo de operación de un POS / recepción electrónica.

CREATE PROCEDURE dbo.CreateOrder
    @CustomerId INT,
    @Lines      dbo.OrderLineTvp READONLY   -- table-valued parameter
AS
BEGIN
    SET NOCOUNT ON;
    SET XACT_ABORT ON;              -- error en runtime => rollback automático, sin transacciones "doomed"

    BEGIN TRY
        BEGIN TRANSACTION;

        INSERT INTO dbo.[Order] (CustomerId, OrderDate, Status)
        VALUES (@CustomerId, SYSUTCDATETIME(), 'Pending');

        DECLARE @OrderId INT = SCOPE_IDENTITY();

        INSERT INTO dbo.OrderLine (OrderId, ProductId, Quantity, UnitPrice)
        SELECT @OrderId, l.ProductId, l.Quantity, l.UnitPrice
        FROM @Lines AS l;

        -- descuento de stock con bloqueo, en una sola sentencia (evita race read-then-write)
        UPDATE p WITH (ROWLOCK)
            SET p.Stock = p.Stock - l.Quantity
        FROM dbo.Product AS p
        JOIN @Lines AS l ON l.ProductId = p.ProductId;

        -- el CHECK (Stock >= 0) ya protege; validación explícita para mensaje claro
        IF EXISTS (SELECT 1 FROM dbo.Product p JOIN @Lines l ON l.ProductId = p.ProductId WHERE p.Stock < 0)
            THROW 50001, 'Stock insuficiente para uno o más productos.', 1;

        COMMIT TRANSACTION;
        SELECT @OrderId AS OrderId;
    END TRY
    BEGIN CATCH
        IF XACT_STATE() <> 0 ROLLBACK TRANSACTION;
        THROW;   -- re-lanza; la capa .NET registra y traduce
    END CATCH
END

Conceptos que te van a picar sobre la transacción

Acceso a datos "escrito a mano" — patrones (ellos: "la mitad del trabajo")

Dapper (lo más común para SQL a mano en .NET)

public async Task<IReadOnlyList<OrderLineRow>> GetLinesAsync(
    DateTime fromDate, DateTime toExclusive, int pageIndex, int pageSize, CancellationToken ct)
{
    const string sql = @"
        SELECT o.OrderId, o.OrderDate, c.FullName AS CustomerName,
               p.Sku, p.Name AS ProductName, ol.Quantity, ol.UnitPrice
        FROM dbo.OrderLine ol
        JOIN dbo.[Order]  o ON o.OrderId = ol.OrderId
        JOIN dbo.Customer c ON c.CustomerId = o.CustomerId
        JOIN dbo.Product  p ON p.ProductId = ol.ProductId
        WHERE o.OrderDate >= @fromDate AND o.OrderDate < @toExclusive
        ORDER BY o.OrderDate DESC, o.OrderId DESC, ol.OrderLineId DESC
        OFFSET (@pageIndex * @pageSize) ROWS FETCH NEXT @pageSize ROWS ONLY;";

    await using var conn = new SqlConnection(_connString);
    var cmd = new CommandDefinition(sql,
        new { fromDate, toExclusive, pageIndex, pageSize }, cancellationToken: ct);
    var rows = await conn.QueryAsync<OrderLineRow>(cmd);
    return rows.AsList();
}

// transacción con Dapper
await using var conn = new SqlConnection(_connString);
await conn.OpenAsync(ct);
await using var tx = await conn.BeginTransactionAsync(ct);
try
{
    var orderId = await conn.ExecuteScalarAsync<int>(insertOrderSql, param, tx);
    await conn.ExecuteAsync(insertLinesSql, lines, tx);
    await conn.ExecuteAsync(updateStockSql, lines, tx);
    await tx.CommitAsync(ct);
}
catch { await tx.RollbackAsync(ct); throw; }

await using var conn = new SqlConnection(_connString);
await conn.OpenAsync(ct);
await using var tx = (SqlTransaction)await conn.BeginTransactionAsync(ct);

await using var cmd = new SqlCommand(sql, conn, tx);
cmd.Parameters.Add("@fromDate", SqlDbType.DateTime2).Value = fromDate;
cmd.Parameters.Add("@toExclusive", SqlDbType.DateTime2).Value = toExclusive;
cmd.Parameters.Add("@pageIndex", SqlDbType.Int).Value = pageIndex;
cmd.Parameters.Add("@pageSize", SqlDbType.Int).Value = pageSize;

await using var reader = await cmd.ExecuteReaderAsync(ct);
while (await reader.ReadAsync(ct)) { /* map por índice ordinal */ }
await tx.CommitAsync(ct);

// consulta LINQ equivalente
var q = _db.OrderLines
    .Where(ol => ol.Order.OrderDate >= fromDate && ol.Order.OrderDate < toExclusive)
    .OrderByDescending(ol => ol.Order.OrderDate).ThenByDescending(ol => ol.OrderLineId)
    .Select(ol => new OrderLineRow { /* ... */ })
    .Skip(pageIndex * pageSize).Take(pageSize);

// transacción explícita
await using var tx = await _db.Database.BeginTransactionAsync(ct);
// ... SaveChangesAsync varias veces ...
await tx.CommitAsync(ct);

// SQL crudo dentro de EF
_db.Database.SqlQuery<OrderLineRow>($"SELECT ... WHERE OrderDate >= {fromDate}");

Mini-drills (hazlos a mano y luego córrelos)

1. Top 10 productos más vendidos (por unidades) en un rango de fechas — GROUP BY + SUM + ORDER BY + TOP.
2. Pedidos sin ningún renglón — LEFT JOIN … WHERE ol.OrderLineId IS NULL o NOT EXISTS.
3. Total facturado por cliente y mes — GROUP BY c.CustomerId, DATEFROMPARTS(YEAR(o.OrderDate), MONTH(o.OrderDate), 1).
4. Clientes con más de 3 pedidos en el rango — HAVING COUNT(*) > 3.
5. El proc CreateOrder completo, probando el rollback (mete un producto con stock 1 y pide 5).
6. Reescribe la paginación de OFFSET a keyset.
7. Explica un plan de ejecución: dónde hay Index Seek vs Scan y por qué.

Angular a fondo — tu fuerte, hay que lucirlo

1 · Observable vs Promesa

En Angular: HttpClient devuelve Observable → al desuscribir cancela la petición (ideal para typeahead con switchMap). Eventos del Router, form.valueChanges, interop con Signals (toSignal(), toObservable()). El pipe async se suscribe y desuscribe solo.

Fugas de memoria = suscripciones sin gestionar. Soluciones: pipe async, takeUntilDestroyed() (Angular 16+), DestroyRef.

Los 4 operadores de aplanado — sé capaz de dar el caso de uso de cada uno

Extra: forkJoin (espera a que todas terminen — cargar datos de arranque), combineLatest (recombina al cambiar cualquiera — filtros), catchError + retry/retryWhen, shareReplay(1) (cachear la respuesta de un GET de catálogo).

2 · Native Federation — qué te aportó y qué te costó

Qué es: el concepto de Module Federation reconstruido sobre ESM nativo + import maps, para que funcione con el build moderno de Angular (esbuild/Vite). Webpack Module Federation dejó de encajar cuando Angular migró a esbuild; @angular-architects/native-federation es el reemplazo. La configuración de remotos vive en federation.manifest.json (el que tienes en tu repo).

Qué aporta (beneficios que viviste)

• Deploy independiente por microfrontend: cada equipo publica su módulo sin recompilar el monolito.
• Integración en runtime: el shell carga los remotos vía import maps al arrancar; cambiar un remoto no toca el host.
• Dependencias compartidas (Angular, RxJS, Material) se cargan una sola vez — negociación de versión con la config shared.
• Compatible con el pipeline esbuild actual (webpack MF no).

Qué cuesta (dolores concretos — esto es lo que confirma que lo usaste de verdad)

• Version skew: si un remoto trae otra versión de Angular/Material/RxJS que el shell, terminas con dos instancias de Angular, rarezas de DI, errores tipo NG0203 (inject fuera de contexto). Alinear shared con singleton: true y strictVersion.
• Comunicación / estado entre microfrontends: no hay solución integrada. Custom events, una librería compartida, o un bus de estado. Cada opción tiene su costo.
• Coordinación de routing entre shell y remotos (rutas hijas, lazy).
• Dev local: necesitas todos los remotos corriendo o mockeados; un federation.manifest.json por entorno.
• Debugging opaco: un error al cargar un remoto da poca información; hay que revisar el import map generado y la red.
• Testing cruzando la frontera entre microfrontends es difícil (los tests de componente aislados van bien; la integración no).
• SSR/hydration es más débil en este esquema.

Prepárate a dibujarlo: shell (host) → lee federation.manifest.json → genera import map → carga remoteEntry de cada microfrontend bajo demanda → monta su ruta. Deps compartidas resueltas una vez.

3 · Otros temas que pueden caer (tu fuerte, respuestas cortas)

• Signals vs RxJS: Signals para estado síncrono de UI (derivados con computed, efectos con effect); RxJS para flujos asíncronos y coordinación de eventos. Interop con toSignal/toObservable. No migrar todo a Signals porque sí.
• Change detection: Zone.js vs zoneless (Angular 18+); OnPush + inmutabilidad + async pipe; ChangeDetectorRef. Con Signals, CD granular.
• Standalone components (default desde v17): sin NgModules, imports: [...] en el componente.
• Lazy loading: loadComponent / loadChildren con rutas; @defer blocks para diferir render.
• Formularios: Reactive Forms tipados (v14+), validadores async, updateOn: 'blur'.
• Interceptores HTTP funcionales (v15+) para auth, retry, logging, y para la idempotency-key de las integraciones.

Testing — tu ventaja diferencial (Karma/Jasmine + Jest)

Eres el único del proceso que nombra las dos. Pregunta 3: "el último test de componente que escribiste y qué comprobaba." Necesitas una anécdota concreta y verificable. Rellena la plantilla con tu último test real.

Karma/Jasmine — patrones que debes poder escribir

describe('SaleButtonComponent', () => {
  let fixture: ComponentFixture<SaleButtonComponent>;
  let sales: jasmine.SpyObj<SalesService>;

  beforeEach(async () => {
    sales = jasmine.createSpyObj<SalesService>('SalesService', ['confirm']);
    await TestBed.configureTestingModule({
      imports: [SaleButtonComponent],                 // standalone
      providers: [{ provide: SalesService, useValue: sales }],
    }).compileComponents();
    fixture = TestBed.createComponent(SaleButtonComponent);
  });

  it('deshabilita el botón mientras confirma', fakeAsync(() => {
    sales.confirm.and.returnValue(timer(100).pipe(map(() => ({ ok: true }))));
    fixture.componentInstance.total = 250;
    fixture.detectChanges();

    const btn = fixture.nativeElement.querySelector('button') as HTMLButtonElement;
    btn.click();
    fixture.detectChanges();
    expect(btn.disabled).toBeTrue();                  // durante la operación

    tick(100);
    fixture.detectChanges();
    expect(btn.disabled).toBeFalse();
    expect(sales.confirm).toHaveBeenCalledOnceWith(250);
  }));
});

HttpTestingController

TestBed.configureTestingModule({ imports: [HttpClientTestingModule] });
const http = TestBed.inject(HttpTestingController);
service.getCatalog().subscribe(r => expect(r.length).toBe(2));
const req = http.expectOne('/api/catalog');
expect(req.request.method).toBe('GET');
req.flush([{ id: 1 }, { id: 2 }]);
http.verify();

Component harnesses de Angular Material (@angular/cdk/testing) — señal fuerte, ellos usan Material

const loader = TestbedHarnessEnvironment.loader(fixture);
const button = await loader.getHarness(MatButtonHarness.with({ text: 'Confirmar' }));
await button.click();
const input = await loader.getHarness(MatInputHarness);
await input.setValue('ABC-123');

Ventaja: el test no depende del DOM interno de Material; sobrevive a upgrades.

Jest — por qué tienen los dos y en qué difiere

Por qué mantener ambos: Jest para el ciclo rápido de TDD y CI (miles de tests unitarios de lógica y componentes); Karma cuando necesitas fidelidad de navegador real — APIs del DOM que jsdom no implementa bien, layout, algunas cosas de Material/CDK, o pruebas que rozan lo e2e. Si te preguntan "¿los unificarías?": depende del coste de mantener dos configs vs. lo que se perdería; migrar a Jest todo lo unitario y dejar Karma/Playwright para lo que exige navegador es una postura defendible.

Testing en microfrontends

Tests de componente aislados: sin cambio. Lo difícil es la integración cruzando la frontera de federación — ahí conviene contract testing entre shell y remoto, o e2e (Playwright/Cypress) sobre el shell ensamblado.

Lo que digo — guion oral

Todas las frases, sin relleno. Una idea por línea, en el orden en que salen.

Al empezar (antes de teclear)

• Repito el requerimiento con mis palabras: "Entonces necesitas…"
• Pregunto para acotar: "¿El reporte es por línea de pedido o agregado por pedido?" · "¿La fecha filtra por fecha de pedido?" · "¿Paginación con page/size o cursor?" · "¿Borrado físico o lógico?"
• "Empiezo por los datos y subo capa por capa: BD → repositorio → controller → pruebo la API sola → recién ahí el front."

Base de datos

• "El invariante vive en la BD: UNIQUE en SKU, CHECK en stock, las FOREIGN KEY — no solo en C#."
• "Índice en OrderDate descendente porque el reporte ordena y pagina por fecha."

Backend — modelos y repositorio

• "El DTO es lo que sale; el Input lo que entra. Con [Required]/[Range], si el body no cumple ASP.NET devuelve 400 sin un if mío."
• "SQL a mano, siempre parametrizado — nada de concatenar."
• "La página y el COUNT(*) en una sola ida con QueryMultiple."
• "Create: INSERT + SELECT CAST(SCOPE_IDENTITY() AS int) para devolver el id nuevo."
• "Update y Delete devuelven filas afectadas: 0 = no existe = 404."
• "DynamicParameters sobre el input para no repetir la lista de campos."

Backend — controller y códigos HTTP

• "GET lista → 200. GET /{id} → 200 o 404. POST → 201 con Location vía CreatedAtAction, o 400. PUT y DELETE → 204 sin body, o 404."
• "El 400 no lo escribo yo: lo da el binder por los DataAnnotations."
• "404 cuando ExecuteAsync afecta 0 filas — hace el DELETE idempotente."

Probar la API antes del front

• "Antes de tocar Angular, la API tiene que estar verde por sí sola."
• "Pruebo el caso bueno y el malo de cada verbo. El POST inválido tiene que dar 400, no 500."
• "Tests de integración con WebApplicationFactory: levanta la API real en memoria. Cubren 200, 404, 400 y el 201 de punta a punta."

El JOIN — las 6 frases, en orden

1. "Traigo columnas de las 4 tablas con alias claros; el total de línea lo calculo, Quantity * UnitPrice."
2. "Arranco por OrderLine, la tabla base, el grano del reporte."
3. "Le pego Order por OrderId, Customer por CustomerId, Product por ProductId; INNER porque solo quiero líneas completas."
4. "Rango semiabierto: >= @fromDate AND < @toExclusive, nunca BETWEEN — incluiría el límite y se rompe con horas."
5. "ORDER BY determinista que termina en columna única — OFFSET/FETCH lo exige o la paginación baila."
6. "Paginación en el server con OFFSET/FETCH; el COUNT con el mismo WHERE en la misma ida."

• "Filtro contra la columna cruda, sin CAST ni CONVERT: SARGable, usa el índice."
• "El cliente manda el primer día del mes siguiente como toExclusive."

La transacción (la otra mitad de la pregunta)

• "Este reporte es un SELECT: no necesita transacción explícita."
• "Donde sí: un alta que toca varias tablas —crear Order + sus OrderLine + descontar stock— la envuelvo en una transacción para que sea atómica: o todo o nada."
• "Con Dapper: connection.BeginTransaction(), lo paso a cada Execute, Commit() al final, Rollback() en el catch."
• "Aislamiento por defecto (READ COMMITTED) suele bastar; subiría a SERIALIZABLE solo si necesito que nadie inserte en el rango que estoy leyendo mientras decido."

Frontend

• "Standalone + Material. La tabla pagina del lado del servidor: el paginador pide la página al API, no traigo todo y filtro en memoria."
• "El proxy manda /api/* al backend; el servicio usa rutas relativas, sin líos de CORS."
• "Las interface son el contrato — mismos nombres que el JSON de .NET, en camelCase."
• "Form reactivo tipado con los mismos límites que el back. Feedback con MatSnackBar."
• "HttpTestingController: por cada método verifico URL, verbo y body, sin tocar la red."

Cierre — las 3 costuras

• "Base ↔ back: connection string + AddScoped<IDbConnection>; Dapper la usa por request."
• "Back ↔ front, red: el proxy reenvía /api/* al puerto del API."
• "Back ↔ front, permiso: CORS deja pasar desde localhost:4200, antes de MapControllers."
• "De la tabla que se ve en pantalla hasta el CHECK de la base, cada capa conectada y probada por separado antes de unirla."

Cuando algo truena

• "Leo el error… mi hipótesis es… voy a probar…" — en voz alta, sin quedarte callado.
• Si no sale en 1–2 min: "Lo dejo anotado y sigo; vuelvo si da tiempo."

Si preguntan por el tooling

• "Son snippets y un par de plantillas dotnet new de equipo. Dejan estructura y wiring; los cuerpos vacíos. El scaffolding con tooling estándar; la lógica la escribo yo."
• "Los repositorios se registran por convención: cualquier tipo *Repository del ensamblado entra como Scoped."

Si mencionas algo que aquí no aplica

• "Para algo más grande metería MediatR / un repositorio genérico / Clean Architecture; aquí no aporta y agrega ruido."

Cloud + Integraciones — AWS Lambda → Azure

Pregunta 4: "tu nube es AWS Lambda, no Azure: ¿qué esperas que cambie?" Buena señal si nombras lo que NO equivale. No finjas experiencia en Azure que no tienes; demuestra que sabes traducir conceptos y dónde están las trampas.

Tabla de equivalencias

La respuesta modelo (di esto)

"Mi experiencia de nube es AWS Lambda, así que lo que traigo es el modelo serverless: funciones stateless, cold starts, pensar en idempotencia y en límites de ejecución. Al pasar a Azure, lo que sí traslada casi directo es el enfoque event-driven, Blob ≈ S3, y App Insights me daría más de lo que tenía con CloudWatch. Lo que no equivale y tendría que aprender: Azure Functions usa bindings declarativos en vez de llamar al SDK a mano; Durable Functions no es Step Functions —es orquestación en código, no una máquina de estados JSON—; Cosmos no es DynamoDB en particionado ni en costeo; y la identidad pasa de IAM roles a Managed Identity + RBAC. Además, para el grueso de una API .NET probablemente no sería Functions sino App Service o Container Apps — ¿qué usan ustedes?"

Esa última pregunta te posiciona como alguien que piensa en arquitectura, no solo en servicios sueltos.

Integraciones externas — patrones (esto es el corazón del puesto)

"Integrar nuevos proveedores externos tomando ownership de toda la capa." Ten estos patrones listos:

• Idempotency keys: toda operación de escritura contra Stripe/Shopify lleva una clave; si reintenta, no duplica el cargo/pedido.
• Reintentos con backoff exponencial + jitter (Polly en .NET), y circuit breaker para no martillar un proveedor caído.
• Webhooks (Stripe: payment_intent.succeeded): verificar firma, responder 2xx rápido, procesar async, tolerar entregas duplicadas y fuera de orden.
• Nada de llamadas HTTP dentro de una transacción de BD. Patrón outbox: la transacción escribe el pedido + una fila "evento pendiente"; un worker lee la outbox y llama al proveedor.
• Rate limits: Amazon SP-API y Shopify tienen cupos por segundo; token bucket local + respetar los headers de rate limit.
• Conciliación: job periódico que compara tu estado vs. el del proveedor (pedidos, inventario) y corrige divergencias — clave con 3 canales de venta (PrestaShop, Shopify, Amazon).
• Anti-corruption layer: cada proveedor detrás de una interfaz propia; el dominio no conoce el JSON de Stripe.

Amazon SP-API / Shopify / Stripe — lo mínimo a saber

• Stripe: PaymentIntents (no Charges), 3DS/SCA, webhooks firmados, idempotency, modo test vs live, Stripe.net.
• Shopify Admin API: REST y GraphQL, OAuth de app, webhooks de pedidos/inventario, límites de llamada (leaky bucket).
• Amazon SP-API: reemplazo de MWS; OAuth con LWA (Login with Amazon), roles de IAM de Amazon, endpoints de Orders/Feeds/Reports, procesamiento async por "reports".

Preguntas — biblia de ensayo

Cada pregunta: por qué la hacen, la estructura de tu respuesta, un borrador con tu dato marcado, qué recalcar y qué evitar. Practica en voz alta y cronometrada. No memorices palabra por palabra — con la estructura clara improvisas.

El método STAR (para las conductuales)

Regla de oro: la A es donde te evalúan. Di "yo diseñé / yo decidí / yo escribí", nunca "el equipo hizo". 60–90 s por historia; si te pasas de 2 min, te cortan.

Parte 1 · Arranque

Parte 2 · Conductuales (STAR)

Parte 3 · Las incómodas (tu historial)

Parte 4 · Técnicas verbales (explicar, no escribir)

Las de escribir SQL están en SQL y Memoriza esto. Estas son para decirlas en < 1 min, con estructura.

Parte 5 · Cierre

Checklist de ensayo

Negociación

Tu marco (de tu perfil)

• Mínimo absoluto: 35,000 MXN/mes (no lo digas).
• Objetivo: hasta 80,000 MXN/mes.
• Perfil: ~5 años, full-stack, Angular senior, remoto.

Estimación de mercado (remoto MX, full-stack Angular + .NET, ~5 años)

Dado que es una LLC de EE. UU. y el puesto es "otro tipo de contrato" (probablemente honorarios/contractor), es razonable anclar en la parte alta.

Guion

Cuando pregunten "¿cuál es tu expectativa?"

Si insisten en que des número primero

El piso que dices (65k) es tu objetivo, no tu mínimo. Nunca ancles en 35k.

Contraoferta si ofrecen bajo

Qué preguntar antes de aceptar

• Esquema de contratación y moneda de pago.
• Prestaciones: ley vs superiores, aguinaldo, vacaciones, IMSS.
• Equipo: ¿dan equipo o hay stipend?
• Horario / zona horaria (empresa opera para EE. UU. — ¿esperan horario US?).
• Periodo de prueba, condiciones de terminación.
• Revisión salarial: ¿cada cuándo?

Qué NO decir

• Tu salario actual exacto (si preguntan, redirige a tu expectativa).
• Tu mínimo (35k).
• "Lo que sea que ofrezcan está bien."
• Un número aislado sin rango ni contexto de esquema.

Plan hasta el martes 8 sep, 8:00 am CDMX

Formato confirmado: fichero .cs suelto, 3 piezas (SQL + método + endpoint) + Angular hablado. No compila nada. El guion completo está en la pestaña La prueba; este plan es el calendario para dominarlo.

Hoy · lun 31 ago — Aterrizar

• Lee la pestaña La prueba entera, una vez, sin prisa. Entiende el por qué de cada línea.
• Primera corrida del bucle sin cronómetro: reset-prueba.bat, y teclea el esqueleto + la consulta mirando la biblia. Corre verificar.sql.
• Meta: tener claro qué archivo, qué herramienta y en qué orden. Cero código de memoria todavía.

Mar 1 – mié 2 sep — La consulta SQL, hasta que salga sola

• 3 corridas al día del bucle. Escribe la consulta sin mirar, narrando las 6 frases del Paso 3 (SELECT · FROM+JOIN · WHERE semiabierto · ORDER BY determinista · OFFSET · COUNT).
• Cada corrida: verificar.sql → confirma las 22 líneas de enero, la frontera (pedido 16 entra, 17 no), la página 2 sin repetir.
• Explica en voz alta, como si te preguntaran: por qué no BETWEEN, por qué sin CAST (SARGable), por qué el ORDER BY termina en columna única, OFFSET vs keyset.
• Meta: la consulta completa en < 4 min sin mirar, narrando cada cláusula.

Jue 3 – vie 4 sep — Las 3 piezas completas + la voz

• Corrida completa cronometrada: encabezado → SQL en comentario → const string → método (QueryMultiple, leer, devolver) → endpoint (validar, sanear, delegar). Todo en prueba.cs.
• Paso 2 — adaptación de firmas: ensáyalo con 2–3 juegos distintos (uno por línea, uno agregado con GROUP BY, uno con objeto de query). Que el read-back y el mapeo salgan solos.
• La transacción (Paso 7): recita las 5 frases hasta que fluyan — READ COMMITTED / el matiz de los dos SELECT / SNAPSHOT / escritura multi-tabla / SERIALIZABLE.
• Repasa 2–3 de los "Si el problema es otro" (agregado, búsqueda LIKE, un INSERT con transacción).
• Meta: las 3 piezas + repaso en voz alta en ~12–15 min, y saber adaptar la firma sin pensarlo.

Sáb 5 – dom 6 sep — Angular hablado + lo no técnico

• Angular (Paso 8): recorre la tabla de ~17 preguntas en voz alta. Prioridad: Observable vs Promesa, RxJS, Native Federation (ten un ejemplo concreto), change detection/signals, el último test que escribiste (uno real).
• AWS → Azure: memoriza la lista de "no equivale" (Functions, Entra ID, Cosmos, Blob, App Insights) y di lo que no equivale, no solo lo que sí.
• Inglés: ensaya tu respuesta 3 veces en voz alta y grábate. Lee una página de doc técnica en inglés en voz alta.
• No técnico: pitch de 60–90 s, por qué NEWCO, cómo cuentas tu historial (un solo empleador, pasante desde 2021). Pestañas Preguntas y Negociación.

Lun 7 sep — Simulacro + logística

• Simulacro completo, de punta a punta, en voz alta: saludo → (te dan la tarea) → reformulas → anuncias tu ejemplo → tecleas las 3 piezas narrando → respondes la transacción → Angular → tus preguntas.
• Una corrida final del bucle con cronómetro. Si sale limpia, para — no sobre-practiques la víspera.
• Repasa Cheat-sheet y Lo que digo. Duerme.

Mar 8 sep · 8:00 am — El día

• 10 min antes: lee Cheat-sheet y las 6 frases del JOIN. Respira.
• Abre prueba.cs (ya reiniciado). Verifica una vez más que Claude Code y Copilot están desactivados.
• Entra 2 min antes. Comparte pantalla. Piensa en voz alta desde el primer segundo.

Cheat-sheet — leer 10 min antes