How to Research a Company Before Your Tech Interview (Engineer's Checklist)

Interviewers at FAANG have a nearly infinite candidate pool. One of the cheapest signals they use to separate "good" from "great" is how well you know the company going into the loop. Not the marketing website. The engineering internals: what they build, how they build it, and what hurts today. This guide is the engineer-specific research checklist, built to finish in under three hours and pay off in every round.

Table of Contents

• Why Research Beats Rehearsing Answers
• The Three-Hour Research Plan
• Sources Ranked by Signal
• What to Look For in an Engineering Blog
• Checking the Product Yourself
• Leadership and Funding Context
• Glassdoor and LevelsFyi: What to Trust and Ignore
• Turning Research Into Questions
• Questions Tailored to Each Round
• FAQ
• Conclusion

Why Research Beats Rehearsing Answers

Coding and behavioral rehearsal are table stakes. Every candidate does them. Research is asymmetric: 30 percent of candidates do enough of it to stand out. The payoff shows up in four places:

1. Answering "why us" without sounding generic. This alone lifts you out of the "standard candidate" pool.
2. Asking smart questions at the end. Interviewers rank candidates partly on the quality of questions asked.
3. Understanding the system design prompt. If you know the company builds on Kafka and Cassandra, your design will resonate.
4. Negotiation leverage. Knowing the funding situation, headcount, and recent leadership changes gives you context the recruiter does not expect you to have.

The Three-Hour Research Plan

Block three hours, one or two days before the loop. Here is the budget that works:

• 45 minutes: Engineering blog. Read the most recent 5 posts and any post with "scale", "architecture", "outage", or "postmortem" in the title.
• 30 minutes: The product itself. Sign up, use it, take notes.
• 30 minutes: Team and role context. Find the team you are interviewing with. Identify their manager, recent hires, what they ship.
• 30 minutes: Business context. Revenue, funding, recent press, upcoming regulatory or competitive pressures.
• 15 minutes: Glassdoor and levels.fyi. Get a baseline on interview format and compensation bands.
• 30 minutes: Write 10 questions you would ask. Refine the list to 5.

That is exactly three hours. Do not skip any section.

Sources Ranked by Signal

From highest signal to lowest, the order is:

1. The company's engineering blog. They choose what to publish. It is the closest thing to a public version of their tech strategy.
2. Conference talks on YouTube. Look for the company name at Velocity, QCon, Strange Loop, KubeCon, SREcon. Staff engineers explaining real outages is pure gold.
3. Their open-source repos. Tells you the tools, languages, and coding standards they actually use.
4. GitHub of the team you are interviewing with (if public).
5. The product or service itself. Use it. Break it. Notice the release cadence.
6. Recent news about the company. Earnings calls, acquisitions, executive changes.
7. LinkedIn posts from engineers on the team. Filter for the last 90 days.
8. Glassdoor interview reviews. Skim for question patterns. Do not over-weight.
9. Reddit and Blind. Take both with heavy salt. Occasional signal on compensation ranges and culture red flags.
10. Marketing website. Lowest signal. Read only for positioning vocabulary.

What to Look For in an Engineering Blog

When reading an engineering blog, you are hunting for five specific artifacts:

1. Current stack. What languages, frameworks, databases, and message buses are they running?
2. Recent pain points. Any post titled "lessons learned" or "postmortem" or "how we scaled X" tells you what was broken recently.
3. Architecture trends. Are they breaking up a monolith? Going serverless? Moving from Python to Go?
4. Scale numbers. Requests per second, data sizes, team sizes. Useful context for system design rounds.
5. Author bios. Who writes the blog posts? Those people are often on the hiring committee or are calibrating interview questions.

Copy the most recent 3 post titles into your notes so you can reference them naturally. "I read your post on moving from RabbitMQ to Kafka last month and I was curious how the migration affected on-call load" is a devastatingly effective opener in a "questions for me?" round.

Checking the Product Yourself

Actually using the product is a differentiator. Most candidates do not, or do so only superficially.

• Sign up. If there is a free tier, create an account. Note any onboarding rough edges.
• Use it for 20 minutes. Find two things you like and two things that feel broken.
• Read public release notes. What shipped in the last 6 weeks tells you about release cadence and priorities.
• Check mobile if applicable. Apps have different teams and different technical constraints.

Be prepared to say: "I signed up last week and noticed X worked well but Y felt slow — was that a recent change?" This shows you are already thinking like a user-facing engineer.

Leadership and Funding Context

For public companies:

• Read the most recent earnings call transcript. Search for "AI", "cost", "growth", "layoffs", and the engineering org's business unit.
• Check the stock's year-to-date performance. Is the company in expansion mode or defensive?
• Look at the CEO's most recent shareholder letter. It sets the org's priorities for the year.

For private companies:

• Check Crunchbase for the last funding round, the valuation, and the investors.
• Check LinkedIn for headcount growth over the last 12 months. Up 30 percent? Expansion. Down 10 percent? Contraction.
• Look for the founder's recent podcast appearances. Founders talk openly on podcasts in ways they never do on blog posts.

This context shapes how you negotiate compensation later.

Glassdoor and LevelsFyi: What to Trust and Ignore

Glassdoor is useful for:

• Interview format (rounds, duration, question topics). Generally accurate.
• Red flags on culture (only if there is a consistent pattern across 30+ reviews).

Glassdoor is not useful for:

• Specific interview questions. They get rotated. Memorising them is a waste.
• Star ratings. Noisy and easily gamed.

LevelsFyi is useful for:

• Total compensation ranges by level. Generally accurate for FAANG and well-funded startups.
• Equity structure (RSUs, stock options, vesting schedules).

Use it to build your negotiation floor before the recruiter asks "what are your compensation expectations".

Turning Research Into Questions

The goal of research is not just to understand the company. It is to generate the 5 smart questions you will ask at the end of each round. A smart question is:

• Specific. Ties to a concrete artifact (blog post, product feature, recent news).
• Open-ended. Cannot be answered with yes or no.
• Calibrated to the interviewer. Technical questions for engineers, strategic questions for managers, team questions for recruiters.
• Reveals that you already know something. Shows you did the homework.

Bad question: "What is the culture like?"

Better question: "I read your post on migrating from REST to gRPC. How is the on-call experience changing as the service mesh matures? Is the team still paged at old-monolith frequency?"

The second question makes the interviewer want to hire you.

Questions Tailored to Each Round

For the recruiter:

• What does the loop look like end to end, and is there one round where candidates typically get filtered out most?
• What is the team's composition today and are they in hiring-growth or steady-state?
• When you present my candidacy to the hiring manager, what signals will they be looking for?

For a peer engineer:

• What is the hardest technical problem on your team this quarter?
• What would a new hire on this team be working on in the first 90 days?
• If you had to onboard a new engineer, what is the single piece of context they would miss from reading only the engineering blog?

For the hiring manager:

• How do you think about the balance between shipping speed and code quality on this team?
• What is the team's biggest operational risk today?
• What does a "great first 6 months" look like for a new senior engineer here?

For the skip-level / director:

• How do you think about the team's charter 12 to 18 months out?
• What is a past hire who exceeded your expectations and what did they do differently?
• What is the company's biggest external pressure right now and how does it shape engineering priorities?

Frequently Asked Questions

Isn't three hours of research overkill?

No. FAANG loops represent hundreds of hours of lifetime earning potential. Three hours is a 100x-to-1000x return on time.

What if the engineering blog is sparse?

Switch to conference talks and GitHub repos. Also check the CTO's and VP of Engineering's Twitter or LinkedIn for recent posts.

What if I am interviewing at a stealth startup with no public info?

Ask the recruiter for a founder call and a product demo before the loop. If they refuse both, that is data about the company's respect for candidate time.

Should I mention specific blog posts during the interview?

Yes, but sparingly. Once per round max, at the natural moment. Over-mentioning reads as brown-nosing.

Can I ask questions about compensation in the last 5 minutes?

Save those for the recruiter, not the engineers or hiring manager.

Conclusion

Researching the company is the single most asymmetric preparation you can do before a tech interview. Three hours, spent on the engineering blog, the product, and the business context, will carry you through every round with sharper answers and better questions. Do it two days before the loop, not two hours. The goal is not to recite facts — it is to walk into the loop already thinking like someone who works there.