They’re structural. They are the main driver of your progress.

Hard skills get you in the room.

But invisible behavioral norms determine whether you can actually work together.

One of those norms is what I loosely call work ethic.

Not in the moralistic sense. Not “who works more hours.”
I mean something subtler.

Work ethic is the internal operating system that governs:

• How you communicate

• How you structure your work

• How you update stakeholders

• How you react to ambiguity

• How you define ownership

• How much proactive effort you put in before someone asks

When two people on the same team run radically different operating systems, friction appears instantly — and then quietly compounds.

It’s Not a Skill Gap. It’s a Norm Gap.

Teams often assume conflict comes from competence differences.

In reality, it often comes from unspoken expectation mismatches.

Imagine:

• Person A believes: “High ownership means I update stakeholders before they ask.”

• Person B believes: “If no one complains, things are fine.”

Both are capable. Both may be smart and hardworking.

But they are running different defaults.

It’s like a distributed system with mismatched timeout settings. One node expects responses in 200ms. Another thinks 5 seconds is reasonable.

Individually functional. Collectively unstable.

The Fairness Detector

Humans have a strong internal fairness detector.

If someone feels they’re carrying more cognitive load — chasing updates, clarifying expectations, compensating for silence — something shifts.

It’s not just irritation.

It’s emotional disengagement.

High performers are especially sensitive to perceived asymmetry of responsibility. Not because they’re dramatic — but because they’re optimizing for momentum.

When effort norms feel uneven, momentum dies.

Being Careful With the Word “Ethics”

We need nuance here.

What we sometimes label as “poor work ethic” may actually be:

• Burnout

• Unclear expectations

• Cultural background differences

• Different life stages

• Misaligned incentives

• Lack of psychological safety

A parent of three and a 24-year-old single engineer may both be excellent — but their energy allocation models differ.

This isn’t morality.

It’s calibration.

The Real Root Cause: Unspoken Norms

Friction hardens when teams don’t explicitly define:

• What does ownership mean here?

• What is “responsive”?

• What is an acceptable update cadence?

• What does “done” actually mean?

• What is our standard for proactive communication?

If these aren’t explicit, everyone silently enforces their personal defaults.

And personal defaults differ wildly.

Especially in small, high-leverage teams.

AI Makes This More Intense

As AI increases individual output, technical skill variance shrinks.

What becomes scarce?

• Trust

• Clarity

• Emotional regulation

• Coordination

• Predictability

Hard skills are being commoditized.

Behavioral reliability is compounding.

In smaller AI-augmented teams, each person’s operating model matters more, not less. A single misalignment has higher surface area.

Diversity of thought is powerful.

Diversity of core effort norms without shared expectations? Explosive.

The Real Lever

The solution isn’t demanding identical intensity.

It’s defining the minimum viable standard of ownership and communication so no one is guessing.

Strong teams don’t just hire for skill.

They hire — and calibrate — for:

• Ownership density

• Loop-closing behavior

• Proactivity under ambiguity

• Communication hygiene

Work ethic isn’t old-fashioned.

It’s infrastructure. It’s fundamental of great execution.

Often infrastructure failures don’t start loud.
They start subtle.
Then they become systemic.

The longer I work, the clearer this becomes:

Brilliance is valuable.

Predictability is compounding.

Larger context windows are unquestionably valuable—a model capable of processing millions of tokens meaningfully expands what can be handled in a single inference. However, for long‑running, production‑grade agents, the volume of relevant data inevitably grows beyond any fixed window. No matter how large the context becomes, there will always be additional data to collect, inspect, correlate, and transform.

The core challenge, therefore, is not eliminating context limits, but designing systems whose correctness and performance do not depend on fitting all relevant data into the model at once. This shifts the problem from prompt construction to system architecture: how data is collected, how it is processed, and how results are produced in a way users can trust.

A proof‑of‑concept agent can survive on a narrow prompt and a handful of examples. A production agent must operate over arbitrary, noisy, real‑world data—often at substantial scale—while remaining fast, predictable, and correct.

They are often referred to as deep agents. Systems such as Manus, Base44, Figma Make, and Claude Code fall into this category.

The challenge in building deep agents is not a lack of techniques—RAG, vector search, prompt compression, frameworks, and workflows are well covered in the literature—but the absence of guidance on composing these pieces into long-running, resilient systems that operate reliably over unbounded data.

While architectural patterns are beginning to converge—for example, the LangChain deep-agent harness—meeting production requirements around latency, completeness, and cost typically demands domain-specific design choices.

Across different implementations, including those that we have at Sweep.io, deep agents consistently encounter three bottlenecks:

1. Collecting large volumes of data

2. Processing large volumes of data

3. Producing large volumes of output

The remainder of this article presents a concrete approach to addressing each of these challenges.

Context: The implementation discussed here is drawn from our work at Sweep.io, where deep agents are used to analyze and reason over enterprise metadata. The system uses LangChain and LangGraph, but the ideas are framework‑agnostic. Python is used due to the breadth and maturity of its data‑processing and machine‑learning ecosystem.

Problem 1: Collecting and Storing Large Volumes of Data

At Sweep.io, production deep agents must reason over enterprise metadata: schemas, object relationships, dependencies, and historical change signals that describe how complex systems are wired together. As a result, a single agent typically exposes many tools—often dozens. While tool orchestration is a substantial problem in its own right, the unavoidable consequence is data volume: database records, filesystem artifacts, API responses, and search results.

Passing these payloads directly to an LLM—for example, via messages in LangGraph—results in rapid context exhaustion. Common mitigations include persisting data to disk or aggressively compacting tool outputs.

We adopt a different strategy.

Most tool outputs are inherently structured, and full materialization inside the LLM context is rarely necessary for effective reasoning. Instead of storing raw payloads or external files, tool outputs are normalized into dataframes (for example, using pandas or polars) and stored directly in the agent state on a per‑invocation basis.

Each dataframe is accompanied by lightweight metadata:

• Column names

• Total row count

• A concise summary including a small row sample

When contextual information is required, the LLM is provided only with this summary representation. For example,

In practice, this is sufficient for the model to infer the structure and semantics of the data without incurring the token cost of full materialization.

This design avoids filesystem complexity, substantially reduces token consumption, and keeps data immediately accessible for downstream computation.

Problem 2: Processing Large Volumes of Data

Once data has been collected and summarized, it must be processed. In Sweep.io’s case, users often ask questions whose answers are buried deep in enterprise metadata—across schemas, relationships, and historical changes—and require drawing conclusions from that structure. Answering such questions cannot be done in a single LLM invocation, regardless of context window size.

Instead, computation is decomposed across sub‑agents.

Given a dataset summary, a model is tasked with producing:

• Instructions for each sub‑agent

• A JSON schema describing the expected output

Each sub‑agent receives:

• Its slice of the dataframe

• Instructions that serve as a system prompt

• A structured output contract defined by the JSON schema

The sub‑agents themselves are deliberately minimal: ReAct‑style agents with structured outputs and no shared global context. They execute in parallel, yielding substantial reductions in end‑to‑end latency.

Parallel execution introduces operational constraints, particularly around rate limits and cost. These are addressed using standard techniques such as model load balancing (for example, via LiteLLM) or controlled, staggered execution.

Multiple orchestration strategies are possible. In our implementation, sub‑agents are invoked via a single tool call that triggers multiple subgraphs. This integrates naturally with the dataframe‑centric state model: aggregation reduces to collecting a list of JSON outputs and persisting them as a standard tool result.

Problem 3: Producing Large Volumes of Output

LLMs are inherently unreliable when asked to emit large volumes of homogeneous data. When asked to generate large tables or lists, models frequently return partial results and indicate that additional output has been omitted.

In production systems, this behavior is unacceptable.

A more reliable approach is to stop asking the LLM to generate the output directly and instead ask it to generate code.

As before, the full dataset cannot be passed back into the model. The dataframe‑plus‑summary representation again becomes critical. The model is provided with:

• Column definitions

• A small sample of the data

• A description of the required transformation and output structure

The model generates a Python script that performs the transformation. This script is executed in a sandboxed environment against the full dataset, producing a deterministic and complete result without relying on the LLM to stream large payloads correctly.

Conclusion: Let LLMs Reason, Not Execute at Scale

At scale, a consistent pattern emerges: LLMs excel at reasoning over summaries and deciding what should happen, but they are unreliable and inefficient when asked to directly manipulate or emit large volumes of data.

The architecture described here follows naturally from that observation:

• Large data is kept as structured dataframes in agent state

• Work is decomposed into parallel sub‑agents with strict, structured outputs

• LLMs are used to generate code for large outputs, rather than generating the outputs themselves

This positions the LLM as a planner and coordinator, while deterministic systems handle bulk data processing. In practice, this enables deep agents that remain predictable and performant at scale—in our case, processing requests touching approximately eight million tokens end‑to‑end in under six minutes without sacrificing correctness.

High-functioning teams still depend on a healthy distribution of seniority. Juniors aren’t disappearing — but the job is changing faster than interview processes are. Most companies are still giving LeetCode puzzles while Claude and Cursor generate full features in one prompt.

If a junior can paste your challenge into an AI tool and get a working solution, what exactly are you testing?

Needing to hire developers with little experience, I had to rethink everything. The answer isn’t banning AI or inventing “AI-proof” riddles. The answer is understanding what juniors actually do now, and deriving interview requirements from real workflows rather than tradition.

What Juniors Actually Do (With AI)

When a junior gets assigned a feature today, their real workflow looks like this:

• Understand product requirements and fill in the edge cases the PM missed

• Understand existing architecture and how the feature fits into it

• Use AI to draft technical design options and estimate time

• Use AI tools to generate the code

• Critically evaluate what AI produced — the accountability is still theirs

• Think through edge cases (API failures, null states, limits, memory issues)

• Debug flows when something breaks

• Move code through deployment

• Understand the full path to production

Some steps can be taught on the job. But several fundamentals cannot be built quickly. These are the skills we must test in interviews.

What Can’t Be Taught Quickly

Three core capabilities are non-negotiable:

1. Understanding existing architecture

Reading unfamiliar code, forming mental models of the system, understanding databases, APIs, queues, caching, and the shape of data flows.

2. Critical evaluation of AI output

AI produces working-but-flawed code constantly. Juniors must be able to spot poor complexity, hidden loops, redundant operations, unsafe assumptions, missing validations, and mis-architected logic.

3. Systematic debugging

When something breaks — and AI will cause bugs — can they form hypotheses, use logs, follow traces, and reason step by step? Or do they thrash around changing random lines?

These rely on the bedrock fundamentals you cannot install quickly: CS basics, code reading fluency, and structured thinking.

Two Additional Capabilities Now Matter More Than Ever

Learning velocity

AI accelerates development loops. Juniors who learn quickly from AI explanations, follow-up questions, refactoring suggestions, and failure patterns become exponentially better. Those who don’t become exponentially stuck.
This needs to be visible during the interview.

Communication as an engineering skill

A junior today writes more debugging narratives, AI prompts, clarifications, and design notes than code.
If they cannot explain their thinking, they cannot engineer — especially in an AI-mediated environment.

The Interview That Actually Works in 2025

Stage 1: Code Review Exercise (45 minutes)

Give them AI-generated code that “works” but contains obvious issues. Ask:

“An AI tool generated this for a feature. Review it as if a teammate asked for feedback.”

Example:

def search_users(query, all_users):
    results = []
    for user in all_users:
        if query.lower() in user[’name’].lower() or query.lower() in user[’email’].lower():
            results.append(user)
    
    # Sort by relevance
    sorted_results = []
    for result in results:
        score = 0
        for char in query:
            if char in result[’name’]:
                score += 1
        for sorted_result in sorted_results:
            if score > sorted_result[’score’]:
                sorted_results.insert(0, {’user’: result, ‘score’: score})
                break
        else:
            sorted_results.append({’user’: result, ‘score’: score})
    
    return [item[’user’] for item in sorted_results]

The goal is not for them to fix it, but to reason about it.

What to look for:

• Do they spot inefficiencies (multiple nested loops, unnecessary sorting logic, no pagination)?

• Do they mention missing edge cases (empty query, missing fields, large datasets)?

• Can they articulate specific improvements instead of vague sentiments?

• Do they ask clarifying questions? That shows communication and learning velocity.

Good answers sound like:

“This scales poorly because we search every user for every query. We should index, paginate, and rely on built-in sorting instead of a manual insertion sort.”

Red flags:

• No mention of performance at all

• Cannot verbalize edge cases

• Suggestions are abstract (“this looks bad”)

• No questions asked

Stage 2: Debugging + System Understanding (45 minutes)

Example 1: E-commerce Checkout Bug

Walk them through the system:

Frontend → API → Payment Service → Database

Show logs:

14:23:01 - Received checkout request
14:23:01 - Validating 1 items
14:23:01 - Total calculated: 100
14:23:01 - Calling payment service
14:23:02 - Payment service error: insufficient_funds
14:23:02 - Rolling back transaction
14:23:02 - ERROR: Failed to save order - Database connection timeout

Watch their process.

Do they see:

• Two separate issues?

• The order in which things fail?

• The likely cause vs. the actual symptom?

• The missing edge cases around retries, partial failures, and async work?

Then ask:

“We need to add an email confirmation when orders complete. Where does it fit, and what can go wrong?”

Good answers include queues, retries, idempotency, and separation between order success and email success.

Example 2: User Authentication Flow

Correct password. Login still fails.

Logs show:

Password validation: SUCCESS  
Token generation: SUCCESS  
Token validation failed: Invalid signature

A strong junior immediately investigates:

• environment mismatch

• rotated or misconfigured JWT secret

• multiple services using inconsistent keys

Then ask them to walk through a password-reset flow and failure modes.

The Skills You Are Actually Measuring

A strong junior in 2025:

• Reads code fluently and sees multiple categories of issues

• Evaluates AI output instead of accepting it blindly

• Debugs with hypotheses, not hope

• Understands system flows, not just isolated functions

• Communicates clearly

• Shows fast learning loops with guidance or AI explanations

A no-hire:

• Can’t spot obvious complexity problems

• Debugs by random changes

• Has no mental model of system structure

• Cannot reason out loud

• Treats AI output as ground truth

The Real Shift

Hiring juniors for their ability to write code is obsolete.
We now hire them for their ability to think about code.

AI expands their capability — if they have the fundamentals to judge, correct, and debug what the AI produces. Without that, AI becomes a liability.

The fundamentals matter more than ever, not less.
Because when AI is writing your code, the only safeguard between your product and absolute garbage… is whether your junior developer actually understands what they’re looking at.

It’s nearly impossible to both work and track this wildfire of innovation at the same time.

So here’s a practical alternative: a simple flow that works with any AI coding tool—VS Code + Copilot, Cursor, Claude Code, Antigravity, whatever. It takes 10 minutes to understand, and if you follow it, your speed and clarity go up immediately. It is battle-tested across real tasks, real teams, and real deadlines.

This flow doesn’t require mastering a special method or memorizing prompts. It mirrors how modern software engineering is quietly changing: less typing, more thinking; less magic, more structure.

Let’s get to it.

1. Start with a brief

Before touching an AI tool, write a short brief. Don’t overthink it. You can do it yourself or ask product to draft it. The goal is clarity, not poetry.

Something like this:

# Brief Title

Short basic description of the brief. What it should do and what’s the goal.

## User flows
1. User should be able to ...
2. User should do ...
3. ...

## Technical details
1. Database schema should have additional fields
2. Changes in controller method
3. ...

Add any necessary screenshots. Save it as brief.md.

This document becomes the anchor for the entire session. Without it, you and the AI drift.

2. Move to planning mode

Open your environment of choice—VS Code + Copilot, Cursor, Claude Code, anything—and give it the brief.

Now comes the critical step: planning mode.

Most AI tools have this mode. This is where the real work happens today.

Modern software engineering is increasingly about shaping correct abstractions, preparing schema changes, mapping flows across services, and making sure everything fits. AI will write the code, but you have to direct it correctly.

Switch your tool into planning mode and ask it to generate a plan for the change:

Here’s the brief @<link-to-brief.md> that we are going to work on. We are going to start with the backend. Analyze the brief, review the relevant files and suggest the implementation plan.

Review it carefully.

If your change spans multiple projects—frontend, backend, micro-services—split it into phases. Plan the backend first, review it, implement it. Then plan the frontend part and implement it. Divide and conquer keeps the AI focused and the output clean.

Once the plan feels solid, pause and ask the agent to review its own plan again. It often catches its own mistakes. That’s free quality assurance.

When everything makes sense, move forward.

3. Implement tests as a source of truth

Ask the tool to write tests before writing any actual implementation. This forces clarity and catches misunderstandings early.

Then stop.

Review the tests like you would review a junior developer’s work.

This rule matters: when AI writes your code and AI writes your tests, there is no ground truth. You must treat the tests as if you wrote them and your name is on the PR.

Once the tests look accurate and cover the right behavior, tell the AI to proceed with implementation.

4. Review the implementation like a real code review

AI will give you code quickly, sometimes brilliantly, sometimes recklessly. Go through it with the same attention you’d give a new intern’s pull request.

If something’s off, start another loop:

plan → implementation → review

Repeat as needed. It’s efficient and keeps everything aligned with your brief.

You’ll notice something interesting: the time you spend is no longer on typing code but on thinking through the system.

In other words, the part you were hired for.

Conclusion

This flow is simple, but it’s powerful.

Your attention shifts to the parts of engineering that actually matter—problem definition, careful planning, architecture, correctness. Code writing becomes a commodity job handled by the machine, and it’s only getting better.

The key is to treat the plan and the tests as your source of truth. Everything else is implementation detail.

If you follow this loop, your development cycle improves dramatically—easily 4× faster, often more, and the output stays solid.

AI is not replacing developers. It’s replacing typing. The real work is still thinking. And this flow gives you the cleanest way to do exactly that.

If mindset is the real differentiator, like I specified in the previous post, then you can’t rely on vibes and gut instinct. You need a system.
A simple, objective, clear and consistent way that helps every hiring manager evaluate candidates the same way, across roles and levels.

Think of mindset as a person’s internal operating system. You can’t fully see it, but you can observe how it behaves under stress, ambiguity, conflict, and curiosity. That’s what this scoring matrix captures.

This is the practical version. No HR poetry. No “leadership principles” carved into a stone tablet. Just eight dimensions that map directly to real-world performance, each scored from 1 to 5.

Use this in interviews, reference calls — anywhere you can observe how someone thinks, reacts, and updates.

Each dimension asks:

• What does their default behavior say about their internal OS?

• Not the story they tell, but how they think, react, decide, and update.

1. Ownership Bias (1–5)

What you test:

How they behave when no one tells them what to do.

Signals:

• 5: They assume responsibility by default, move without permission, unblock themselves, escalate only when truly stuck.

• 3: They act when told, need clarity, solve some problems but avoid messy ones.

• 1: They wait, deflect, blame ambiguity, or rely heavily on others.

Interview questions:

“Tell me about a time you owned something that wasn’t technically your job.”

“What do you do when everything is unclear?”

2. Learning Velocity (1–5)

What you test:

How they adapt, learn, and reinvent themselves.

Signals:

• 5: Curiosity engine, pursues depth, learns new things unprompted, shows recent updates to their worldview.

• 3: Learns when needed, but rarely self-directed.

• 1: Fixed playbook, defensive about feedback, outdated mental models.

Interview questions:

“What’s something you learned recently that changed how you work?”

“How do you choose your next learning focus?”

3. Intellectual Honesty & Ego (1–5)

What you test:

Ability to admit ignorance, change their mind, and surface real problems.

Signals:

• 5: Says “I don’t know” easily, changes position when shown evidence, separates ego from ideas.

• 3: Some openness, but occasionally defensive or overconfident.

• 1: Excuses, defensiveness, performs confidence instead of substance.

Interview questions:

“Tell me about a time you were wrong. How did you discover it?”

“What’s the hardest feedback you ever received?”

4. Problem-Solving under Ambiguity (1–5)

What you test:

How they navigate unclear or chaotic situations.

Signals:

• 5: Breaks chaos into constraints → hypotheses → next steps. Moves fast without losing precision.

• 3: Can solve problems with guidance, struggles with open spaces.

• 1: Stalls, waits for instructions, avoids mess.

Interview question:

“Imagine you join and your first task is blocked by missing info—designer away, spec unclear. Walk me through your next steps.”

5. Collaboration & Attitude Toward Others (1–5)

What you test:

How they handle people, conflict, and friction.

Signals:

• 5: Describes others fairly, seeks causes before blame, resolves tension with maturity, positive-sum orientation.

• 3: Generally fine but can get frustrated or rigid.

• 1: Blames, escalates, complains, creates friction.

Interview question:

“Tell me about someone difficult you had to work with. How did you make it work?”

6. Grit & Resilience (1–5)

What you test:

How they behave when things go wrong.

Signals:

• 5: Recovers fast, adjusts strategy, stays calm, doesn’t collapse emotionally or intellectually.

• 3: Some resilience, but struggles in repeated adversity.

• 1: Spiral of stress, catastrophizing, becomes ineffective quickly.

Interview question:

“What was a moment you were close to burning out? What did you do?”

7. Communication & Thinking Clarity (1–5)

What you test:

Whether their thinking is structured and their communication helps or confuses.

Signals:

• 5: Very clear articulation, structured thinking, concise, can reorganize thoughts on request.

• 3: Understandable but rambly.

• 1: Disorganized, unclear, talking in circles.

Live test:

Ask them to re-answer a question more cleanly. Watch how fast they improve.

8. Motivation & Internal Drive (1–5)

What you test:

Their “why”.

People driven by curiosity, mastery, and purpose behave differently from people driven by safety, ego, or convenience.

Signals:

• 5: Talks about impact, learning, autonomy, building.

• 3: Talks about work-life balance, stability, growth opportunities.

• 1: Talks about perks, titles, comfort, avoiding difficulty.

Interview questions:

“What do you optimize for in your career today?”

Scoring Interpretation

Add up the points across all categories (max 40).

34–40: Hire immediately. This is a self-propelled, low-friction, high-agency individual.

28–33: Strong candidate. Hire if role and team match their strengths.

22–27: Risky. They may perform but won’t bend reality for you.

<22: No. Skills won’t compensate for mindset gaps.

This scoring makes your hiring managers consistent without turning them into robots.

The HR interview is often the most vague part of the hiring process.

Yet after hiring over 200 people and interviewing more than 1,000, I can say with confidence: the biggest differentiator in how well people perform at work isn’t technical skill. It’s mindset and attitude.

There are two steps I once underappreciated but now consider crucial: the HR interview and reference calls. The insights from these two steps have a far greater long-term impact than any coding test, design challenge, or case study.

So the big question is: how do you actually assess mindset?

Subscribe now

Start with their story

Every good HR interview begins with curiosity, not interrogation.

Ask candidates to tell their story — how they got where they are, what moments shaped them, what patterns keep showing up. Then listen. Don’t rush to fill silence. Don’t judge too early.

As you listen, pick the threads worth pulling. Each story contains signals — how they react to failure, handle ambiguity, talk about others, and learn from mistakes. Once the story unfolds, you can start to dive deeper using the frameworks below.

1. Let them narrate their defaults

People show mindset when they’re asked to explain how they think, not just what they achieved.

Try prompts like:

• “Tell me about a time you disagreed with your manager or founder. What did you do?”
  You’re listening for intellectual honesty, agency, and humility — not a heroic story.

• “Describe a time you hit a wall. What was your first instinct?”
  This shows ownership versus avoidance, problem-solving style, and whether they lean toward initiative or helplessness.

• “What’s a mistake you made that changed how you operate today?”
  A-players speak openly, reflectively, and show how they’ve updated their behavior. Others deflect or generalize.

These questions don’t check “culture fit.” They expose the person’s internal rules of behavior.

2. Test how they reason through ambiguity

Mindset shows up most clearly when the path is unclear.

Give them a small, messy scenario:

“Imagine you join and on day one you realize the spec is incomplete, the designer is on vacation, and the backend isn’t ready. What do you do next?”

Then watch:
Do they freeze? Wait for permission? Identify constraints? Form quick hypotheses?

Ambiguity removes the script. What remains is how someone thinks when there are no instructions. It reveals agency, bias for action, and collaboration style.

3. Listen to how they talk about others

A person’s attitude is loudest when they describe people who frustrated them.

Ask:

“Tell me about someone at work who annoyed you. What was the situation, and how did you handle it?”

Strong candidates describe behaviors, not personalities. They show curiosity about why the other person acted that way. They take responsibility for their part in the tension.

Weaker candidates moralize, blame, or generalize. They see villains instead of systems.

4. Check how they frame learning

Mindset is a growth engine. You can hear it in how people talk about learning loops.

Ask:

• “What’s something you learned recently that excited you enough to dive deep?”

• “What’s the last skill you intentionally developed, and why?”

• “How do you decide what to learn next?”

You’ll quickly sense whether learning is intrinsic (driven by curiosity) or extrinsic (driven by checklists). The first kind scales faster, adapts better, and thrives under change.

5. Simulate a small conflict

Not drama — just tension.

Give feedback right in the interview:

“Your answer wasn’t structured. Can you walk through it again more cleanly?”

Then watch:
Do they get defensive?
Do they update fast?
Do they appreciate the clarity?
Or do they crumble?

That one moment can tell you more than any polished story from their past.

6. Ask value-revealing questions

A-players carry a coherent internal compass. They’ve thought deeply about what drives them.

Ask:

• “What matters to you in a team?”

• “What do you optimize for in your career?”

• “How do you decide whether you’re doing good work?”

You’re not looking for the “right” answer. You’re looking for reflection. Have they articulated what they stand for, or are they operating on autopilot?

Combine it with reference calls — the real truth serum

Reference calls aren’t a formality. They’re where the real signal lives.

Ask past managers:

• “If you were to hire them again, what conditions would they need to succeed?”

• “What situations make them shine, and which derail them?”

• “What’s the one thing you wish they did differently?”

Compare what you’ve heard from a candidate with a reference. Try to dive into the same situations and compare the notes.

When someone describes an A-player, the feedback is vivid and specific. When they describe a mediocre performer, it’s vague and overly positive.

The surprising truth

Assessing mindset isn’t a soft skill. It’s the most predictive part of hiring.

There’s no universal “right” mindset — only one that fits your company’s DNA, how you work, decide, and grow together.

Most companies get this part wrong. They run the HR interview at the very end, or worse, skip it altogether, assuming everyone who met the candidate can piece together a full picture. Nothing could be further from the truth.

All those previous interviews are snapshots — narrow glimpses of skill or experience. The mindset interview is the only one that captures the whole story.

That’s why it shouldn’t come last. It should come first. Because once you understand how someone thinks, you already know how they’ll perform.

How is this post different from other resources?

1. The LangChain GitHub repo and blog posts provide only high-level explanations of how things work.

2. LangSmith and LangGraph Studio don’t expose all the details—it’s difficult to capture the state at each step and the dynamic invocation of the graph. Therefore, it’s hard to understand the full picture at each step of execution.

3. A solid grasp of reflection agents, tool-use design patterns, and basic recursion is required to fully understand the process.

This is a long post by design, so brace yourself. We’ll start by aligning on the high-level design of Open Deep Research. We’ll then cover several design patterns used in the implementation that are crucial for understanding. Finally, we’ll take a step-by-step deep dive through an example to see how the Open Deep Research graph and state evolve at each step.

How It’s Designed

I assume you’ve read the official LangChain blog post that explains how Open Deep Research is built. However, to ensure we’re all on the same page, let’s have a quick look at the architecture.

The agent conceptually consists of three main parts: scoping, research, and final report. Any design variation you might want to build will likely contain these three components.

The goal of the scoping part is to build the input for the research phase. In Open Deep Research, this consists of a user clarification loop—the LLM determines whether it requires any clarification from the user or not—and then brief generation.

If you design your own agent, this is where you can perform user prompt optimizations or apply other techniques to improve the quality of user input.

When the brief is generated, it proceeds to the research phase. This is where the heavy work happens. We’ll go into much more detail later, but in a nutshell, it consists of two stages: supervisor and research sub-agents. The supervisor, given the brief and using reflection, spawns multiple research sub-agents on demand, each with a dedicated sub-task. Each sub-agent (sub-graph) receives a dedicated topic, performs research on it, and returns a summary to the supervisor. When the supervisor reflects on the results and decides that it has gathered enough data, everything moves to the Reporter part.

The Reporter takes all the collected information and generates the final result. If your result is too large, this is where you can generate an artifact (like in Claude) instead of text results.

Prior Knowledge

To understand how Open Deep Research really works, we need to discuss several patterns in isolation that are used throughout. It’s not the classic ReACT pattern that’s now standard.

Reflection Pattern

The reflection pattern enables agents to evaluate their own output and use that feedback to refine their responses iteratively. In this pattern, an LLM generates an initial response, then acts as its own critic to assess the quality of that output. Based on this self-critique, the agent produces an improved version, repeating this cycle until it meets quality standards or reaches a stopping condition. This self-correction loop allows agents to avoid getting stuck in purely reactive thinking patterns and move toward more deliberate, methodical problem-solving.

Tool Use Pattern

The Tool Use pattern is fundamental to understanding Open Deep Research’s architecture. While it might seem similar to standard tool calling, there are crucial differences that enable more sophisticated agent behaviors.

Standard Tool Calling (ReACT)

In classical ReACT architecture, tool calling is straightforward:

@tool
def search_web(query: str) -> str:
    “”“Search the web for information.”“”
    return tavily_search(query)

# LangGraph automatically:
# 1. Detects the tool call in LLM response
# 2. Executes the function
# 3. Adds result to message history
# 4. Continues to next LLM call

This works great for simple tools, but has limitations when dealing with complex operations.

The Manual Tool Use Pattern

Open Deep Research uses a different approach—manual tool orchestration. Here’s why and how:

Why is this needed?

1. Complex operations: When a “tool” is actually spawning an entire subgraph (like a research sub-agent), you need more control

2. Memory management: Tool results can be massive (e.g., full research reports). Adding everything to message history bloats the context window

3. Custom routing logic: You might need to handle tool execution differently based on business logic

4. Parallel execution: Spawning multiple sub-agents simultaneously requires manual coordination

How it works:

1. Define tool schemas without implementations:

class ConductResearch(BaseModel):
    “”“Tool definition for spawning a research sub-agent.”“”
    topic: str = Field(description=”The research topic to investigate”)
    
# Note: This is just a schema - no actual function implementation

2. Bind schemas to the LLM:

llm_with_tools = llm.bind_tools([ConductResearch, ThinkTool, ResearchComplete])

3. LLM returns structured tool calls: When the LLM decides to “use” a tool, it returns:

AIMessage(
    content=”I’ll research this topic now”,
    tool_calls=[
        {
            “name”: “ConductResearch”,
            “args”: {”topic”: “machine learning frameworks”},
            “id”: “call_abc123”
        }
    ]
)

4. You manually handle the tool execution:

# Check if LLM wants to call a tool
if message.tool_calls:
    for tool_call in message.tool_calls:
        if tool_call[”name”] == “ConductResearch”:
            # Spawn a research sub-agent (a whole subgraph!)
            result = await research_subgraph.ainvoke({
                “research_topic”: tool_call[”args”][”topic”]
            })
            
            # Return a compact confirmation, not the full result
            return ToolMessage(
                content=f”Research completed on {tool_call[’args’][’topic’]}”,
                tool_call_id=tool_call[”id”]
            )

Key Benefits in Open Deep Research:

• Subgraph invocation: The supervisor can spawn entire research sub-agents as “tools”

• Context efficiency: Instead of adding a 10,000-token research report to the message history, you return a simple “Research completed” message

• Flexible routing: You can route different tool calls to different subgraphs or handlers

• Parallel coordination: Spawn multiple research sub-agents simultaneously, each with isolated context

The Trade-off: You lose automatic tool execution but gain fine-grained control over when, how, and what gets executed. This control is essential for sophisticated multi-agent architectures like Open Deep Research, where “tools” are actually entire reasoning subgraphs with their own state management.

Deep Step-by-Step Guide

Now that we have all the necessary knowledge and a high-level understanding of how Open Deep Research is designed, it’s time for a deep dive.

The best way to describe it is to walk through an example step-by-step and see how the overall graph and state of the deep research agent change at each step.

Each step contains a corresponding image showing how the graph looks and the LangGraph state object (in green) at that step.

Step 1: User Question

It all starts with the user question. The LLM decides, using structured output, whether it requires any clarification from the user. If so, it returns the corresponding boolean value and a follow-up question that is sent to the user. The state at this stage is simple: an array of messages.

Step 2: User Responds to a Clarifying Question

When a user replies, Open Deep Research performs another call to the LLM with the array of messages. It might ask for clarification again or return structured output with:

{
  need_verification: false,
  verification: “Thank you…”
}

where need_verification indicates whether we should proceed to the brief writer or not.

response = await clarification_model.ainvoke([HumanMessage(content=prompt_content)])
if response.need_clarification:
    # End with clarifying question for user
    return Command(
        goto=END,
        update={”messages”: [AIMessage(content=response.question)]}
    )
else:
    # Proceed to research with verification message
    return Command(
        goto=”write_research_brief”,
        update={”messages”: [AIMessage(content=response.verification)]}
    )

Step 3: Generate the Brief and Pass to Supervisor

Now we make another call to the LLM with a different prompt to generate the research brief. The result we get back is stored in the state.

We also prepare the initial state for the supervisor subgraph. It’s stored in supervisor_messages inside the state and starts with the system prompt and the brief that was just generated.

Step 4: Supervisor Reflects on the Brief

Now the complex part begins. The supervisor has its own system prompt and three tool definitions: think_tool, conduct_research, and research_complete. It’s important to point out the pattern we described earlier—these are just definitions without actual implementations. The supervisor node listens to LLM calls and performs tool calls itself.

It starts with a call to the think_tool (reflection pattern) to understand what it should do, and the result is stored in supervisor_messages. The supervisor also checks the number of calls (research_iterations) it has made and stops if it exceeds the predefined maximum; otherwise, the research could continue indefinitely.

Step 5: Supervisor Initiates the Research

When the first reflection is recorded, the supervisor makes a call to the LLM, which returns a call to the conduct_research tool with the topic. It might return several conduct_research tools; in that case, the supervisor will spawn multiple sub-agents in parallel, each with a dedicated topic.

Step 6: Initiate Research Sub-Agent

The research sub-agent is a subgraph that is invoked dynamically based on the LLM response from the conduct_research tool; therefore, it’s not visible in LangGraph Studio. It consists of three main nodes: researcher, research_tools, and compress_research. Research tools can be configured but generally include think_tool with the same logic as the supervisor tool, search, MCP servers, and the research_complete tool. As a subgraph, it has its own state with messages and research_topic that it received from the supervisor. Similar to the supervisor, each tool call is tracked in the state and capped by the maximum number of iterations.

Step 7: Research Agent Initiates the Search

This step is straightforward. The research node makes an LLM call with the system prompt and the research topic it received from the supervisor. It receives back a tool call to web_search with an array of queries that it should perform.

Step 8: Research Agent Performs Multiple Searches

Open Deep Research uses Tavily search and spawns several searches in parallel, one for each query it received from the researcher node. Given that search results can be large, before the search tool returns the results, they are summarized and then stored in researchers_messages in the state.

Step 9: Reflect on Research Results

Similar to the supervisor, the research node invokes the think_tool to reflect on received search results and make a decision about whether the results are sufficient or whether to continue.

Step 10: Research Completed

If the result of the think_tool indicates that the research has sufficient information, the research node calls the research_complete tool and goes to the compress_research node. Since the result of the search can be large, we compress the results at this point and return them back to the supervisor.

Step 11: Re-evaluate Research Plan

When results from research sub-agents are received, it’s like finishing a tool call. We store the results in the state and specify to the LLM that conduct_research has finished. The supervisor, as per its system prompt, calls the think_tool to understand what to do next.

Step 12: Research Completed

At this stage, reflection indicates that the supervisor has gathered sufficient information for the research the user requested, and the research_complete tool is called to finish executing this subgraph.

Step 13: Generate Final Report

When all subgraphs are complete, the current state contains the message history, supervisor_messages, the brief, and the research results. The last step is to make a call to the LLM to generate the final report and return it to the user.

References

1. https://www.philschmid.de/agentic-pattern#reflection-pattern

2. https://www.philschmid.de/agentic-pattern#tool-use-pattern

3. https://blog.langchain.com/reflection-agents/

4. https://github.com/langchain-ai/open_deep_research

5. https://blog.langchain.com/open-deep-research/

Many employees want trust immediately, and many managers hope for it as well. However, when trust isn’t properly established, the usual outcome is work that doesn’t meet “the right, expected standards,” often resulting in micromanagement.

To achieve effective “fire and forget” management, a process needs to unfold. Here’s a step-by-step approach to building trust and alignment:

Step 1: I identify the problem and solution, instruct you on how to solve it, and check your execution.
This stage helps you understand company standards, learn expectations, and see how I approach problems as a manager.

Step 2: I define the problem and the solution, but you handle the implementation and execution. I review your progress.
The goal here is to align our thinking and approach to decisions. We essentially teach each other about our thought processes, decision-making, and trade-offs. This stage often lasts the longest.

Step 3: I outline the problem; you determine the solution, implementation, and, if necessary, delegate tasks to others. This is the true “fire and forget” stage.

Jumping straight to the third level without establishing trust and alignment can often lead to failure.

As an employee, I consistently use this model with my managers, whether I’m transitioning to a new role within the same company or joining a new organization.

Think of it as due diligence, but focused more on employees. This model is straightforward and requires no special financial or investor expertise.

If you're considering joining a startup as an employee, this approach will help you estimate its chances of success.

Understand Company’s Ideal Customer (ICP)

The ICP—Ideal Customer Profile—is the cornerstone of product development, sales, and marketing. It’s crucial to understand who the company is solving a problem for and how. Without this clarity, building a successful company is nearly impossible.

When interviewing with the company, the founders should be able to clearly describe the ICP. Additionally, anyone else interviewing you should describe the same persona consistently. This alignment among employees is a strong indicator that they understand the problem they’re solving.

A good ICP is specific and typically narrow, like "e-commerce business owners in the US with annual revenues up to $80M." If you hear something too broad or vague, consider it a red flag.

Assess the Problem’s Size

Evaluate the size of the problem the company is trying to solve. While many assess this by estimating the Total Addressable Market (TAM), which can require extensive research, a simpler approach involves considering:

1. The severity of the customer’s pain.

2. The frequency of this pain.

3. The number of customers who experience it.

You can also do a quick Google search to identify existing alternatives customers use to address the same pain. A good problem size is one that affects many people on a daily basis.

It’s important to differentiate between a real problem and a hype-driven one. Significant technological shifts can lead to the creation of many companies (think Blockchain or GenAI), but not all of them solve real problems.

Evaluate the Founders

Ask yourself: Are these founders the best people to tackle this problem, and why?

The answer usually involves two main factors: 1) Do they have deep knowledge and expertise in this space? 2) Have they successfully built a business before?

While it’s common to ask founders about their vision, I believe it’s not worth putting too much weight on it, as it’s likely to change over time. The founder's commitment to solving the problem and their resilience in the face of uncertainty are far more crucial.

Research the Investors

Strong investors indicate that the founders have effectively communicated the potential of the problem and its scale. These investors believe the problem is worth solving and that the founders are capable of doing so.

Identify the top-tier investors in the field and ask the founders who their investors are. Ideally, at least one of them should be on that list. The same applies to angel investors.

Top VC funds are pitched frequently, and if they choose to invest, they conduct thorough due diligence. You can trust their process.

If it’s an early-stage startup, consider asking to speak with their angel investor before making your decision. Ask about their perspective on the problem's size, why they chose to invest, and how they view the potential of the business.

Evaluate the Current Team

Finally, assess the team. The goal here is to determine if this is the right team to build the product for the ICP. Identify key players and evaluate their backgrounds. Ideally, they should have experience in the domain and with the problem they’re solving.

Using this framework, you can assess different startups across various stages and industries.

Bonus: If you’ve read this far, you’re likely very interested. If you want to evaluate a specific offer you have, feel free to DM me, and we can go over it together.

The Simplistic Solution

The most straightforward solution in this scenario is to utilize a library that effectively removes unwanted characters from the input. The npm package known as String-sanitizer is adept at performing this task.

onst { sanitize } = require("string-sanitizer");

const names = [
  " John,Smith ",
  "🌯John,Smith",
  "John,Smith ✔️",
  "John,Smith  🇺🇦"
];

names
  .map(name => name.split(',')) // split because sanitize removes ','
  .map(([firstName, lastName]) => ([sanitize(firstName), sanitize(lastName)]))
  .map(parts => parts.join(','));

// ["John,Smith", "John,Smith", "John,Smith", "John,Smith"]

Initially, this solution may appear effective until one encounters less predictable instances of names.

Dealing with Unpredictable Input

It is important to note that LinkedIn users often get creative with their naming conventions. The following examples illustrate how this variation can disrupt the efficiency of the code.

const { sanitize } = require("string-sanitizer");

const names = [
  "John (Johnny),Smith",
  "Joghn,\"Smith, CPA\"",
  "John,Smith-Perry",
  "John,Smith Jr.",
  "John,\"Smith, Ph.D\"",
  "John,Smith ✰ I'm Hiring ✰",
];

names
  .map(name => name.split(','))
  .map(([firstName, lastName]) => ([sanitize(firstName), sanitize(lastName)]))
  .map(parts => parts.join(','))

// ["JohnJohnny,Smith", "Joghn,Smith", "John,SmithPerry", "John,SmithJr", "John,Smith", "John,SmithImHiring"]

One might attempt to address each of these instances by crafting complex regex. However, this approach presents two major challenges:

1. It's plausible that there will always be a use case where the code will return an incorrect result.

2. The maintenance cost of the code, which includes testing and improving, is quite high. For each new use case encountered, the function must be altered to accommodate it.

Probabilistic Approach

For this use case, probabilistic models can yield significantly superior results than any possible code written by developers.

An example of this is using the OpenAI API with a simple prompt to return the person’s name. This method excels in more complex use cases, such as "I am hiring". However, it may overlook various suffixes.

OpenAI provides a mechanism to refine results according to specific needs via fine-tuning the model.

Fine-tuning the model has three key advantages:

1. The model is trained based on specific data, which yields more precise results.

2. It is cost-effective due to the use of a pre-trained model, necessitating a smaller system prompt.

3. The process is expedited.

Although it may seem excessive to employ machine learning for a seemingly simple task, this task is not as simple as it appears. Solutions like OpenAI offer fine-tuning capabilities that are easy to implement, providing superior results in less time than traditional coding approaches.

Fine-Tuning the Model

Here's how we can prepare a fine-tuned model in three steps:

1. Prepare training and validation datasets.

2. Train the model.

3. Implement the pre-trained model in the code.

Training a model, in simplest terms, involves supplying the OpenAI model with a file containing examples that include user input and the correct answer that the model should return.

OpenAI recommends providing 10-100 such examples.

The training file in .jsonl format might look like this:

{"messages": [{"role": "system", "content": "A given phrase contains a name. Your task is to extract it."}, {"role": "user", "content": "Smith 🇮🇱"}, {"role": "assistant", "content": "Smith"}]}
{"messages": [{"role": "system", "content": "A given phrase contains a name. Your task is to extract it."}, {"role": "user", "content": "John גיון סמיט"}, {"role": "assistant", "content": "John"}]}
{"messages": [{"role": "system", "content": "A given phrase contains a name. Your task is to extract it."}, {"role": "user", "content": "John-Perry"}, {"role": "assistant", "content": "John-Perry"}]}
{"messages": [{"role": "system", "content": "A given phrase contains a name. Your task is to extract it."}, {"role": "user", "content": "John Smith"}, {"role": "assistant", "content": "John Smith"}]}

Each line is a separate example. It contains a system prompt (what you want the model to do), user input, and assistant output (the correct answer that the model should provide).

Upon preparing this file, it can be uploaded to OpenAI's fine-tuning UI to pre-train the model. If your data preparation process is more complex, the OpenAI SDK can also be used for fine-tuning models.

The training duration will depend on the number of examples provided. Once complete, the model can be integrated into your code.

import { get } from 'lodash';

async sanitizeName(someName: string) {
    const res = await openai.chat.completions.create({
      model: 'ft:gpt-3.5-turbo-0613:personal::some-weird-code', // fine-tuned model
      temperature: 0.0,
      top_p: 1,
      frequency_penalty: 0,
      presence_penalty: 0,
      messages: [
        { role: 'system', content: systemPrompt },
        { role: 'user', content: someName },
      ],
    });

    const answer: string = get(res, 'choices[0].message.content');
    return answer;
  }

Evaluating the Cost

Finally, let us consider the cost. If you choose to use OpenAI, there may be costs involved, but this should not be a deterrent.

Instead, it would be beneficial to assess the efficiency perspective. This approach considers how much time you have expended to achieve the most optimal results.

The Simplistic Approach

The efficiency of the simplistic approach is rather low. For instance, you might spend approximately four hours writing and testing a function that covers all known cases. The challenge with this approach is the inability to predict all possible scenarios, resulting in a high likelihood of errors.

Fine-Tuning Approach

The cost of the fine-tuning approach consists of three components:

Your time to prepare training data + Cost to train the model + Cost to use it.

Although preparing the training data is the most time-consuming part, it would likely take less than half the time spent writing code using the simplistic approach.

Fine-tuning the model with OpenAI is a cost-effective solution. For instance, it took about 15 minutes to train a model with 151 examples at a cost of $0.13.

The final component is the cost of usage, which is also not substantial.

However, the fundamental question is whether the benefits outweigh the costs. Can you truly obtain better results for unpredictable input?

Consider this: the fine-tune approach works not only with known scenarios but also with names that include mixed languages or are entirely in different languages.

I started to cultivate the feeling of what's THE right way to build the product and deliver value to customers consistently and sustainably. Those two criteria are important and have a significant impact on how to build a product.

I couldn't verbalize it myself but Itamar Gilad did and he did it very well - Stop Obsessing Over Development Velocity, Focus on This Instead.

The ideal architecture has a low cognitive load, is easy to maintain, scalable with the application's growth, and is customizable to accommodate the imagination of any UX designer. Unfortunately, such I couldn’t find a framework that meets all those needs, and, no, I am not on a mission to build one.

However, we do have many tools at our disposal. Can't we simply wire them all together? The short answer is no.

If you choose to wire different libraries yourself, various problems arise, such as overlapping functionality and different assumptions in their usage. It is frustrating to piece together different libraries in the React ecosystem.

Fortunately, I believe we have found a sane architecture that we are happy with.

Before we dive into the details, let's establish our requirements:

1. Clear Separation of Concerns Without Side Effects: As developers, we crave clarity, a map that shows us exactly where to lay down our code.

2. Scalability: Our architectural design should gracefully expand as our application grows, whether it's composed of 2 or 142 components.

3. Testability: Each layer should be testable in isolation, allowing for easy swaps if needed.

4. Simplicity: Our architecture should possess a low cognitive load, drawing from familiar concepts. This simplicity should make learning, maintenance, and modifications a breeze.

Implementation Blueprint

1. Project build foundation

The popular create-react-app is deprecated. Other recommended tools like Next.js or Remix have many assumptions and conventions that are imposed on developers. While following the recommended flow with these tools can make the development process a pure joy, it requires a strong commitment that we don't want to make from the beginning.

Instead, we have chosen Vite with the React TypeScript template. Vite is a fast, non-opinionated build library that provides the necessary structure for our application without imposing any strict conventions. It is also much easier to configure compared to Webpack, and can be easily extended if necessary.

2. Routing

Since we don't follow the conventions, we will handle the routing ourselves. In the React ecosystem, there is only one library for that - React Router. Specifically, we will use react-router-dom v6.

However, we will not be using loader functions and actions as recommended. They impose more limitations on client-side applications - you cannot use react hooks inside the loader function, they control the flow of fetch and render with function calls and the <Suspense /> component, among other things.

Using these functions makes more sense if you are using Remix, the full-stack framework written by the same authors as React Router. It is very powerful in that context.

3. Authentication

Auth0 is a popular user management tool with a great developer experience library for React. It simplifies login configuration, user management, and more.

Auth0 also offers a powerful binding of their JavaScript library for React with the use of hooks.

To start, we need to configure the Auth0 provider, which is a straightforward process.

When we want certain routes to be accessible only for logged-in users, Auth0 provides a useful higher-order component. We can wrap it in a Protected component and use it later in the router configuration as follows:

const router = createBrowserRouter([
  {
    path: '/',
    element: <Root />,
    children: [
      {
        index: true,
        element: <Main />,
      },
      {
        path: 'protected',
        children: [
          {
            index: true,
            element: <Protected component={Internal} />,
          },
        ],
      },
    ],
  },
]);

The Protected component is very simple too:

import { withAuthenticationRequired } from '@auth0/auth0-react';

export const Protected = ({
  component,
  ...args
}: {
  component: React.ComponentType;
}) => {
  const Component = withAuthenticationRequired(component, args);
  return <Component />;
};

When navigating to a specific route, auth0 checks if the user is logged in before rendering the component. If the user is not logged in, auth0 performs a full page redirect to the auth0 configuration page.

Auth0 is also used to handle the last concern, which is obtaining an access token for the logged in user. We can use this access token in the Authorization header when making API calls to our server.

Once the user is logged in, we extract the access token and store it for future use.

4. State management

When your application grows, you will eventually need a way to manage fetched data from a server and the application state.

There are many tools available for this purpose.

We have chosen Zustand, a small and simple library based on Flux concepts. I won't go into much detail comparing it to other libraries, as there is a dedicated page for that here.

I would like to specify the factors that were important to us in making this choice:

• Small API surface: Zustand essentially has only two concepts - store and actions. This means there is not much boilerplate code that developers have to write, such as wiring actions or reducers.

• Simplicity: It provides a hook and actions that mutate the initial state. That's it. There are no extra magical features like in Mobx.

• The store is a React hook and can also be accessed as a plain JavaScript object if needed.

• Easy scalability: As your application grows, you can split the store into separate slices with dedicated actions.

5. API calls

The final layer of our client-side architecture is the API. This is where we make calls to our server. The API layer interacts exclusively with the store (a vanilla object) and its actions. It is important to avoid any direct calls from components to maintain a clear separation between boundaries.

The API layer should also be stateless and focus on providing minimal logical data manipulation. Data management should be handled by the data management layer.

For making API calls, we create an Axios instance with an interceptor that takes an access token and adds it to every request sent to the server.

import axios from 'axios';
import { useStore } from '../store';

const axiosInstance = axios.create({
  baseURL: `${import.meta.env.VITE_SERVER_URL}/api`,
});

axiosInstance.interceptors.request.use(
  async (config) => {
    const token = useStore.getState().me.token;
    config.headers['Authorization'] = `Bearer ${token}`;
    return config;
  },
  (error) => {
    return Promise.reject(error);
  },
);

export default axiosInstance;

Conclusion

So, what have we achieved? We have created a layered client-side architecture for a scalable project with clear boundaries. Each layer is separately testable.

To get started, you can create a new GitHub repository using the sane-front-end-project-template. It already includes all the mentioned components wired together.

AI's Influence and the Unchanged Essence of Software Engineering

The AI wave is indeed changing the game with tools like GitHub's Co-pilot. These tools boost our efficiency and save a ton of time and money. And there's cool stuff on the horizon, like self-healing code, that'll make our software better and quicker to produce. It's an exciting time, no doubt.

My Recent Experience: A Peek into Our World

I recently took on a project from scratch to finish, and it got me thinking. I compiled a list of technologies that we, as software engineers, need to be familiar with to create a simple app.

Here's a snippet:

1. Creating the look (HTML)

2. Adding style (CSS)

3. Making it work (JavaScript)

4. Handling browsers (Browser stuff)

5. Navigating within the app (Routing)

6. Managing data flow (State management)

7. Designing the interface (UI libraries)

8. Linking with other apps and services (APIs)

9. Speeding things up (Caching)

10. Picking a backend language (Python, JavaScript, etc.)

11. Building the backend (Server framework)

12. Juggling tasks (Async programming)

13. Ensuring security (Security basics)

14. User access (User authentication)

15. Storing data (Database)

16. Team coordination (Version control)

17. Packaging the app (Docker)

18. Getting it out there (Deployment)

19. Checking it works (Testing)

20. Speeding up delivery for end users (CDN)

21. Handling addresses (DNS and networking)

22. Utilizing the cloud (Cloud architecture)

23. Domain management

24. Sending emails (Email service setup, reputation and warm-up)

25. Respecting privacy (Privacy concerns)

26. Monitoring performance (Monitoring)

It's a hefty list, right? Sure, AI tools like ChatGPT can help with some. Today's tools let us do more with a smaller team than before.

The Real Value We Bring

Here's the scoop: being a software engineer isn't just about knowing tools. It's about fitting these tools together seamlessly. It's like cooking up a dish with various ingredients. As we improve at this, we innovate fresh ways to solve issues.

A Bright Future Ahead

The idea that AI will replace us isn't the full picture. In the next 10 to 15 years, we'll still be here, doing our thing. Instead of fading away, we'll focus more on tackling tough challenges in smarter ways. As technology advances, so will our skills to make great things happen.

In a nutshell, the AI storm won't wipe us out. While AI tools are handy, the blend of skills, creativity, and problem-solving we possess is hard to replicate. So, brace yourselves – the future of software engineering is a thrilling ride!

Embracing Change: Code Implementation vs. Essence

To understand the potential influence of AI on software engineering, it's essential to distinguish between code implementation and its essence. While code implementation refers to the specific technical details and tools used to build software, the essence encompasses the broader concepts and architectural decisions behind it.

For example, a message queue is an essence to support async communication between different services. Kafka including the usage of its API is the implementation detail. Due to different technical reasons, it’s possible to substitute Kafka with RabbitMQ. The implementation will change but the essence of message queue has remained.

AI's Growing Role in Code Implementation

AI has already started making its mark on code implementation. Tools like GitHub's Co-Pilot have demonstrated the ability to generate code snippets and assist developers in writing code more efficiently. As AI becomes increasingly proficient at writing code, developers may find themselves relying more on these AI-powered tools to handle implementation details.

Shifting Focus to the Essence

As AI takes over some aspects of code implementation, software engineers can redirect their focus towards the essence of software development. This entails delving into software architecture, designing bigger building blocks, and making critical decisions regarding the overall structure of the software. Instead of spending significant time on writing lines of code, developers will have the opportunity to engage in more strategic and creative thinking.

The Continued Need for Computer Science Knowledge

While AI may automate certain coding tasks, the fundamental knowledge of computer science remains crucial for software engineers. Understanding concepts such as complexity, DB schemas and their design, and security risks will continue to be essential. However, developers may no longer need to implement low-level algorithms from scratch, as AI can assist in generating optimized solutions. It is worth noting that many developers already rely on existing resources like Wikipedia and Stack Overflow for code snippets.

The Impact of AI on Software Engineering

The impact of AI on software engineering is expected to follow the path of abstraction. Much like the progression from Assembly language to high-level programming languages like Python, AI's role will elevate abstraction in the development process. Software engineers will still be in demand, but their responsibilities will shift towards higher-level tasks that leverage AI-generated code. This transition will enable developers to focus on designing sophisticated systems, ensuring robust software architecture, and effectively utilizing AI tools to enhance productivity.

Conclusion

As we contemplate the future of software engineering in the era of AI, one thing is clear: software engineers will continue to play a vital role in the industry. While AI may take over certain aspects of code implementation, the essence of software development and the need for strategic decision-making will remain essential. Software engineers must adapt to these changes by embracing AI-powered tools and leveraging their expertise to contribute to higher-level tasks. The future of software engineering holds exciting possibilities, and it's up to us to navigate this evolving landscape with enthusiasm and adaptability.

The Pitfalls of the Outside-In Approach

1. Starting from the blank canvas every time: In reality, software development rarely involves starting from scratch. Instead, we build upon existing architectures with the goal of enhancing and improving them. When architects and decision-makers attempt to invent the future architecture without sufficient familiarity with the current codebase, their assumptions may be inaccurate or flawed. This lack of context can lead to suboptimal design decisions that hinder the development process.

2. Communication Gaps: Effective communication between decision-makers and engineers is vital for successful architecture implementation. However, when architects pass down architecture requirements through documentation or verbal means, information can be lost or misinterpreted along the way. This breakdown in communication can result in a misalignment between the envisioned architecture and its actual implementation.

3. Lack of Feedback Loop: One significant drawback of the outside-in approach is the absence of a proper feedback loop. Architects, team leads, and other stakeholders often lack a non-intrusive method to validate and review the implemented architecture. As a result, mistakes and issues may only be identified late in the development cycle, leading to costly and time-consuming rework.

Redefining the Architecture Design Process

• Generating High-Level Architecture from Code: To overcome the limitations of the outside-in approach, one alternative is to generate the architecture directly from the codebase. The code itself represents the ultimate source of truth, providing insights into the existing structure, dependencies, and patterns. By analyzing the codebase automatically, engineers can gain a deeper understanding of the architecture and make informed decisions for further enhancements. Some tools are getting close to doing so. For example, architecture-view-nestjs VS code extension generates 2 levels of architecture for NestJs applications.

• Leveraging AI for Architecture Generation: Then, we can enhance the deduced architecture by leveraging artificial intelligence (AI). With the wealth of existing architectural patterns and best practices, training AI models like GPT on this knowledge can enable them to generate new and innovative architectural solutions. By tapping into AI's capabilities, architects can benefit from an augmented design process, expanding the scope of possibilities and ensuring comprehensive exploration of potential architectures.

• Real-Time Architecture Updates: To facilitate better collaboration and feedback, it is essential to establish a near real-time architecture view. This view would enable architects, team leads, and stakeholders to monitor the progress of architecture implementation throughout the development process. By having a clear and up-to-date understanding of the evolving architecture, early detection of implementation issues becomes possible, allowing for timely intervention and course correction.

Conclusion

The standard outside-in approach to architecture discussions often falls short due to its detachment from the existing codebase, communication gaps, and the lack of a feedback loop. By embracing alternative strategies, such as deducing architecture from code, leveraging AI for generating architectural solutions, and establishing real-time architecture updates, we can revolutionize the architecture design process. These new approaches encourage a more holistic understanding of the system, enable better collaboration between decision-makers and implementers, and empower teams to detect and rectify issues early on. Ultimately, by reimagining how we approach architecture discussions, we can unlock the potential for more robust, efficient, and successful software systems.

Why understand software architecture as soon as you can?

1. Communication: Software architecture communicates the software system's design and structure to stakeholders, ensuring better collaboration and reducing the chances of misunderstandings.

2. Quality and Performance: Understanding software architecture is essential for ensuring the quality and performance of software systems by identifying potential issues and bottlenecks.

3. Planning and Design: Understanding software architecture helps to plan and design software systems, ensuring they are scalable and adaptable.

We don’t see it the same way

Having different levels of experience, knowledge, and seniority can lead to problems in software architecture as it can cause misunderstandings and communication issues between team members. For instance, those with less experience may not be able to understand the technical details provided by experienced team members, leading to confusion and misinterpretation of the software design. Similarly, senior team members may not be able to effectively communicate the impact of architectural decisions on the organization's goals to junior team members, leading to a lack of alignment and direction.

Visualize product architecture in real-time

Having a tool that visualizes product architecture in almost real-time, where everyone sees the same picture, can produce a significant impact on software quality and improve communication

Let's take the popular open-source project Tooljet as an example.

It's immediately obvious how complex the Tooljet project is. Analyzing its code and understanding its architecture can take several hours. However, you can use a VSCode extension that visualizes everything at once with the necessary level of abstraction. Seeing the high-level picture allows you to spot potential problems well before they become significant.

Credit: Visualized by Architecture View NestJS

What does it improve?

1. When entering a new or legacy code base, visualizing the product architecture can help you understand the system's structure quickly, making it easier to navigate and locate relevant code sections.

2. When onboarding new employees, visualizing the product architecture can help them get up to speed with the system's design and structure, ensuring they are better equipped to contribute to the project.

3. Keeping up with changes in the system can be challenging, but visualizing the product architecture can help you identify the potential impacts of any changes, ensuring you can make informed decisions and minimize the risk of introducing new issues.

Visualizing the architecture and how code changes impact overall architecture can easily allow you to become another “go-to” person for the team.

Successful candidates surprisingly share the same “trait”: the beginning of each of their careers was incredibly similar to one another.

I do believe that there shouldn’t be much freedom when you are just starting because tackling the right problems will define your path.

Stage 0: Learning to write code

All of us learn how to write code as the first step. We start with something relatively simple, like functions, scripts, classes, etc. Choosing a specific language doesn’t matter much at this point, since you will most likely learn many others along the way.

Stage 1: Learning to write production-grade code

You landed your first job. Congratulations!

Your main goal now is to learn how to transform your “writing code” abilities to “writing code for real users (production)”. This requires a lot more than just committing a code to a version control system. The list might vary between different companies, but in a nutshell, you should learn the following:

1. Code readability - how to write code for others to read

2. Teamwork - how to work in a team of other developers and QA

   1. Code reviews

   2. Pull requests

   3. Development tasks/tickets/issues

3. Tests - how to write testable code and learn different types of tests

4. Deployments - how your code is deployed to production

5. Monitoring - how to monitor your code in production and make sure it works as intended

6. Coping with production problems (urgents) - how to handle problems in production that happen to real users

Countless books have been written on each of the topics above. While we won’t dive into them here, you must invest some time into learning more about all of them. This is the foundation to become a successful software engineer.

Stage 2: Learn how to build simple architecture

When you feel comfortable delivering code to production, we can go up a level: learning to design software architecture solutions. The best way to accomplish this is to start small and ask your team leader to give you less defined tasks. This creates an opportunity for you to brainstorm the potential solution, design it, discuss it with senior peers, receive feedback, and finally, to implement it. The emphasis at this stage is on suggesting solutions and receiving feedback.

Stage 3: Learn to design subsystems or their parts

This stage is a logical continuation of the previous one: we are moving from features to designing important parts of the system. This requires a deep understanding of the whole picture (system) and how the part in question, the one you are working on, fits into it.

The course of action is similar to the previous stage, in that you will provide solutions and receive feedback. However, now the scope of the project has grown. You should consider the overall architecture of the part, its API communication with other parts of the system, using industry standards solutions, different design patterns, etc.

Stage 4: Build service from zero to production

There’s no substitute for the experience of building a service from the ground up and delivering it to production. This is a rare opportunity, especially in well-established engineering companies. Thus, whenever you have the chance, be sure to jump on it!

What should you expect here? Ouch…. quite a lot.

• You should learn to evaluate different approaches to solve the problem you have, taking into account their advantages, disadvantages, and cost of implementation.

• You should also experience how to deploy a new service to production.

• If, in all previous cases, you could remain in one domain, e.g., front-end or back-end, at this stage, you should be able to cross them and start writing code in both of them, including DevOps for the deployment part.

• You have a chance to define and/or adopt coding standards for your project.

• Last but not least, you’ll need to understand how to monitor the behavior of the service in production and the load, as well as what metrics and KPIs to look at.

Stage 5: Build a product

Whether you are in a startup or your well-established company is discovering a new possibility, you should participate in building a product. You may be wondering, “How is it different from stage 1?”

We are always contributing code to some product. At this stage, you must shift your concentration from writing a good code to building a good product.

To achieve that, what do you pay attention to here?

You work with the product team is mainly where you will direct your energy. Why are you working on this or that feature? What customer problem does it solve? Have you considered all feasible edge cases? How will a certain feature perform under load?

Those are just a few among the many questions engineers should ask product people and themselves, too.

This is the step where engineering and business value finally interact.

Stage 6: From here to infinity

The easy part is now over. This journey usually takes around 3-5 years. This is when the ‘hard’ part begins. Nobody can tell you what your goals should be but you. You will have to decide for yourself whether you want to try the management path or go deeper into engineering craftsmanship.

Whatever you decide, the stage that starts here has no end.

Here I want to offer an alternative approach to evaluating experience and provide some practical questions that you can use to aid your understanding of what experience truly is.

Part 1. The definition.

Let’s start by looking at the definition. According to Merriam-Webster, the experience can be defined as:

a: direct observation of or participation in events as a basis of knowledge

b: the fact or state of having been affected by or gained knowledge through direct observation or participation

Simply, experience is gained from direct observation and/or participation. Therefore, the more we encounter different types of problems and their solutions, the more our experience grows.

Part 2. Real-life.

But what happens in real life? Most of the actions in our daily jobs are so abstract that we just repeat them over and over again. They are usually simplistic tasks, for example, workers at an assembly line, each one doing one part of an overall product but not able to act on the bigger picture. By dividing work into repetitive tasks, the overall business is efficient, but it may hinder attempts to gain broader experience.

What is true for those on industrial assembly lines is true for many software engineers. We are surrounded by infrastructure, libraries, and frameworks that assist us in carrying out complex tasks. This allows us to produce code quickly, and all we are left to do is technical design and its implementation.

Solving new problems and implementing innovative features can be extremely rewarding and stimulate our intellect. Encountering and dealing with the same time of problems can also create a depth of understanding and expertise. However, there is a threshold, that when crossed, means that repeated tasks become mind-numbing and fail to stimulate our creativity. At these times, we need to switch to new challenges. The problem is that many of us are stuck at that repetitive point and count this as additional experience. So while experience measured in time may be growing, experience measured in intellectual growth may have stalled.

Part 3. The valid alternative.

True experience comes from solving different types of problems in a variety of ways.

For example in a set of two candidates, from one perspective you could say that one who has worked for five years has more experience than the other who has worked for three years. However, if we assessed them more qualitatively, we might find that the candidate who has worked for three years has been exposed in that time to a wider diversity of problems.

This is the reason why software engineers who join startups in the early stages are more likely to gain significantly more familiarity with diverse areas while perhaps compromising on knowledge depth as a result.

Part 4. The practical way

I believe it’s fair to say that every position has a finite set of types of problems that one can encounter. For example, one way, but certainly not the only one, to categorize the problems of software engineering would be in the following way, in order of complexity:

1. Investigating and solving a bug

2. Implementing a feature within given specifications

3. Designing and implementing a feature according to a product specification

4. Architecting the solution across different boundaries (e.g. front-end, back-end, devops)

Thus, if we were evaluating experience in terms of diversity of experience rather than simply quantity of time, we might wish to understand the level of complexity a potential employee has been exposed to. This can be achieved by probing candidates more about the nature of their work experience. From my own experience, I have found that the majority of full-stack developers have experience working with the first and second categories above, while the best candidates have experience in three or more of the categories. I also make sure to ask candidates a more subjective question, asking them to tell me what the most challenging problem they had to face in their career was or the problem-solving process that they are the most proud of. The answers to this question are a good indicator of the edge of a candidate’s experience and in ideal situations, their answers would fall in the third of the fourth category of problem-solving.

Part 5. Conclusion

If you are looking to optimize your professional growth, then seeking out work environments with fast-growth rates can help give you the space to gain a wider diversity of experience. Such places, for example, a startup that grows from hundreds to thousands of users within a short timeframe, is likely to experience many new and complex constraints and problems to solve. Thus, within these environments, you’ll be able to gain not just quantity of experience, but a true depth and range of experience too, which will make you a valuable asset for any company.

These days startups are ubiquitous but most of us are unfamiliar with its growth stages. Performing a role that doesn't correspond to a particular stage leads to a lot of friction in the process and disappointment.

This article greatly explains the stages of company growth, what kind of people are necessary for each stage, and when it's worth for you to join.

https://theskip.substack.com/p/stage-of-company-not-name-of-company

Let's say you have 5 years of experience as a software engineer and you come to an interview for a senior position. To your surprise, you don't get the job because you lack experience as you were told. How come?

Honestly, professional experience has very little to do with the number of years you've been in business. Instead, it's the variety of experience you gain on the way.

I've interviewed over 100 people within just 2 years, and it's easy to spot candidates who planned their careers early on.

So what do successful candidates do differently?

1. Choose the right company over a title

Let's face it, landing your first job is hard. No pressure, but it also plays a significant role in your future career.

Usually, at that point, the main choice is between a small startup (maybe with a fancy title) or a big established company. I don't think that choosing your company by size is right.

Here are 3 signs the company is a good fit:

• They are willing to invest in your professional growth;

• They are a team of smart people who you will interact with daily;

• They hold you accountable for your actions

Let's dig a little deeper into each of the above.

Investment in your professional growth

In a nutshell, it means the company has practices in place that contribute to the professional growth of employees. These practices don't have to be formal, such as courses or lectures. Simple things work well too: regular code review, involving junior engineers into design and architecture reviews. All these indicate a good engineering culture that aims to grow engineers and not only ship features or fix bugs.

Great people

A good team leader builds a team of engineers of different levels. A balanced team has a spectrum of engineers, e.g. 1 junior, 2 mid, and 2 senior engineers for a team of five.

Why should you care about it?

With experienced colleagues you get to read clean code and understand the logic behind these lines. It's like learning to cook by looking at our meal - you can guess some parts but it doesn't mean you can cook it.

Daily interactions with senior colleagues will teach you to analyze different approaches, reason about them, and make the right technical decisions. It's a skill that usually takes years to develop. Having experienced colleagues around you can significantly shorten this learning time.

Holding you accountable

We act differently when we know that our ass is on the line. On the one hand, such situations put you under pressure and intuitively we want to avoid them.

On the other hand, such situations allow tremendous growth because they force you to operate outside of your comfort zone. Good companies know that and nurture the culture of accountability (usually also backed up with the safety nets).

2. Become an expert in your domain

Software engineering has many specialties: front-end, back-end, DevOps, databases, and many others. Many companies are hiring a full-stack though - what should you do?

Young engineers face this dilemma quite often - should I know a little front-end, back-end, and one type of database, or focus on just one area, say, front-end?

As you might guess from the title, I believe it's better to be an expert in at least one area than being a surface learner. Every product has a period of weird behavior before the stack is mature enough. For example, NodeJS server fails, say, once every 3 days, your database gets random timeouts on connections, or your modal dialog keeps getting stuck. Fixing inconsistent behavior requires a solid understanding of underlying technology and experience to have a hunch where to look for.

When such moments come, experts are in the limelight and save the day. This is why established companies are interested in hiring more experts rather than generalists.

3. Ship a product

That feeling when you see customers using the product that you've built is extraordinary. It's also a great responsibility and requires you to be more than just a coder.

To feel this, you need to master the disciplines you’re not necessarily an expert in. These often include understanding product value, task prioritization, engineering, UX, QA, customer support, and feedback, you name it.

Having a proven record of a shipped product demonstrates your ability to get shit done and serves as a strong indicator of your abilities to the hiring manager.

4. Don't do more of the same

Your true experience comes from the types of problems you solve. You can have 7 years of experience, but it’s not so relevant if you solve the same problem over and over again, e.g. building the same type of application or the same type of website (landing pages). You’ll get exceptional at these, but it will be hard for you to change the job. Most likely your next position will be almost the same but in a different company. Why? Because you have 7 years of experience solving the same type of problem and you are damn good at that.

As an alternative, you can have just 3 years of experience, but these 3 years are a rollercoaster - you get to build an application, set testing infrastructure, improve monitoring, then build a different type of application, and so on. Combining your domain expertise with a handful of problems you solve on the way gives you the true experience.

You might notice, I didn't mention the number of years of experience at all. You may meet a person with 2-3 or even 4 years of experience and be amazed by their achievements. Most likely, these 2-3-4 years have been very rich with all sorts of engineering problems, solving which this person grew to be this outstanding professional you want to be.

Stick for a while but leave early if it’s not a good fit

It all takes time. Understanding the culture, learning architecture, building your reputation - it doesn't happen overnight.

Depending on the size of the company, this time might vary. As a rule of thumb, for the mid-size company, it takes about 3-6 months to onboard an employee and up to a year for a new employee to bring some meaningful results.

Sometimes, a person switches jobs every year or two. If this is you - it’s okay, but be ready to give a good reason why this happened.

Sometimes, it just doesn't feel right. Try to understand what's wrong and try to work it out. Try to be objective and see the full picture. There's a very good chance things will improve.

Sometimes, things don’t work out. And that's okay too. Accept it and move on. No point in staying to collect "the years of experience".

Still have any doubts about career choice? Email me. Seriously, I mean it. We can schedule a call and discuss it further.