DEV Community: henry

The follow up email is short, specific, and sent the same day

henry — Thu, 22 Oct 2026 14:09:06 +0000

The follow up email is short, specific, and sent the same day
Most advice about this is either far too long or tells you not to bother. Here is what I send, when I send it, and what to do about the silence that follows.

Written after over thinking a four sentence email for an hour. Updated October 2026. 6 min read

Company norms vary. The timing below is a reasonable default rather than a rule.

I spent an hour on four sentences
And nearly did not send them.

My first thank you email went through about six drafts. The version I sent was four sentences long, took forty seconds to write once I stopped editing, and got a reply within the hour mentioning a detail I had raised.

I have no idea whether it changed the outcome. What I do know is that the hour of agonising added nothing to the email.

The email is not an argument for hiring you. It is a short, human acknowledgement of someone making time for you.
The four sentences
Same day, before you forget the detail.

1
Thanks
One line. Name the
person, name the
day.
2
One detail
Something specific
from the
conversation.
3
One line of interest
Why the role still
appeals, briefly.
4
An open door
Happy to answer
anything further.
Four lines. Anything longer starts to read as a pitch.
The specific detail is the part that matters. It proves the message was written after the conversation rather than before it, and it quietly reminds them which candidate you were.

What not to include
All of these have been suggested to me and all of them are worse.

Works
Four short sentences
One concrete detail
Sent within a few hours
Plain subject line
Backfires
A summary of your qualifications
Attaching extra work nobody asked for
Correcting an answer at length
Anything that mentions how badly you want it
The correction one deserves a caveat. If you got something factually wrong and the fix is one sentence, including it is fine and occasionally impressive. Three paragraphs relitigating a design decision is not.

The waiting part
Which is harder than the writing.

Ask for a timeline
At the end of the interview, so you are not guessing later.
Wait the stated time
Then a day or two more, then check in.
One polite check in
Two sentences. Still interested, any update, no pressure.
One final message
A week later. Then stop and keep applying.
What silence usually means
Rarely what it feels like.

Silence after an interview is almost always internal. A panel member is on leave, the role is being re-scoped, another candidate is mid process, or someone simply forgot. It occasionally means a no that nobody has written up yet. It very rarely means anything about you personally, even though it feels extremely personal when it is your week.

The practical response is to assume nothing, send your two messages on schedule, and keep other processes moving so that this one is not carrying all your hope.

After a rejection
One short reply, which costs nothing.

Thank them, say you enjoyed the conversation, and ask whether there is anything specific you could improve. Many companies will decline to say. The ones who answer usually give you one precise sentence, and that sentence is worth more than a week of guessing.

When the feedback named a round rather than a quality, which it usually did for me, that was the thing to go and drill. I used Phantom Code AI[https://www.phantomcodeai.com/]
for that, since rotating between coding, system design, SQL and behavioral practice in one place made it easy to spend a fortnight on whichever round the feedback pointed at rather than starting a whole new routine.

Common questions
Short answers.

Should I send a thank you email?
How long before following up?
What if there is no reply?
Should I ask for feedback after a no?
Short, specific, and then let it go
The follow up is one of the few parts of a job search you fully control, which is exactly why people overwork it. Four sentences, one detail, and then your attention belongs to the next application.

Write your template tonight so that after your next interview it takes two minutes rather than an hour.

Written after finally sending the first draft

Do you send thank you emails?

I was convinced they were pointless until one got a reply.

Preparing for Interviews in More Than One Language

henry — Tue, 20 Oct 2026 13:00:39 +0000

Preparing for Interviews in More Than One Language
Interviewing in a second language adds a hidden tax: you translate while solving.

Build a bilingual glossary
List technical terms in both languages so neither slows you down.

Practice out loud in the target language
Narrate your reasoning, not just your code.

Tools
Phantom Code AI offers real-time transcription in 50+ languages and bilingual modes for code-switching conversations, which makes it a useful rehearsal partner.

Explore language support at phantomcode.co[https://www.phantomcodeai.com/]

Nail Behavioral Interviews: Turning Your Resume into STAR Stories Behavioral

henry — Thu, 15 Oct 2026 16:14:24 +0000

Nail Behavioral Interviews: Turning Your Resume into STAR Stories
Behavioral rounds decide more offers than people admit. The fix is preparation: a bank of real stories drawn from your own resume.

Step 1: Mine your resume
For each project, note the problem, your role, the decision you made and the result. Metrics matter: latency cut by 40%, onboarding time halved.

Step 2: Structure with STAR
Situation, Task, Action, Result. Spend most of your time on Action and Result. Keep the Situation to two sentences.

Step 3: Cover the classics
Conflict with a teammate, a failure, a tight deadline, a time you led without authority, and a technical disagreement.

Step 4: Rehearse out loud
Stories read well on paper and sound rambling aloud. Record yourself and trim.

Phantom Code AI lets you upload a resume once and tailors behavioral and project answers to it, which is a handy way to draft and sharpen your stories before the real conversation. Always make the final answers your own and truthful.

Ready to practice? Explore Phantom Code AI at https://phantomcode.co/. Always follow the rules set by your employer or assessment provider.

Microservices questions are really questions about failure

henry — Tue, 13 Oct 2026 18:08:45 +0000

Microservices questions are really questions about failure
Drawing three boxes is easy. The round turns on what you say happens when one box stops answering, and whether you can admit that a monolith might be the better choice.

Written after a design round that fell apart on retries. Updated October 2026. 8 min read

Bad answer: the order fails because email failed.
Better: the order is placed, the email is queued and retried, and the user sees a success.
The short version: draw boundaries around data ownership rather than around nouns, prefer asynchronous messaging for anything that is not needed to answer the user right now, make retried operations idempotent, and be willing to say that a single service would be simpler here. That last one impresses more interviewers than it loses.

Terminology varies between teams. What matters is that you can defend the boundaries you draw.

The round that fell apart on one follow up
"What happens if the email service is down?"

I had drawn orders, payments and email, with arrows between them, and I felt good. Then the interviewer took the email service away. In my design the order request waited for it, so taking it away meant customers could not place orders because a receipt could not be sent.

Nobody is impressed by the boxes. They are listening for what happens when one of them stops answering.
Boundaries follow data, not nouns
The first question to answer out loud.

A service should own its data and be deployable on its own. If two services need to write the same table to do their jobs, the boundary is in the wrong place. If a single user action requires five synchronous hops, the boundary is also in the wrong place, just in a different way.

Synchronous or asynchronous
Decide per call, and say why.

Sometimes
Not the tool for this
Which style suits which kind of work.
The rule I use out loud: if the user cannot get an answer without it, call it synchronously. Everything else becomes an event, which is also what stops one failing dependency from taking down the main path.

Retries make idempotency mandatory
Say this before you are asked.

Once calls can be retried, every operation must be safe to receive twice. That usually means a key on the request that the receiver stores, so a duplicate returns the original result rather than creating a second payment. This is the single most common follow up in distributed design rounds.

The vocabulary worth having ready
Four terms, one sentence each.

Circuit breaker
Stop calling a failing dependency for a while so you fail fast rather than queueing.
Backoff with jitter
Space out retries and randomise them so clients do not retry in lockstep.
Saga
A workflow across services where each step has a compensating action.
Outbox
Write the event in the same transaction as the data so the two cannot disagree.
The answer that scores well
Being willing to say monolith.

Reasons to split
Different scaling profiles
Clear data ownership
Teams blocking each other on deploys
Different reliability requirements
Reasons to wait
A small team
An unclear domain
No deployment automation yet
Every change touching several services
How I practised the follow ups
Design, then remove a service.

My routine was to draw a design and then delete one box and talk through what happens. I used Phantom Code AI[https://www.phantomcodeai.com/] in its slower reasoning mode to attack the design rather than produce one, asking what breaks when a dependency times out or when a message is delivered twice. Since it covers coding, SQL and behavioral practice as well, one evening habit carried the whole loop.

Common questions
Short answers.

How do I pick boundaries?
When should calls be asynchronous?
What is a saga?
Is a monolith ever right?
Design for the day something is down
Every distributed design question eventually becomes a question about partial failure, because that is what the job actually is.

Take a design you have drawn and remove one service. Write what the user sees.

Written after an email service taught me a lesson

What is the smallest useful service you have shipped?

And did it stay that size?

Machine Learning Interviews and How to Spot Data Leakage

henry — Fri, 02 Oct 2026 14:42:20 +0000

A model achieves an impressive score, but its performance collapses after deployment. In a machine learning interview, one explanation to investigate is data leakage: information reached the training or evaluation process in a way that would not be available for the intended prediction.

Start with the prediction moment. For this exercise, a service predicts on Monday whether an account will cancel during the following 30 days. Every feature must be justified in relation to what the system knows on Monday. A feature can look harmless in a spreadsheet and still reveal the future.Ask when each feature becomes available

Recent activity measured before Monday may be eligible. A final cancellation reason recorded three weeks later is not. A customer status field can also be dangerous if historical training rows were assembled from the latest account table rather than a snapshot from the prediction time.

That problem is not solved by removing a column named cancelled. Information about the outcome can hide in support workflows, billing adjustments, or fields updated after the event. Ask how each feature was produced and whether the historical value matches what a production request would have seen.

Distinguish event time from ingestion time. An event that happened before Monday but only arrived on Wednesday might still be unavailable to Monday's live prediction. The relevant boundary is actual availability under the proposed serving process.

Make the split match the question

If deployment predicts future behavior, a chronological evaluation can help test that setting. If the same person appears in multiple rows, consider whether splitting related rows across training and evaluation creates an easier problem than the one you intend to solve.

There is no universal split that fits every task. Explain the generalization you care about: future periods, unseen people, new organizations, or another population. Then choose a split that approximates it and state what it leaves untested.

Fit preprocessing in the right place

Transformations learned from data can leak information too. A scaler, imputer, or feature-selection step fitted using evaluation data has already learned something from the examples intended to assess the model.

The scikit-learn common-pitfalls guide discusses this issue and the use of pipelines to keep fitted transformations tied to the training process. In cross-validation, learned preprocessing should be fitted within each training fold. A pipeline helps enforce that organization, but it cannot fix features that already contain future information.

Investigate a suspicious score

Ask for a simple baseline, a feature-availability audit, and a comparison using a split that matches deployment. Remove questionable features and observe how performance changes. A score drop is evidence worth examining, but it does not by itself identify which feature was invalid or prove the remaining model is ready.

Check the evaluation metric against the decision too. A churn model may inform a limited outreach budget, so ranking quality at a useful operating point can matter alongside aggregate metrics. Avoid making business claims from one score without defining how predictions will be used.

For general technical rehearsal, explore PhantomCodeAI's interview resources, then validate ML-specific advice against the modeling library and your data construction. A useful practice prompt asks you to audit feature timestamps and defend the split, rather than merely recite a definition of leakage.

Finish with a production question: can every feature be computed with the same meaning and timing when a real request arrives? That question connects offline evaluation to the system you actually intend to build.

Coding Interview Patterns and the Sliding Window Invariant

henry — Wed, 30 Sep 2026 14:35:32 +0000

Recognizing a coding interview pattern is useful only when you can explain why the pattern applies. Sliding window is a good example. It is tempting to see an array or string and start moving two pointers, but the important decision is what those pointers represent.

Consider this practice question: find the length of the longest contiguous substring with no repeated characters. For the string abcaef, the answer is five, corresponding to bcaef. The problem gives you a window whose validity you can test and restore as you move through the input

Worked example using the string abcaef. The longest substring without repeated characters is bcaef.

State what must remain true

Let the left and right positions define the current substring. After processing each new character and repairing the window, every character inside that substring must be unique. That statement is the invariant: the property you preserve as the algorithm progresses.

Read the characters from left to right. The window grows from a to ab to abc. When the next a arrives, keeping the original a would create a duplicate. Move the left boundary past that earlier a. The valid window becomes bca. Adding e and f then produces bcaef.

Notice what you did not do. You did not restart the entire search after seeing a duplicate. Earlier positions that would still include the repeated a cannot produce a valid window ending at the current position. Moving the boundary discards those possibilities for a reason.

Choose an implementation you can explain

One approach uses a set of characters. When a new character is already present, repeatedly remove the leftmost character and advance the left boundary until the duplicate has been removed. Then add the new character and update the best length.

Another approach records the most recent index of each character. On a repeat, move the left boundary to the larger of its current value and one position after the previous occurrence. That maximum matters. A character that appeared before the current window must not pull the boundary backward.

Both approaches require assumptions about character comparison and indexing. For a basic practice problem, ordinary character units may be sufficient. If the question concerns user-visible Unicode characters, clarify the required unit instead of silently assuming that every language handles strings identically.

Derive the running time from movement

In the set-based approach, a nested loop does not automatically mean quadratic time. The right boundary advances across the string once. The left boundary also advances at most across the string once. With average constant-time hash-set operations, the total work is linear in the input length.

Space depends on the maximum number of distinct characters held in the window. State that relationship before claiming constant space. A fixed, bounded alphabet and an unrestricted character set are different assumptions.

The PhantomCodeAI coding interviews hub includes pattern-based preparation. When using a guide or an AI hint, ask it to explain the invariant before showing an implementation. That makes the exercise transferable to unfamiliar wording.

Learn when the pattern stops working

The same boundary movement does not automatically solve every contiguous-subarray problem. For example, reasoning that extending a window always increases its sum depends on the values being nonnegative. Negative numbers can break that reasoning.

Finish your practice by testing an empty string, a string of identical characters, a string with all unique characters, and a repeat that occurs outside the current window. Then explain the algorithm without naming the pattern. If you can justify each boundary movement, you understand more than its label.

The failure question is not a trap. It is an ownership test.

henry — Mon, 28 Sep 2026 12:12:32 +0000

used to answer this with a failure that was secretly someone else's fault. Interviewers hear that immediately. Here is the structure that works and the kind of story worth telling.

Written after telling this story badly several times · Updated September 2026 · 6 min readThe answer that quietly cost me
A failure that was, conveniently, somebody else's fault.

My old answer went something like: the deadline was unrealistic, requirements changed twice, and the release slipped. All true. Also a description of a situation rather than a decision, and every interviewer could hear that I had not taken anything personally out of it.

This question is not looking for a flaw. It is looking for evidence that you can hold a decision that went wrong.
The three part structure
Under ninety seconds.A worked example: "I ran a schema migration on a Friday without a dry run because we were behind. It locked the orders table and checkout was down for forty minutes. The deadline was real but skipping the dry run was my call. We added a dry run and a rollback plan to the migration checklist, and I have not run one without both since."How I practised saying it calmly
Out loud, with pushback.

Writing the story was easy. Saying it without either minimising or over apologising took repetition. I uploaded my resume to Phantom Code AI[/www.phantomcodeai.com] and used its mock practice so the follow up questions referenced the actual project, which made the rehearsal feel like a conversation rather than a monologue. Then a friend ran it once and told me my voice went up at the end, as if asking permission.

That was the real fix. The story was fine. The delivery was apologising for existing.

Common questions
Short answers.

Which failure should I choose?
Can it be non technical?
What if nothing big has gone wrong?
How long should the answer be?
Own one decision and show the change
Everyone has shipped something that broke. The candidates who do well are the ones who can name their part in it without flinching and point at what is different now.

Write yours in three sentences tonight. Read it back and delete any sentence that shifts the blame.

Written by someone who now dry runs everything

What failure would you tell?

The good ones usually still sting a little.
Some third-party reviews of these tools are published by competing products, so verify prices on official sites before buying.

Some interviews now let you use AI. That's harder, not easier.

henry — Thu, 24 Sep 2026 13:32:57 +0000

A growing number of companies hand you the tools and watch how you use them. Same 45 minutes, completely different scoring, and a very obvious gap between people who direct a model and people who follow one.

Written after two AI-permitted rounds · Updated September 2026 · 8 min read

AI tools: allowed in this round
45:00

!
The short version: when AI is allowed, the code stops being the signal. What gets scored is whether you had a plan before you prompted, whether you reviewed what came back, and whether you can defend the result under questioning. Prompting fast and pasting fast is the fastest way to fail an open-tools round.

This is about rounds where AI is explicitly permitted. When it isn't, using it is cheating, whatever a tool's marketing says.

The round where my instincts were wrong
I'd trained myself to hide the tools. Then they handed me one.

Every piece of advice I'd absorbed said: close everything, prove it's all you. Then an interviewer said, "use whatever you'd use on a normal workday, just talk me through it." I froze for a second, which is a funny way to fail a round designed to be easier.

What I learned over the next forty minutes is that open-tools rounds are not a relaxation of the standard. They move the standard somewhere harder to fake.

When the code is free, the only thing left to evaluate is your judgement about it.
What actually gets scored
Four things, none of them typing.

A plan before the prompt
"Here's my approach; I'll use the tool for the boilerplate." Said out loud, before anything is generated.
Review of what came back
Reading the output critically, out loud, including what you'd change.
Knowing when not to use it
Writing the core logic yourself is a signal, not a weakness.
Defending the result
Every line is yours the moment you submit it.
Two candidates, same tools
The difference shows up in one question.

How to practise for open-tools rounds
Narrating is the skill.

Practising this alone is awkward, because the natural way to use a tool at home is silently. So I made the narration the point. In my nightly sessions with Phantom Code AI I'd state my plan out loud first, then capture the problem and compare its approach and complexity against mine, saying what I'd keep and what I'd change. It covers coding, system design, SQL and behavioral rounds, so the same habit carried across the whole loop, including the closed-tools rounds where I practised without it entirely.

What it can't do is play the interviewer who interrupts you at minute twelve to ask why. A friend did that once a week, and those sessions were where the narration actually became natural.

The closed-tools rounds still exist
And the rules there are absolute.

Most interviews are still no-tools, and in those, hidden assistance is cheating regardless of how a product markets itself. Detection keeps improving on assessment platforms, and the follow-up question exposes borrowed answers faster than any software does. If the round is closed, close everything.

Ask which kind of round it is. Ten seconds of clarification beats forty-five minutes of guessing.
Common questions
Short answers.

Do companies allow AI now?
What's scored when it's allowed?
Should I use it if I'm faster alone?
What if they don't say?
The tools stopped being the secret
For two years the anxious question was whether you could get away with using AI. The more interesting question now is whether you can be trusted with it, and that one you answer out loud.

Next practice session, narrate the whole thing as if someone is listening. It's harder than it sounds and it's the entire skill.

— Written after being told to use whatever I'd normally use

Have you had an AI-permitted round yet?

I want to know how common this is getting.
Some third-party reviews of these tools are published by competing products, so verify prices on official sites before buying.

AI mock interviews vs human ones: I tried both. You need both.

henry — Mon, 21 Sep 2026 13:39:04 +0000

An AI never gets tired of your fifth attempt at the same problem. A human notices when you stop making eye contact. Here's what each is actually good for, and the weekly mix that worked.

Written after 40+ practice sessions of both kinds · Updated September 2026 · 8 min read

WHO SHOULD INTERVIEW YOU TONIGHT?
🤖

Short answer: use AI for volume and humans for realism. An AI mock interview tool like Phantom Code AI (free plan, from $19 a month) is unbeatable for nightly repetition across coding, system design, SQL and behavioral rounds. A human mock, from a peer or a paid coach, catches what AI can't: nerves, pacing, body language and the awkward silence. My mix: five AI sessions and one human session a week.

Prices and features checked September 2026 and may change. Always verify on official websites before buying.

Forty mocks, two very different teachers
Neither one alone was enough.

For the first month of my job search I only practised with an AI tool. My solutions got cleaner, my complexity explanations got sharper, and then my first real interviewer interrupted me mid-sentence and I lost the thread completely. The AI never interrupted.

For the second month I added human mocks, and discovered the opposite problem: people are brilliant at pressure and terrible at availability. My peer partner cancelled twice in a week.

!
AI taught me what to say. Humans taught me how to say it with someone watching.
What each one is actually good at
An honest split.

Not clearly listed
My experience across roughly forty sessions. "Limited" means it depends heavily on the person or tool.
The pattern is clean. AI wins everything to do with volume and explanation. Humans win everything to do with being watched. Nothing in the chart is a close call.

widely and are often $100 or more per session; peer platforms are often free. AI assumes one month of a paid plan or a free plan.
Ten coaching sessions can cost more than a year of an AI tool. That does not make coaching bad; a great coach can c
Common questions
Quick answers.

Are AI mocks as good as human ones?
How much does a human coach cost?
How often should I do mocks?
Which AI mock tool should I use?
Don't pick a side. Build a rhythm.
The question isn't AI or human. It's what each one is for. Let AI carry the hundreds of repetitions nobody else has patience for, and save human time for the one thing it's uniquely good at: making you feel watched.

Five nights with AI, one with a person. That rhythm got me further in four weeks than three months of either alone.

Start AI practice tonight on a free plan
Book one human mock for this weekend
Ask the human to interrupt you on purpose
Fix their notes with AI on Sunday
— Someone who finally learned to talk slower

Have you ever done a mock with a stranger?

How did it compare to practising alone?
Some third-party reviews of these tools are published by competing products, so verify prices on official sites before buying.