Read the JD, the Engineering Blog and the Product Like an Insider

Here is what one interviewer heard from two candidates when she asked, "What do you know about what we do?"

The first said: "You're a leading fintech company with a great culture and innovative products." She has heard it hundreds of times.

The second said: "You help small online sellers accept payments and get paid out the next day. I tried the test mode of your payment links: creating a link and paying it with a test card took a couple of minutes. Reading your post on payout retries, I wondered how you decide when a failed payout should be retried versus sent back to the merchant." That candidate got a ten-minute conversation, and the interviewer remembered her.

The difference is three sources read properly. This article shows how.

• How to read a job description for explicit, implied and team-level needs.
• How to compare several job descriptions from the same company.
• How to extract decisions, trade-offs and likely questions from an engineering post.
• How to use a product, or its developer mode, to form specific observations.
• How to bring all of this into an interview without sounding rehearsed or critical.

You read job descriptions in three layers in article 12 to tailor your resume. For an interview, read them again for what the team needs and how they are likely to test it.

Analyse this job description for an interview I have. Quote the text for every point.1. Stated requirements: list them.2. Implied needs: what does the wording suggest the team cares about that is not   stated directly? (For example, "comfortable with ambiguity" may suggest a small   or fast-changing team.) Mark these as interpretations, not facts.3. Technical signals: which technologies and problem areas recur, and what kind of   problems would a team with this stack likely work on?4. Likely interview focus: given the above, which technical topics and behavioral   themes should I prepare? Mark this as a prediction.Do not use information from outside this description.[paste job description]

The quotes keep the assistant honest, and the labels ("interpretation", "prediction") keep you honest about what you actually know.

If the company has posted several similar roles, now or in the past (check its careers page, job boards and your saved copies), compare them:

Here are [N] job descriptions from [company] for entry-level or similar roles.1. What appears in all or most of them? (Likely the company's constant priorities.)2. What appears in only one? (Likely specific to that team or role.)3. Given the constant priorities, what should I spend most of my preparation on?Quote each description.

What stays constant across descriptions is usually what every interviewer at the company cares about: a language, testing, fundamentals, ownership. What changes is team-specific.

An engineering post is a company explaining, in public, a problem it found hard. That makes it unusually good interview preparation. Most posts contain five things:

1. The problem. What was failing or not scaling.
2. The decision. What they built or changed.
3. The alternatives. What they considered and rejected, and why.
4. The scale. Numbers that tell you what "large" means to them.
5. The values. What the post celebrates: reliability, speed of shipping, simplicity, cost.

Each maps to a kind of interview question: "How would you approach X?", "Why choose A over B?", "What breaks at larger scale?", "Tell me about a time you made a trade-off."

Here is an engineering blog post from [company]. Using only the post:1. The problem, in one sentence.2. The decision, and the two most important reasons given.3. The alternatives considered and why they were rejected.4. Any numbers about scale, quoted.5. What the post suggests this team values.6. Three questions an engineer on this team might ask an entry-level candidate   about this kind of problem, and what a good answer would need to cover.7. One honest connection to my project ([description]), or "no strong connection".[paste post]

Then read the post yourself. The summary helps you decide where to look; the post is what you will be asked about, and an interviewer who wrote it will notice if you only read a summary.

Answer the three generated questions out loud, as you would in the interview. If an answer depends on knowledge you lack (for example, how message queues guarantee delivery), that is your study topic for the next day.

Engineers use their product every day. Candidates who have used it seriously say different things from those who have only read the homepage.

For an app or website (shopping, food delivery, investing, travel):

• Use it for real for a few days, if you can do so sensibly. You do not need to spend much money; browsing, searching and comparing count.
• Notice moments that feel slow, confusing or impressive, and features you expected but did not find.
• Think about what has to work behind the screen: search ranking, availability, payments, notifications, live tracking.

For APIs, payment gateways, developer tools and business software:

• Many offer a free tier, a trial or a test mode (payment gateways commonly have test keys and test cards). Sign up and do the "getting started" guide.
• Read the documentation. Its structure shows what the company thinks matters most.
• If time allows, build a tiny integration: a page that creates a test payment, a script that calls their API. This is the strongest product preparation there is, and it can become a line on your resume.
• Respect terms of use, never use real customer data and never probe for security weaknesses on a company's live systems.

I used [company]'s product as follows: [what you did].My observations: [list 5 to 8 specific, factual observations].For each observation:1. What engineering reasons might explain it? Label these as guesses.2. Is it consistent with what the company's posts (in my notes) say they prioritise?3. Would it make a respectful interview question? If so, phrase it with curiosity,   not criticism.

Three places this research shows up:

1. "What do you know about us?" One sentence on what the company does in plain words, one on the part that interests you, and one specific detail from the product or a post.
2. Technical rounds. When a problem resembles their domain, you recognise it and ask sharper clarifying questions. When asked to design something, you can mention a trade-off they wrote about, carefully ("I read that your team chose X for Y; I'd consider something similar because…").
3. Your questions at the end. Article 29 builds these from your research.

Ananya has an interview at an online travel company for a junior backend role.

• Job description: stated: Java, REST, SQL. Implied: "high availability during peak seasons" suggests traffic spikes matter. Signals: search, pricing, bookings.
• Comparing four descriptions: all mention "ownership" and "testing"; two mention caching. She prepares caching basics and a story about owning a bug fix end to end.
• Engineering post: about caching search results for popular routes and handling stale prices. Alternatives considered: a shorter cache lifetime (more load) versus checking the live price at booking time (chosen). Likely question: "How would you avoid showing a price that has changed?"
• Product: she searches the same route at different times and notices the price shown at search sometimes changes at the booking step, with a message. This matches the post.
• In the interview: asked about caching, she explains the trade-off between freshness and load, then mentions, carefully, that she noticed the re-check at booking and asks how often prices change between search and booking. The interviewer explains, and the round becomes a conversation.

• Reading only the job description's skills list.
• Relying on AI summaries of posts without reading the posts.
• Never using the product, or using it for two minutes the night before.
• Turning observations into criticism.
• Presenting guesses about architecture as fact.
• Probing a company's systems beyond normal use. Never.

• Next: Why This Company, Questions to Ask and the Interview-Day Routine turns this research into answers and questions.
• For queues and retries like those in Exercise 2, see Design a Notification System: Email, SMS and Push at Scale.
• For job descriptions and skill gaps with AI, see Job Descriptions, Skill Gaps and Portfolio Projects with AI.