Google Python Developer Interview Questions & Answers

At a high level, I would expose one versioned calendar API over HTTPS. The client signs in through OAuth2, receives a JWT, and sends it as a Bearer token. The API layer validates the token before routing requests. The API supports creating, updating, cancelling, listing, free-busy lookup, and attendee responses. Separate services own events, recurrence, RSVP data, availability, and notifications. Free-busy uses a cache with a fallback data source. Notifications run asynchronously. This adds operational work, but it keeps ownership clear and the main API path responsive.

The goal is to provide one secure API for scheduling and managing calendar events. The main challenge is separating event logic, security, availability, and notifications. I would explain the design by following the request from the client to each service.

1. Which clients and core use cases must the API support?
2. What authentication, authorization, and data-validation rules should I assume?
3. What scale, error handling, idempotency, and versioning requirements matter?

I would start with the user signing in through the Auth or Identity Provider.

The design uses OAuth2 with the authorization code flow or PKCE. OAuth2 is a standard way to grant application access. The identity provider returns an access token in JWT form, with an ID token also shown.

JWT means JSON Web Token. It contains identity and permission claims. The User or Client App sends the JWT as a Bearer token with each HTTPS request.

The client is outside the trusted internal system. HTTPS protects the request and JSON payload while they travel over the network. The HTTPS JSON response returns from the API layer to the client.

The Calendar API Gateway or REST API is the system entry point. It receives the client request over HTTPS.

The Authorization and JWT Validation component checks the token. It verifies the signature, expiry, scopes, and claims. Authentication proves the caller's identity. Authorization checks whether that caller may perform the requested action.

The request continues only after a successful validation result. If validation fails, the request must stop before reaching a domain service. The diagram does not define a specific failure status code, so I would keep that response generic.

The API uses version /v1. Versioning allows future API changes without immediately breaking existing clients.

The API surface contains six visible routes.

POST /v1/events creates an event. The Event Service returns 201 with the created event.

PATCH /v1/events/{id} updates an event. The response returns 200 with the updated event.

DELETE /v1/events/{id} cancels an event. The response returns 200 with the cancelled event.

POST /v1/events/{id}/responses records an attendee response. The response returns 200 with the recorded RSVP.

GET /v1/free-busy requests availability. The Free-Busy Service returns 200 with the free-busy data.

GET /v1/events?pageToken=...&pageSize=... lists events in pages. The response contains the items and a nextPageToken.

Recurrence is handled as part of event creation or updates. The Recurrence Service expands and validates recurrence rules shown in the event flow.

The Event Service owns creating, updating, cancelling, and reading events. It reads and writes the Calendar DB or Event Store.

The Recurrence Service expands and validates recurrence rules. It reads and writes Recurrence Data.

The Attendee Response Service records and reads attendee responses. It stores them in Response Storage.

Each service receives a request from the API layer. It performs its owned operation and returns a separate response. This keeps request and response directions clear.

The benefit is focused ownership. A change to recurrence logic does not need to change attendee-response storage.

The Free-Busy Service computes availability for the requested users and time range.

It first reads the Availability Cache or Index. A cache stores commonly used data for faster access. On a cache hit, the data returns directly to the service.

If the cache misses, the service follows the shown fallback path. It reads the Event Data or Index backup source. The data result then returns to the Free-Busy Service and back through the API.

The benefit is lower response time for common lookups. The downside is that the cache and fallback source must remain coordinated.

Event changes can enqueue notification work. The Notification Worker processes jobs and sends reminders, updates, or cancellation messages.

The Job Queue or Outbound Notifier holds the work. Outbound Channels deliver messages through email, push, or SMS.

This work is asynchronous. The event API response does not wait for final message delivery. This keeps event operations responsive, but notification delivery may happen later.

The design sends audit logs, metrics, traces, and alerts to Audit Log, Monitoring, and Observability. These signals help the SRE team investigate errors and performance issues.

The main trade-off is operational complexity. Separate services, data stores, caching, and queued work require more deployment and monitoring. We accept this because the design keeps security checks, ownership, and scaling boundaries clear.

The benefit of this design is clear ownership. The Event Service owns normal event operations. Other services own recurrence, attendee responses, availability, and notifications. This makes each part easier to test and scale. The downside is that more services need more monitoring and deployment work. JWT validation protects every API call, but clients must obtain and send a valid token. Version /v1 protects current clients, but future versions may need parallel support. Pagination prevents very large event responses. The availability cache makes free-busy requests faster, but cache misses require the backup Event Data or Index. Asynchronous notifications keep the main API fast, but delivery happens later. We accept these costs because the design keeps the request path clear and separates important responsibilities.

At a high level, I would separate fast translations from long-running batch jobs. Clients send HTTPS requests with a JWT through an API Gateway. The gateway authenticates callers, validates requests, checks quotas, and routes /v1 or /v2 traffic. POST /v1/translate returns translated text synchronously. POST /v1/detect-language returns the detected language. Batch creation returns 202 Accepted with a job ID, while workers process queued items in the background. The main trade-off is a simple synchronous experience versus the extra queue, worker, storage, and polling complexity needed for large jobs.

The goal is to provide one translation platform for quick requests and large jobs. The main challenge is keeping the client API simple while supporting validation, quotas, glossaries, and background processing. I would explain the design by following each request and response path in the diagram.

1. Which clients and core use cases must the API support?
2. What authentication, authorization, and data-validation rules should I assume?
3. What scale, error handling, idempotency, and versioning requirements matter?

I would start by placing an API Gateway in front of every endpoint. The client is an API Client or Developer App. It sends requests over HTTPS and includes a JWT. HTTPS protects data while it travels across the network. A JWT is a signed token used to identify the caller.

The API Gateway handles authentication and version routing. It supports paths such as /v1 and /v2. Version routing lets newer APIs evolve without immediately breaking older clients.

Before routing a request, the gateway calls Request Validation. That service checks the request schema and content. An invalid request returns the 400 Bad Request validation error contract.

The gateway also calls the Quota and Rate Limit Service. That service applies per-client request limits. A client that exceeds its quota receives 429 Too Many Requests. Unexpected platform failures return the shown 5xx Server Error contract. Each response returns through the gateway to the client.

For immediate translation, the client sends POST /v1/translate. The request reaches the gateway using HTTPS and JWT. After validation and quota checks, the gateway routes it to the Synchronous Translate API.

The Synchronous Translate API calls the Translation Orchestrator. The orchestrator coordinates the services needed for one translation.

If the source language is missing, it calls the Language Detection API. That API returns the detected source language.

The orchestrator then calls the Glossary Selection Service. A glossary contains approved translations for important business terms. The service reads the chosen glossary from the Glossary Store. It returns the selected glossary to the orchestrator.

The orchestrator sends the text and glossary to the Translation Engine. The engine returns the translated text to the orchestrator. The result then returns through the Synchronous Translate API and gateway. The client receives 200 OK with the translated text.

The client may only need to identify the source language. For that case, it sends POST /v1/detect-language.

The request passes through the same gateway checks. The gateway then routes it to the Language Detection API. The API examines the supplied text and returns the detected language. The response returns through the gateway. The client receives 200 OK with the detected language.

This endpoint avoids running the complete translation flow. It also lets clients inspect text before requesting translation.

For large workloads, the client sends POST /v1/batch-translations. The gateway validates the request and checks the client quota. It then routes the valid request to the Batch Translate API.

The Batch Translate API writes job metadata to the Batch Job Store. This store keeps the job identifier and current status. The API also places the work in the Job Queue.

The API does not wait for every translation to finish. It returns 202 Accepted with a job ID through the gateway. The job ID lets the client check the work later.

The Job Queue delivers queued work to Batch Workers. Workers can run in parallel when batch demand increases. Each worker invokes the Translation Orchestrator for its assigned items. The orchestrator uses language detection when needed. It also uses glossary selection and the Translation Engine.

Batch Workers write completed output to the Result Store. They also update job status in the Batch Job Store.

The client checks progress with GET /v1/batch-translations/{jobId}. This polling request passes through the API Gateway. The gateway routes it to the Batch Translate API.

The Batch Translate API reads the job status from the Batch Job Store. It reads result information from the Result Store when output is ready. The response then returns through the gateway to the client. The client receives 200 OK with job status, a result, or a download URL.

The request and response remain separate flows. The batch workers never send a direct business response to the client.

The gateway and translation services send operational data to Logging and Monitoring. The diagram also sends worker activity through this observability path. These one-way flows contain logs, metrics, and traces. They help operators find failures and measure system performance. They are not part of the client response path.

The synchronous API is simple and fast for small requests. The batch API prevents large jobs from blocking client connections. The downside is more operational complexity. The system must manage a queue, workers, job state, result storage, and polling.

The design separates quick work from long-running work. The synchronous endpoint is simple because it returns translated text in one request. The batch endpoint is better for large jobs because it returns a job ID and processes work later. The benefit is better responsiveness and easier worker scaling. The downside is extra infrastructure, including a queue, workers, job storage, result storage, and polling. Request validation stops malformed input early. Quotas protect capacity from one heavy client. Version routing allows /v2 changes while /v1 clients continue working. Glossaries improve translation consistency for special terms, but they add a storage lookup. Logging, metrics, and traces improve operations, but they also require monitoring systems. We accept these costs because global workloads can vary greatly in size.

At a high level, I would separate quick reads from slow VM lifecycle changes. The client authenticates with OAuth2 or OIDC, receives a JWT, and sends HTTPS requests through the API Gateway. The authorization layer checks identity, permissions, request data, current state, and API compatibility. List and inspect return 200 responses from the instance state store. Create, start, stop, resize, and delete return 202 with an operationId. A workflow executes the command, while the client polls GET /operations/{opId}. The downside is more components, but operations stay responsive, traceable, and reliable.

The API manages cloud virtual-machine instances through one controlled entry point. The main challenge is that reads finish quickly, while lifecycle changes take longer. I will follow the diagram from authentication through execution, status tracking, and errors.

1. Which clients and core use cases must the API support?
2. What authentication, authorization, and data-validation rules should I assume?
3. What scale, error handling, idempotency, and versioning requirements matter?

I would start by saying that the client manages VM instances through the API Gateway.

The supported operations are create, start, stop, resize, list, inspect, and delete. The client can also poll the status of a long-running operation.

The API Gateway is the public entry point. It terminates TLS, routes requests, applies rate limits, and assigns a request ID. TLS protects data while it moves across the network.

The gateway separates the external client from the internal cloud-provider services. It also gives the platform one place to control traffic.

The client first authenticates with the Identity Provider using OAuth2 or OIDC. The Identity Provider returns a JWT access token. A JWT is a signed token that carries the caller's identity and claims.

The client sends an HTTPS REST request with the JWT to the API Gateway. The gateway forwards the request and token to the Authorization, Validation, and Compatibility layer.

This layer validates the JWT. It then applies RBAC or IAM authorization. Authentication proves who the caller is. Authorization decides whether that caller may perform the requested action.

The same layer validates the request structure. It checks policy limits, current VM state, and API compatibility. For example, it can reject a start request when the VM is already running.

After all checks pass, the layer sends an authorized request to the VM Instance API Service.

List and inspect are quick read operations, so I would keep them synchronous.

The VM Instance API Service asks the Instance Metadata and State Store for the current instance data. This store holds details such as configuration, state, network information, and other instance metadata.

The store returns the state data to the API service. The service returns a 200 response to the API Gateway. The gateway then returns the instance list or instance details to the client.

This path does not involve the workflow or compute control plane because it does not change the VM.

Create, start, stop, resize, and delete can take several seconds or minutes. I would therefore process them asynchronously. Asynchronous means the work continues after the first API response.

The VM Instance API Service first creates a pending record in the Operation Store. The record tracks the operationId, operation type, target, status, progress, result, error, and timestamps.

The service then submits a long-running task to the Workflow, Task Queue, or Orchestrator.

The service returns 202 Accepted with an operationId through the API Gateway. A 202 response means the request was accepted, but the action is not complete.

This keeps the client connection short and gives the client a stable identifier for tracking progress.

The Workflow or Orchestrator sends the create, start, stop, resize, or delete command to the Compute Control Plane, Hypervisor, or Instance Agent.

That compute component owns the real VM lifecycle action. It returns execution status and heartbeats to the workflow.

The workflow sends progress and completion updates to the Long-Running Operations API or Operation Manager.

The Operation Manager updates the operation status in the Operation Store. After the lifecycle action succeeds or fails, it persists the current instance state in the Instance Metadata and State Store.

This separation keeps operation history apart from the latest VM state.

The client polls GET /operations/{opId} through the API Gateway. The gateway routes the request to the Long-Running Operations API or Operation Manager.

The Operation Manager returns a 200 operation status or result. The response travels back through the API Gateway to the client.

Errors use a separate path. Authorization failures, validation failures, and execution errors go to the Error Mapper. The Error Mapper converts internal failures into consistent API errors.

The diagram includes 400 for invalid requests, 401 for invalid authentication, 403 for denied access, 404 for missing resources, 409 for state conflicts, 422 for invalid operation details, 429 for rate limits, and 5xx for server failures.

The gateway, API service, workflow, operation manager, compute control plane, and error mapper send audit events, logs, and metrics to the monitoring system. These records support debugging, alerts, tracing, and security reviews.

The benefit of this design is that simple reads return quickly, while slow VM changes run in the background. Returning 202 with an operationId prevents long client connections. The downside is extra operational work because the system needs a workflow, operation manager, operation store, and polling flow. JWT validation and RBAC protect the API, but they add processing to every request. State validation prevents invalid actions, such as resizing a deleted VM. Idempotent request handling reduces duplicate work when clients retry, but it requires careful operation tracking. Compatibility checks reduce client breakage, but they increase testing effort. Central error mapping makes responses consistent. Rate limiting protects the platform, but quotas must remain fair. We accept these costs because VM lifecycle actions are slow and must be traceable.

At a high level, I would build one versioned API for managing topics, subscriptions, publishing, pulling, and acknowledgements. Clients send JSON over HTTPS with a bearer JWT to the API Gateway. The gateway asks Auth and Access Control to validate the token and check permissions. The Event Stream Service then updates topic metadata, appends events, reads retained events, or advances a subscription cursor. Responses return through the gateway with clear status codes and pagination tokens. The trade-off is more state and security checks, but the API becomes safer and easier to operate.

The goal is to let publishers send events and consumers read them safely. The main challenge is managing access, retained data, filters, and consumer progress. I would follow the diagram from the clients through the gateway and service.

1. Which clients and core use cases must the API support?
2. What authentication, authorization, and data-validation rules should I assume?
3. What scale, error handling, idempotency, and versioning requirements matter?

I would start with three client types. The Admin Client manages topics, subscriptions, retention, filters, and access policies. The Publisher Client sends events to topics. The Consumer Client pulls events and acknowledges completed work.

All public requests enter through the API Gateway / REST API. Every route uses version v1. The topic routes are POST /v1/topics and GET /v1/topics?pageSize&pageToken. The subscription routes are POST /v1/subscriptions and GET /v1/subscriptions?pageSize&pageToken. Event delivery uses POST /v1/publish, POST /v1/pull, and POST /v1/acknowledge. Administration also uses PATCH /v1/topics/{id}/retention, PATCH /v1/subscriptions/{id}/filter, and PUT /v1/access-policies.

The request first reaches the gateway as JSON over HTTPS. The caller includes a bearer JWT. A JWT is a signed token that identifies the caller.

The gateway sends a JWT validation and authorization request to Auth and Access Control. That component validates the token and evaluates access policies. It returns an allow or deny decision to the gateway. A missing or invalid token returns 401. A valid caller without permission returns 403. This keeps identity checking separate from permission checking.

After approval, the gateway sends a validated, versioned request to the Event Stream Service. The service owns the domain logic. It contains the Topics API, Subscriptions API, Publish API, Pull API, Acknowledge API, and Retention and Filtering.

The service returns a separate response to the gateway. The gateway then returns it to the original client. Successful operations use 200, 201, or 204, as shown. Errors may use 400, 401, 403, 404, 409, 429, or 500.

The Topics API creates and lists topics. It reads and writes the Topic Metadata Store. This store keeps topic configuration, retention settings, and access policies. List responses may return nextPageToken.

The Subscriptions API creates and lists subscriptions. It also manages each subscription filter. The Subscription State Store keeps subscription configuration, filters, cursors, and acknowledgement state. A cursor is the current reading position for that subscription.

The Publisher Client calls POST /v1/publish. The Publish API validates the event and appends it to the Event Store / Retained Topic Log. That store is an append-only event log for each topic. It returns a stored result with a message identifier. The client receives 201 Created on success.

The Consumer Client calls POST /v1/pull. The Pull API loads the subscription filter and cursor from the Subscription State Store. It then reads retained events from the event store. Filters are evaluated for that subscription during the pull. The response returns an events page and may include nextPageToken.

After processing, the consumer calls POST /v1/acknowledge. The Acknowledge API commits the acknowledgement and advances the cursor. The Subscription State Store saves the new state. A successful acknowledgement returns 204 No Content.

Retention is enforced in the Event Store / Retained Topic Log. Expired events are removed there. This keeps retention ownership close to the stored events.

The Event Stream Service sends audit and delivery logs asynchronously. Asynchronous means this logging does not block the business response. Audit / Access Logs stores access, delivery, and error records.

The benefit is clear ownership and strong access control. The downside is more state and more components. We accept that cost because durable event delivery needs stored events, subscription progress, and visible audit history.

The benefit of this design is clear separation. The gateway owns routing and common request handling. Auth and Access Control owns token checks and permission decisions. The Event Stream Service owns topic, subscription, publish, pull, acknowledge, retention, and filtering behavior. Versioning with /v1 protects current clients when the API changes. Pagination keeps list and pull responses small. The downside is more moving parts. The system must manage topic metadata, an append-only event log, and subscription cursors. Retention saves storage, but expired events are removed. Filters reduce unwanted events, but they add work during pull. Asynchronous audit logging improves visibility without blocking responses, but it adds storage and operational cost. We accept this because the design is safer and easier to debug.