Skip to content

Portfolio Insights (May 2025 – now)

Associate, Software Engineer II. J.P. Morgan Model Portfolios platform, used by financial advisors. Stack: Java, Spring Boot, React, EKS/ECS, Kafka, DynamoDB, Redis.

How to use this page

The STAR blocks are skeletons. The Situation/Task parts are true to the CV; the Fill in parts need your real detail (team size, weeks, what you personally decided). The technical depth sections are general and safe to say.

Owning features end to end

What the platform does, in one breath: portfolio managers publish model portfolios; advisors browse, compare and apply them to their clients, and download fact sheets and trade commentary.

STAR: how you run a feature

  • S: The product owner brings a need from advisors (e.g. "show how a fund fits an existing portfolio").
  • T: Turn it into something shippable on a tight timeline with other developers.
  • A: Discovery sessions with the PO (what decision does the advisor make with this?), a short design note (API, data, UI states, edge cases), split into tickets others can pick up, build the API and UI, review each other's code, release behind a feature flag if risky. Fill in: your flag/release mechanism.
  • R: Fill in: shipped in N weeks, used by advisors, any feedback or metric.
How do you handle a product owner who changes requirements mid-sprint?

Ask what decision changed and why; show the cost (what slips); offer options: swap scope, ship a thinner version first, or move the date. Write the agreement down in the ticket. Changes are normal; surprises are the problem.

How do you review code? What do you look for?

In order: does it do the right thing (requirements, edge cases), is it safe (null handling, transactions, security, concurrency), is it tested, is it readable and consistent with the codebase, performance last unless on a hot path. Comment with the reason, separate "must fix" from "nit", approve with small nits rather than block.

How do you estimate?

Break into tasks small enough to estimate (≤ 1 day), add unknowns explicitly as spikes, compare with similar past work, give a range not a point, and re-estimate when something new is learned.

Alternatives (ALT) and SMA support

STAR

  • S: The platform's models assumed traditional, daily-priced funds. The business wanted to offer alternatives and separately managed accounts, a line expected to scale fast.
  • T: Extend the model so ALT and SMA products could be part of models, without breaking existing ones.
  • A: Fill in: what you changed. Typical changes: new product types in the domain model, validations that depend on type (minimum investment, liquidity, pricing frequency), UI that shows the right fields per type, and backward compatibility for existing data and API clients.
  • R: Enabled the new business line. Fill in: number of new products, release date, no regressions.

Depth: how to extend a domain model safely

  • Model the variation explicitly: a product type with type-specific attributes (composition or a sealed hierarchy), not boolean flags sprinkled everywhere.
  • Push "what differs by type" into one place (strategy/polymorphism) instead of if (type == ALT) across the code.
  • Keep the API backward compatible: new optional fields, never change the meaning of an old one; version if you must.
  • Data: migrate existing rows to the default type; make the new column non-null only after backfill.
  • Test with existing data snapshots so old models render the same as before.
What is different about alternatives compared to mutual funds?

Illiquid (redeem monthly/quarterly, lock-ups), high minimums, accredited/qualified investors only, priced infrequently (NAV monthly or quarterly), capital calls for private equity. So: validations, eligibility, and performance calculations that cannot assume daily prices.

What is an SMA, and why would a client want one?

The client owns the individual securities directly in their own account, managed to a strategy. Benefits: transparency, customisation (exclude a stock), and tax-loss harvesting per security. Cost: higher minimums and more operational work (many accounts to trade).

Heatmap integration (incl. capital gains)

STAR

  • S: Advisors compared funds in a separate Heatmap app; models lived on our platform.
  • T: Let advisors analyse a model's composition in Heatmap, including capital-gains impact.
  • A: Fill in: how the integration worked (API call, deep link with model id, event). Typical pieces: an API contract agreed with the Heatmap team, a mapping layer between the two domain models, timeouts and retries, and a clear UI state when the other side is down.
  • R: Fill in: advisors could go from a model to analysis in one step.
How do you make a call to another team's service resilient?

Timeouts (connect and read), retries with backoff only for idempotent calls, a circuit breaker (Resilience4j) so a dead dependency fails fast, a fallback or a clear error state in the UI, and metrics/alerts on error rate and latency. Agree the contract (OpenAPI) and have contract tests so either side knows when it breaks the other.

Why does capital gains matter in a fund comparison?

Switching from a fund you hold to a "better" one means selling, which can realise a taxable gain. A fund that is slightly better on paper can be worse after tax. Showing the gain lets the advisor make the real trade-off.

White-labeling and co-branding on PDFs

STAR

  • S: Advisors share fact sheets and trade commentary with their own clients, but the PDFs carried only J.P. Morgan branding.
  • T: Let an advisor's firm name and logo appear on every generated PDF.
  • A: Fill in: where branding config lives, how logos are uploaded/validated, which PDF library/template. General design: branding config per firm (name, logo, placement rules), resolved from the user's firm at render time, injected into the PDF template; logos validated (type, size, dimensions) and cached; a fallback to default branding if missing.
  • R: Fill in: every model's PDF co-branded; advisors' adoption.
How would you generate PDFs at scale?

Template (HTML + CSS rendered to PDF, e.g. headless Chrome/OpenHTMLtoPDF, or a library like iText/JasperReports) filled with data. For many documents: generate asynchronously (queue → worker), store in object storage (S3), return a link; cache documents that only change when the model changes; key by model version + branding version so a branding change invalidates correctly.

What could go wrong with user-uploaded logos?

Huge files, wrong formats, malicious files (SVG with scripts), wrong aspect ratio breaking the layout, and trademark issues. Validate type by content not extension, limit size, re-encode to PNG, sanitise or forbid SVG, and preview before saving.

Fund suitability and single-click analysis

STAR

  • S: Advisors wanted to know whether adding a fund made sense given what a client already holds.
  • T: Design a fund-suitability feature based on correlation with the existing portfolio, and make portfolio analysis one click.
  • A: Fill in: what you designed (data source for returns, window, where computed, how shown).
  • R: Fill in.

Depth: correlation

  • Pearson correlation of two return series over the same dates: ρ = cov(X, Y) / (σX · σY), from −1 (opposite) through 0 (unrelated) to +1 (move together).
  • Use returns, not prices (prices trend, so everything looks correlated).
  • Portfolio return series = weighted sum of holdings' returns (weights as of each date, or current weights as an approximation).
  • Choices to defend: window (e.g. 3 years monthly), frequency (daily is noisy across time zones; monthly is standard), and missing data (align on common dates).
  • Correlation is not the whole story: also volatility, overlap of holdings, fees.
Where would you compute this, and how would you make it fast?

Return series are reference data that change daily at most: precompute or cache them (Redis) keyed by fund and date range. The correlation itself is O(n) over the series, cheap. For a portfolio, compute the weighted series once per request. Batch nightly for popular funds if needed.

Zero-downtime blue/green EKS and EMR migration

STAR

  • S: The platform had to move to new EKS (Kubernetes) and EMR (Spark/Hadoop) clusters. Fill in: why (version end of life, new account, security).
  • T: Migrate with zero downtime for advisors.
  • A: Fill in: your steps. General shape: build the green environment next to blue with the same config (infrastructure as code), deploy the same version, run smoke tests against green, shift traffic gradually (DNS or load balancer weights), watch error rate and latency, keep blue running for fast rollback, then decommission.
  • R: Zero downtime. Fill in: how many services, how long.

Depth: the hard parts in a blue/green migration

Concern What to do
Traffic switch Weighted routing (Route 53 weights, ALB target groups, ingress) to move 5% → 50% → 100%
Kafka consumers Two consumer groups on the same topics would process twice. Use the same group id so partitions rebalance across old and new, or stop blue consumers before starting green; consumers must be idempotent anyway
Scheduled jobs (EMR, cron) Exactly one side runs each job. Disable on blue before enabling on green; have a manual run book
Database Usually shared, not migrated at the same time. Schema changes must be backward compatible (expand → migrate → contract)
Sessions, caches Stateless services; sessions in a shared store; caches can start cold, so warm them
Rollback Keep blue warm until green is proven; switching back must be one change
Config and secrets Same IaC, diff the environments, rotate secrets once
Blue/green vs. canary vs. rolling?

Rolling: replace pods a few at a time (Kubernetes default); cheap, but two versions run together and rollback is another rollout. Blue/green: two full environments, switch traffic; instant rollback, double cost during the switch. Canary: send a small % of traffic to the new version and watch metrics before increasing; catches problems with real traffic at small blast radius. A cluster migration is naturally blue/green; releases inside it can be rolling or canary.

What is EMR and how does it differ from EKS?

EKS is managed Kubernetes for long-running services and containers. EMR is managed big-data clusters (Spark, Hive, Hadoop) for batch/stream processing jobs. Migrating EMR means jobs, their schedules, IAM roles, S3 paths and cluster configuration; migrating EKS means deployments, services, ingress, secrets and autoscaling.

Stack questions to prepare

What flows through Kafka in your platform?

Fill in one honest sentence: e.g. "events when a model is updated, which downstream services consume to regenerate documents or refresh caches". Then link to Kafka concepts: key choice for ordering, idempotent consumers, DLQ.

Why DynamoDB for that data? What is the key design?

Fill in the access pattern. Then: DynamoDB is chosen when access patterns are known and you need predictable single-digit-ms latency at any scale; design the partition key for even spread and sort key for range queries; GSIs for other access patterns. See Data.

What do you cache in Redis and how do you invalidate it?

Fill in. Common answer: reference data and computed results with TTL; invalidate on update events (from Kafka) for correctness, TTL as a safety net. See Data.