You build agent memory systems and RAG pipelines, and you're wondering if that work belongs in a GitHub portfolio for FDE roles. It does. But only if you package it to show what forward deployed engineers actually get evaluated on: production pragmatism, client empathy, and written communication, not just technical depth. Most GitHub portfolios read like a resume with extra steps. Yours shouldn't.
The honest answer is that your RAG and agent work is exactly the kind of evidence FDE hiring managers want to see, but it has a translation problem. A clean vector database integration says nothing about how you handled a client who wanted it air-gapped. A slick evaluation framework doesn't show how you explained a 12% recall drop to a non-technical stakeholder. GigaRAG helps you document and share that work in a way that surfaces those stories.
This guide gives you a practical framework: the FDE Portfolio Canvas. It maps your agent memory and RAG projects to the four competencies that matter, shows you five project types that signal readiness, and tells you plainly what your portfolio cannot show.
| At a glance | Details |
|---|---|
| Primary audience | Engineers building agent memory and RAG pipelines |
| Core signal | Client empathy, production pragmatism, clear communication |
| Key artifact | READMEs that map work to FDE competencies |
| Common mistake | Showcasing code without context or outcomes |
| Time to build | 2-4 weeks of focused effort |
| Biggest limitation | Cannot demonstrate real client interaction |
In This Guide
- What FDEs Actually Do (and Why Your GitHub Portfolio Matters)
- FDE Portfolio vs Traditional Software Engineering Portfolio
- The FDE Portfolio Canvas: A Framework for Agent Memory and RAG Builders
- GitHub Portfolio For FDE Roles: A Step-by-Step Guide
- What to Put in Your GitHub Portfolio for FDE Roles
- Five Portfolio Projects That Signal FDE Readiness
- How to Structure Your GitHub Profile and Repos for FDE Hiring Managers
- How to Prepare for FDE Roles Using Your Portfolio
- What Your GitHub Portfolio Cannot Show
- Red Flags to Avoid in Your FDE GitHub Portfolio
- Is the FDE Role Booming? What It Means for Your Portfolio
- Final Thoughts: Building a GitHub Portfolio for FDE Roles That Works
What FDEs Actually Do (and Why Your GitHub Portfolio Matters)
Forward Deployed Engineers sit at the intersection of engineering and consulting. You build, but you also deploy into customer environments, debug production failures on a call, and explain tradeoffs to people who don't read code. The role is technical. It's also relentlessly customer-facing.
The FDE persona: engineer + consultant
An FDE ships code that runs inside someone else's infrastructure. That means constraints you don't control: air-gapped networks, legacy auth systems, data that's messier than anything in your local dev environment. You can't just say "works on my machine." You have to make it work on theirs, then explain what you did in plain language.
The consulting half matters as much as the engineering half. You'll scope work with clients, push back when a request doesn't make sense, and write up what happened afterward. Hiring managers look for evidence you can do both. A repo that shows clean code but no written context signals you're a software engineer, not an FDE.
Why GitHub is your evidence locker, not your resume
A resume says you built a RAG pipeline. A GitHub repo shows how you built it, what broke, and what you'd do differently. That's the difference. FDE interviewers don't just ask "can you code." They ask "can you ship under constraints and communicate what you did."
Your portfolio is where you prove it. Every repo becomes a case study: here's the problem, here's the constraint, here's the decision, here's the outcome. Code alone won't carry that. Written context will.
[!note] FDE roles often emphasize client-facing skills, but your GitHub portfolio can only indirectly demonstrate them through clear communication and problem framing. Pair it with case studies or testimonials from collaborative projects.
FDE Portfolio vs Traditional Software Engineering Portfolio
| Factor | FDE Portfolio | Traditional SWE Portfolio |
|---|---|---|
| Primary focus | Demonstrating client empathy and production pragmatism | Showcasing technical depth and code quality |
| Key artifacts | READMEs with problem context, trade-offs, and outcomes | Code repositories and live demos |
| Communication emphasis | Clear explanations for non-technical stakeholders | Technical documentation and comments |
| Metrics highlighted | Client impact, deployment success, user adoption | Performance benchmarks, code coverage, scalability |
| Typical projects | End-to-end solutions with ambiguous requirements | Algorithmic challenges or open-source contributions |
The FDE Portfolio Canvas: A Framework for Agent Memory and RAG Builders
The FDE Portfolio Canvas maps four competencies — technical depth, client empathy, production pragmatism, and communication — to specific portfolio elements, so agent memory and RAG builders can structure their GitHub repos as FDE evidence rather than code dumps.
Most portfolio advice treats GitHub as a showcase for technical skill. FDE hiring managers read it differently. They're scanning for evidence you can operate inside a customer's constraints and explain what you did. The canvas gives you a mapping: each competency gets a column, each repo element fills a cell.
The four FDE competencies your portfolio must prove
Technical depth is the baseline. You need to show you understand vector databases, embedding tradeoffs, retrieval quality, and agent memory architectures. But depth alone won't get you the interview.
Client empathy means you built for someone else's problem, not your own curiosity. Production pragmatism means you shipped under constraints: rate limits, air-gapped environments, messy data. Communication means you wrote down why you made choices, not just what the code does.
A repo that only proves technical depth reads as a software engineer portfolio. An FDE portfolio proves all four, in writing, on every project.
Mapping agent memory work to FDE competencies
Agent memory systems are a strong FDE portfolio asset because they force constraint-driven decisions. You chose a memory architecture (summary, vector store, hybrid) based on context window limits and retrieval latency. Write that down. That's production pragmatism.
Client empathy shows up when you document whose problem the memory system solves. A customer support agent that forgets conversation history is a business problem, not just a technical one. Name the user and the failure mode.
Communication shows up in an ADR explaining why you picked a sliding window over full conversation storage. The code proves you can build it. The ADR proves you can justify it.
Mapping RAG pipeline work to FDE competencies
RAG pipelines map cleanly because they fail in production in ways that are easy to document. Chunking strategy, embedding model choice, reranking, retrieval quality metrics: each is a decision with tradeoffs. An FDE portfolio captures those tradeoffs in writing.
Technical depth shows in your evaluation framework: how you measured recall, precision, and latency. Production pragmatism shows in how you handled document updates, rate limits, or a vector store that didn't fit in memory. Client empathy shows in the use case you chose and why it mattered to a real workflow.
The honest catch: most RAG repos on GitHub are tutorials with clean data and no constraints. Yours needs the messy parts.
[!tip] For engineers building agent memory or RAG pipelines, create a dedicated repository that documents a pipeline you built, including the client problem, design decisions, and lessons learned. Use GigaRAG to help structure and share this documentation, making it easy for hiring managers to see your production pragmatism.
GitHub Portfolio For FDE Roles: A Step-by-Step Guide
- Audit your existing repositories for projects that involved ambiguous requirements or client-facing problem-solving.
- For each selected project, write a README that starts with the business problem and constraints, not the technical stack.
- Document the trade-offs you made and why, highlighting production pragmatism over theoretical elegance.
- Include a 'Client Impact' section with qualitative outcomes (e.g., 'Reduced manual review time by ~30% (verify at publish)').
- Add a 'Communication' section with links to blog posts, diagrams, or presentations explaining the work to non-technical audiences.
- Create a pinned repository that serves as your 'FDE Portfolio Canvas'—a meta-repo linking to your best work with a summary of competencies.
- Solicit feedback from peers or mentors on clarity and relevance to FDE roles, and iterate.
What to Put in Your GitHub Portfolio for FDE Roles
The canvas tells you what to prove. This section tells you what to put in the repo. Five elements carry the weight. Each maps to at least one competency, and the best ones map to three.
Project repos with production context
A repo without production context is a toy. You need the messy parts: rate limits you hit, data that didn't fit in memory, a client constraint that forced a design change. Write these in the README, not buried in commit messages.
The context matters more than the code. A hiring manager skims the README first. If it reads like a tutorial, they'll assume the project never left your laptop.
Written ADRs (Architecture Decision Records)
ADRs are the single highest-signal artifact for FDE roles. They prove you can justify a choice under constraints, which is most of the job.
Keep them short: context, options considered, decision, tradeoffs accepted. One page. No diagrams required.
Post-mortems on things that broke
Every production system breaks. Most engineers hide that. FDEs write it down.
A post-mortem shows production pragmatism and communication at once. What failed, what you tried, what fixed it, what you'd do differently. The "what you'd do differently" part is what interviewers read first.
Evaluation frameworks for real use cases
Don't show a RAG pipeline without showing how you measured it. Recall, precision, latency, cost per query. Pick metrics that matter to the use case, not the ones that make your numbers look good.
An evaluation framework with a real dataset and a documented threshold for "good enough" signals you think like someone shipping to a customer.
MCP servers or integrations with real constraints
MCP servers are useful because they force you to work with external systems you don't control. Authentication, rate limits, schema mismatches, timeouts. Document how you handled each.
The constraint is the point. A clean integration with a well-documented API proves less than a messy one with a real constraint you worked around.
Five Portfolio Projects That Signal FDE Readiness
The previous section listed what to put in a portfolio. This section gives you five concrete projects to build or adapt. Each one maps to a competency from the canvas, and each one has specific technical requirements that make it credible to an FDE hiring manager.
Project 1: An MCP server connecting 3+ real data sources
Build an MCP server that pulls from at least three data sources you don't control. A customer database, a third-party API, and an internal document store works. The point is the friction between them.
Document the schema mismatches. Show how you handled authentication across sources with different auth models. Include the rate limit you hit and the retry logic you wrote. The README should explain why you chose MCP over a custom integration, and what broke when you first connected all three.
This project proves technical depth and production pragmatism at once. It also gives you something concrete to walk through in an interview.
Project 2: An evaluation framework for a real use case
Pick a use case you actually care about. Customer support triage, contract review, internal search. Build an evaluation framework that measures recall, precision, latency, and cost per query.
The framework needs a real dataset, not synthetic data. Scrape or collect at least 200 examples. Define what "good enough" means before you run the first evaluation, and write that threshold down. Then show the results, including the failures.
Hiring managers read the failures first. A framework that shows where your RAG pipeline breaks is worth more than one that shows a 98% pass rate with no explanation of the 2%.
Project 3: An enterprise integration with real constraints
Enterprise constraints are the FDE's daily reality. Air-gapped deployments, SSO requirements, data residency rules, legacy systems that don't speak modern protocols.
Build an integration that respects at least two real constraints. If you can't access an actual enterprise environment, simulate the constraints honestly. Document what you couldn't test and why. The README should read like a deployment plan, not a demo.
This project signals client empathy. You're showing you can work inside someone else's rules, not just your own.
Project 4: A written architecture decision record (ADR)
An ADR is a one-page document that captures a decision, the options you considered, and the tradeoffs you accepted. Write one for a real decision you made in a project.
The context matters more than the decision itself. What were you building? What constraints forced the choice? What did you give up? Keep it under 500 words.
One good ADR beats five mediocre ones. It proves you can justify a choice in writing, which is most of what an FDE does in front of a client.
Project 5: A post-mortem on something that broke in production
Something broke. Write down what happened. Not a sanitized version. The actual sequence: what failed, what you tried, what fixed it, what you'd do differently.
The "what you'd do differently" section is where you prove you learn. Be specific. "I'd add better monitoring" is weak. "I'd add a circuit breaker on the vector database connection because the timeout cascaded into the embedding service" is strong.
A post-mortem shows production pragmatism and communication at once. It's the artifact that most clearly separates an FDE from a pure software engineer.
How to Structure Your GitHub Profile and Repos for FDE Hiring Managers
The projects matter less than how a hiring manager experiences them in the first 60 seconds. Most FDE hiring managers open your profile, scan your pinned repos, click one README, and decide whether to keep reading. You control that sequence.
Profile README: your 30-second pitch
Your profile README sits at the top of your GitHub page. It's the first thing anyone sees. Don't waste it on badges, visitor counters, or a list of every language you've touched.
Write three things, in this order: what you build (agent memory systems, RAG pipelines), who you build it for (enterprise customers, internal teams), and one line about how you work (on-site, with constraints, in production). Keep it under 80 words. A hiring manager should know what you do and whether you're an FDE candidate before they scroll.
Link to your two best repos directly from the profile README. Don't make anyone hunt.
Repo README template for FDE projects
Every FDE project repo needs the same skeleton. The README is your written communication sample, and it gets read before your code does.
Start with a one-paragraph problem statement: what was the customer or user trying to do, and what was blocking them. Then a "What this repo contains" section with three to five bullets. Then a "Constraints" section listing the real limitations you worked under: air-gapped environment, rate limits, legacy auth, data residency. Then a "What I'd do differently" section, even if it's two sentences.
Put the architecture diagram near the top, not buried at the bottom. A simple ASCII diagram or a linked image works. The point is that someone can understand the system in 30 seconds without reading code.
Pinning strategy: what to feature first
You get six pinned repos. Use them deliberately.
Pin your ADR repo and your post-mortem repo first. They're the artifacts that most clearly signal FDE communication skills, and they're rare enough that they stand out. Then pin your strongest technical project, the one with the most production context. Then your evaluation framework. Then one more project that shows range.
Don't pin six projects that all look the same. Two RAG pipelines with similar READMEs signals you built the same thing twice. One RAG pipeline, one MCP server, one evaluation framework, one ADR, one post-mortem, and one wildcard is a stronger spread.
Reorder your pins every few months. The top two slots get the most clicks. Put whatever best represents your current FDE readiness there.
How to Prepare for FDE Roles Using Your Portfolio
Your portfolio is not a static artifact. It's a script you can rehearse. The repos you built become the stories you tell, and the stories you tell decide whether you get the role.
Walking through a repo like an FDE, not a SWE
A software engineer walks through a repo by explaining the architecture: here's the service, here's the database, here's the API. An FDE walks through the same repo by explaining the customer problem first, then the constraints, then the tradeoffs.
Start with the problem statement from your README. Say who the customer was and what was blocking them. Then explain the constraint that shaped your design: air-gapped environment, rate limits, legacy auth. Then walk through the code, but only the parts where you made a decision. Skip the boilerplate. Nobody asks about your folder structure.
Practice this out loud. Time yourself. If you can't walk through a repo in five minutes and make the listener understand why you built what you built, your README needs work.
Anticipating the "what would you do differently" question
Every FDE interview asks this. It's not a trap. It's a test of whether you can critique your own work honestly.
You already wrote a "What I'd do differently" section in your README. That's your answer. But don't just read it back. Explain what you learned, what you'd change, and why the original decision made sense at the time given the constraints. That last part matters. It shows you understand that engineering is tradeoffs under pressure, not hindsight.
If you don't have a good answer for a repo, fix the repo or don't feature it in interviews.
Using your portfolio as an interview script
Before any FDE interview, pick three repos. For each one, write down: the customer problem, the constraint, the decision you made, and what broke. That's your script.
Don't memorize it word for word. Memorize the beats. When the interviewer asks "tell me about a time you dealt with a difficult constraint," you already have the story loaded. When they ask "what's the hardest bug you've fixed," you have the post-mortem.
The portfolio does the remembering so you can do the talking.
What Your GitHub Portfolio Cannot Show
Your GitHub profile proves you can build. It cannot prove you can sit across a table from a client who is frustrated, confused, or wrong, and still move the project forward. FDE work is consulting work with a compiler open. The portfolio shows the artifact, not the interaction.
Client interaction and stakeholder management
A repo cannot show how you handled a stakeholder who changed requirements three days before deployment. It cannot show whether you pushed back on a bad idea without burning the relationship, or whether you translated a vague complaint into a scoped fix. Those moments happen in meetings, on calls, in Slack threads. They leave no commit history.
Hiring managers know this. They read your portfolio for technical signal, then use interviews to probe the rest. If your repo claims you "worked with stakeholders," that's a claim, not evidence. They'll test it live.
Real-time debugging under pressure
Production breaks during a customer demo. The client is watching. You have minutes, not hours. A post-mortem written afterward shows what you learned. It does not show whether you stayed calm, asked the right questions, or kept the client informed while you fixed it.
That skill only shows up in live settings: take-home exercises with time pressure, pair debugging sessions, or a reference call with someone who watched you do it.
Complementing GitHub with case studies and writing samples
The fix is not to abandon GitHub. It's to add artifacts that capture the parts GitHub can't. Write a one-page case study for your best project: the client situation, the constraint, what you did, what broke, what you'd repeat. Publish it as a gist, a blog post, or a Notion page linked from your profile README.
Writing samples carry weight because FDEs write constantly: scoping docs, status updates, incident reports. A clear case study signals you can do that work. Your repos show the engineering. The case study shows the judgment.
Red Flags to Avoid in Your FDE GitHub Portfolio
Hiring managers scan repos fast. Most get under 60 seconds before they decide whether to keep reading. These are the things that get you skipped.
Toy projects without production context
A RAG pipeline that runs on a clean dataset with no users, no latency constraints, and no failure modes tells the reader you can follow a tutorial. FDEs work in messy environments. If your project never touched real data, real users, or a real deadline, say so plainly. Better: add the production context you did have, even if it was a hackathon or an internal tool.
Missing or thin READMEs
A repo with no README is a closed door. A README that says "RAG pipeline using LangChain" and nothing else is barely better. The README is where you show you can explain what you built and why. No README, no signal.
Code without written justification
Clever code without a note explaining why you chose that approach reads as either cargo-culting or hiding something. FDEs make tradeoffs constantly. Write down the tradeoff. One paragraph in the README or a linked ADR is enough.
No evidence of communication or collaboration
Solo projects with a single commit history and no issues, no PR discussions, no written decisions signal you worked in a vacuum. FDE work is collaborative by definition. Link to a PR review, a design doc, or a written post-mortem. If you don't have one, create one for your best project.
Is the FDE Role Booming? What It Means for Your Portfolio
Yes, but not evenly. Demand is concentrated in AI-native companies and enterprise AI teams shipping agent and RAG systems into production. The role is growing because someone has to sit between the model and the customer's actual environment. That someone is the FDE.
Current FDE market demand
The honest answer is it depends on what you mean by booming. Headcount at AI infrastructure companies and consultancies is up. But so is the applicant pool. Engineers who spent two years building RAG pipelines and agent memory systems are now competing for the same roles. The differentiator isn't that you can build. It's that you can show you can build in someone else's environment, under their constraints, and explain it.
Why a portfolio is table stakes, not a differentiator
A GitHub portfolio gets you into the conversation. It doesn't win the conversation. Every serious FDE candidate has one. What separates candidates is the written reasoning around the code: the ADRs, the post-mortems, the tradeoff notes. That's the part most portfolios skip, and it's the part hiring managers actually read.
Final Thoughts: Building a GitHub Portfolio for FDE Roles That Works
The FDE Portfolio Canvas gives you a structure. The five project types give you content. The honesty about what GitHub cannot show gives you credibility. None of it works without written communication.
That's the through-line. FDE hiring managers read your ADRs and post-mortems before they read your code. A repo with a clean README and a clear tradeoff note beats a technically impressive repo with no context. Every time.
Pick two projects from the five. Write them well. Skip the rest. A thin portfolio with strong written reasoning signals more FDE readiness than ten repos with bare code.
If you're building RAG pipelines or agent memory systems, GigaRAG helps you document and share that work with the evaluation frameworks and integration notes FDE hiring teams actually look for. But the tool matters less than the writing. Start there.
Frequently Asked Questions
Is the FDE role booming?
Yes, the Forward Deployed Engineer role is growing as companies increasingly need engineers who can bridge technical and client-facing responsibilities. The demand is particularly strong in AI and data-intensive industries.
What should I put in my GitHub portfolio?
Focus on projects that demonstrate client empathy, production pragmatism, and clear communication. Include READMEs that explain the problem, trade-offs, and outcomes, and highlight any collaboration with stakeholders.
How to prepare for FDE role?
Beyond technical skills, develop your ability to communicate with non-technical stakeholders and make pragmatic decisions under ambiguity. Build a portfolio that showcases these competencies through real or simulated client projects.
Is FDE a technical role?
Yes, FDE is a technical role that requires strong engineering skills, but it also demands client-facing abilities. You'll need to code, but also understand client needs and translate them into solutions.
What can my GitHub portfolio not show?
It cannot directly demonstrate real-time client interaction, empathy in live conversations, or the ability to handle unexpected client requests. Supplement your portfolio with case studies, testimonials, or recordings of presentations.
How do I map my RAG pipeline work to FDE competencies?
Highlight the problem-solving aspects: how you handled ambiguous requirements, made trade-offs for production, and communicated results. Document these in your READMEs and link to any client-facing artifacts.
About GigaRAG
GigaRAG is for agent memory and RAG pipeline builders. get this right. Whether you are working through GitHub portfolio for FDE roles or something adjacent, we publish what we have actually tested, including where it falls short.
