Write Pseudocode for Embedding Creation and Vector Search

Quick Overview

Write production-oriented pseudocode for batched document embedding and vector upserts plus filtered similarity search, including chunk identity, idempotency, normalization, and error handling.

Write Pseudocode for Embedding Creation and Vector Search

Company: Nike

Role: Software Engineer

Category: Machine Learning

Difficulty: medium

Interview Round: Technical Screen

## Prompt Write clear pseudocode for two production-facing functions: 1. `indexDocuments(documents)`: split approved text documents into chunks, create embeddings in batches, and upsert the chunks into a vector database. 2. `search(query, filters, topK)`: embed a query, search the vector database, apply metadata constraints, and return the best matching chunks with scores and source IDs. Explain error handling, idempotency, normalization, batching, and the assumptions behind the similarity score. ### Constraints & Assumptions - Every document has a stable ID, version, text, and metadata. - Embedding vectors from different model versions must not be compared in one index space. - Upserts and embedding calls can partially fail or be retried. - `topK` is bounded and filters include the caller's authorized scope. - Empty text and an empty or invalid query receive explicit behavior. ### Clarifying Questions to Ask - Which similarity metric and vector normalization does the index expect? - What chunking strategy and overlap are appropriate for these documents? - Can the vector service apply filters before approximate search? - What batch, rate, timeout, and cost limits apply to embedding calls? - Must search combine keyword and vector results? ```hint Make an upsert identity deterministic Derive each chunk ID from document ID, document version, and source span so retrying the same ingestion cannot create duplicates. ``` ### What a Strong Answer Covers - Shape-aware batching and validation of returned vector counts and dimensions. - Stable chunk and model-version metadata, deterministic upsert IDs, and bounded retries. - Correct normalization for cosine similarity or a clear alternative metric contract. - Permission filters in the retrieval operation rather than only after results are exposed. - Over-fetching and reranking when approximate search or filters can reduce the candidate set. - Partial-failure reporting, checkpointing, and a deletion or replacement path. - Pseudocode that distinguishes source records, embeddings, index rows, and returned matches. ### Follow-up Questions 1. How would you resume after the third embedding batch fails? 2. What goes wrong if query vectors are normalized but indexed vectors are not? 3. How would you migrate to a new embedding dimension? 4. Where would hybrid keyword retrieval enter the pseudocode?

Quick Answer: Write production-oriented pseudocode for batched document embedding and vector upserts plus filtered similarity search, including chunk identity, idempotency, normalization, and error handling.

|Home/Machine Learning/Nike
Nike logo
Nike
Aug 4, 2026
mediumSoftware EngineerTechnical ScreenMachine Learning
1
0

Prompt

Write clear pseudocode for two production-facing functions:

  1. indexDocuments(documents) : split approved text documents into chunks, create embeddings in batches, and upsert the chunks into a vector database.
  2. search(query, filters, topK) : embed a query, search the vector database, apply metadata constraints, and return the best matching chunks with scores and source IDs.

Explain error handling, idempotency, normalization, batching, and the assumptions behind the similarity score.

Constraints & Assumptions

  • Every document has a stable ID, version, text, and metadata.
  • Embedding vectors from different model versions must not be compared in one index space.
  • Upserts and embedding calls can partially fail or be retried.
  • topK is bounded and filters include the caller's authorized scope.
  • Empty text and an empty or invalid query receive explicit behavior.

Clarifying Questions to Ask Guidance

  • Which similarity metric and vector normalization does the index expect?
  • What chunking strategy and overlap are appropriate for these documents?
  • Can the vector service apply filters before approximate search?
  • What batch, rate, timeout, and cost limits apply to embedding calls?
  • Must search combine keyword and vector results?

What a Strong Answer Covers Guidance

  • Shape-aware batching and validation of returned vector counts and dimensions.
  • Stable chunk and model-version metadata, deterministic upsert IDs, and bounded retries.
  • Correct normalization for cosine similarity or a clear alternative metric contract.
  • Permission filters in the retrieval operation rather than only after results are exposed.
  • Over-fetching and reranking when approximate search or filters can reduce the candidate set.
  • Partial-failure reporting, checkpointing, and a deletion or replacement path.
  • Pseudocode that distinguishes source records, embeddings, index rows, and returned matches.

Follow-up Questions Guidance

  1. How would you resume after the third embedding batch fails?
  2. What goes wrong if query vectors are normalized but indexed vectors are not?
  3. How would you migrate to a new embedding dimension?
  4. Where would hybrid keyword retrieval enter the pseudocode?
Loading comments...