Data job search

This course is for people looking for a data job: Data Engineer, Analytics Engineer, Data Analyst, BI Engineer.

I built it from three years of our own Discord. Every resume we reviewed, every interview question someone brought back, every offer people announced, every salary number they were willing to share. Nothing here is theory. It is what happened to people in Surfalytics between November 2023 and September 2026.

When I say something works, I can show you who it worked for and when.

One rule that runs through every module

Never stop searching. Not because your job is bad. Because the search is a skill, and skills fade when you stop using them. And because a better job might be open right now, and you will not know unless you look.

I have said this in our channels more than once:

“this is the point about Job Security. It is not exists, you need to study more and build your networking and personal brand by writing posts, commit to git and be active here and in Linkedin. Otherwise you are in higher risk.”

Nikita runs it as a routine, and he is employed:

“Every 6 months I do an active job search to practice interviews, update resume, check what skills are in demand, and see if I can get a higher compensation. In today’s market, it’s important to stay in interview shape, so if a layoff ever happens, you can find a new job quickly.”

So every module ends with a list of action items, and the last item is always a habit you keep after you land. A recruiter call you take even when you are happy where you are. A question you add to the bank after every interview. A number you update every quarter. Do these while employed and your next search takes weeks, not months.

The modules

Module	What you walk away with
0 — Reality check	Your own baseline: target date, weekly application count, how many rejections to expect
1 — Pick one role	One target title and one line that says what you are
2 — The resume	A resume matched to that role, reviewed by people who will be honest with you
3 — Portfolio and proof	One public project you can talk about for twenty minutes
4 — The search engine	A weekly routine and a written filter for what you apply to
5 — Interview rounds	Written answers for your top twenty questions, plus three stories
6 — Record, transcribe, compound	A recording setup that turns every interview into material for the next one
7 — Mock interviews	Three mocks done, with written feedback
8 — Offers and negotiation	A script you have said out loud, and your number
9 — Stay in interview shape	A monthly routine you run from day one and keep after you land

How to work through it

Modules 0 to 4 are setup. Give them about two weeks.

Modules 5, 6 and 7 never really finish. You run them while you search. Each interview feeds the next one.

Module 8 matters when offers start coming.

Module 9 is the habit behind the whole course. Read it early, not last. It tells you what to keep doing after you land, and it is the part most people skip. Do not skip it.

If you only read one module, read Module 4. It has the one number that changed how I think about job searching: three people tracked their own conversion rates, and applying to more jobs was the worst of the three strategies by a wide margin.

What you will not find here

No advice like “finish your degree first”, “start as a junior and wait”, or “take shifts at McDonald’s while you look”. That is the slow road. Our goal is a result, fast: a better job, higher income, stronger skills, and learning that never stops.

Think of an escalator that goes down. That is your career. To keep your place you have to walk up, all the time. Walking up means studying, networking, upskilling, and searching for jobs. Stop walking and you are out.

Here you will learn about real job searching and real job security. No bullshit.

Two notes on who this is for:

• New grads and first job. You are welcome here. Your problem is a chicken-and-egg one: no job without experience, no experience without a job. We help you break it. This course gives you a purpose, a plan to start, and a way to speed up once you are in.
• Overemployment and contract stacking. That is Club 500, and it gets its own course. It needs two things first: you are an expert at what you do, and you already hold at least one decent job. You cannot scale what you do not have. Get the first job right here, then scale it there.

Where it came from

Source	Volume
#job-searching-and-interviewing	3,253 messages, 1,584 conversations
#resume-review	1,184 messages, 346 conversations
#mock-interviews	258 messages

Time to complete: 30-40 minutes

You finish this module with:

• A target role and market. One role, one country. If you want two, make two pages.
• A target date. 2 to 6 months from today, depending on your market and your skills.
• A weekly application number. How many you send each week, in your chosen mode.
• An expected reply count. How many real responses to plan for, so silence does not surprise you.

Why this module exists

I have watched a lot of people quit their job search in our community. Almost none of them quit because their skills were bad. They quit because their expectations were wrong. They expected two weeks and got three months. They expected every application to get a reply and got silence 97% of the time. Then they gave up, right before it usually turns.

So before you send one more application, I want to give you real numbers. Thirteen people in our community landed offers between 2023 and 2025, and they tracked their own numbers in #job-searching-and-interviewing while they did it. I watched most of this happen live. Use their numbers to set your own expectations. Then I am going to tell you the honest limit of these numbers, because I don’t want you walking away with a false sense of odds.

Last, I want to cover the market as it is right now, in 2026. It is harder than it was a few years ago. You need to know that going in.

Lesson 0.1 — The real numbers

Thirteen people in our community reported landing at least one offer. Here is what their search looked like.

Measure	What our community shows
Search duration	2 to 6 months, median 3 months
Applications sent	7 to 200, median 63
Response rate	About 3%, in the one case with full numbers (viktor090134: ~200 applications, 6-7 responses)
Interview rounds per process	3 to 6, typically
Offers declined	Common. One member (ksuna92) received 4 offers and declined 3

One person (olelle8) sent 7 applications and got an offer from the first interview. Another (viktor090134) sent about 200 applications over 6 months and got 6-7 responses. I saw both of them post in the same channel. Do not assume you will be the 7-application case. Plan for the median: about 3 months, about 63 applications.

Nikita, who tracks his own numbers closer than almost anyone I know, has been posting weekly progress updates in our community since 2023. Here is one of them:

Week #5
Applied this week: 12 positions

Total Applied: 74
Automatic rejections: 13
Interview invitations: 2
Rejection after interview: 1
Waiting for feedback for Support DE

At a response rate near 3%, you can expect about 3 replies for every 100 applications you send with no referral and no personalization. That is the current baseline, not a flaw in you. At that rate, volume alone is a weak strategy. Module 4 shows the numbers on why targeting and referrals beat volume.

Makseshina put the referral case plainly, from her own numbers:

The explanation is very simple. I try to get a referral to every position I apply for. And very seldom apply without it (because otherwise, the conversion rate for me is almost zero).

Lesson 0.2 — The survivorship warning

One thing before you read these numbers again. Everyone I listed above posted because they got good news. The people who searched for a year and gave up did not post anything. I know some of them personally. They are not in this data.

So read this as what worked for people who made it. Not as your odds.

This means:

• The 2 to 6 month range is how long it took the people who succeeded and told us.
• Somewhere, people searched longer and are not in this data at all.
• Do not treat 3 months as a deadline for yourself. Treat it as one useful data point among many.

Lesson 0.3 — Market conditions right now

The market changed between 2024 and 2026, and it changed for the worse on some measures. Plan for the market you are in, not the one your friend searched in two years ago.

• Application-to-interview rate fell. Nikita saw this in his own numbers:

  Before, around 15% of my applications led to interviews; now it’s closer to 8%… it could just be increased competition.

  Yury put the same shift more bluntly:

  The hiring process is completely broken with AI and fake profiles.

• Companies fight AI and demand it at the same time. Live technical tests increasingly ban AI tool use and enforce this with screen-share and camera monitoring. In the same period, a manager told Alexey outright that they would watch how he used an AI agent to solve a problem, “because that’s what’s needed in real life” (alexg7ag, Dec 2025). You need to prepare for both: doing your own work under camera, and having a real, specific answer about your AI usage.

• The new-grad market is broken. People in our community half-joke that colleges need a “middle” degree track, because there is no entry point below senior-adjacent expectations anymore. Nikita said this straight to a member asking about a first job:

  Unfortunately, in current market, it’s almost impossible to find a first job and being honest. If you are a student, you can probably find a coop, or there are some graduation programs in some companies. But if you are not eligible, the only way to find a job fast is to “fake it till you make it”.

  If you are early-career, expect this to be the hardest part of your search, and read Module 1 on how role and title choice can still help.

• Canada pay draws consistent criticism against cost of living. Our community’s consensus, stated many times over: “Canada is not about money… to live comfortably you’d need around 15k net/month.” If you are searching in Canada, factor this into your expectations for comp, covered fully in Module 8.

One line I keep repeating in the channel: “the market is challenging… we should always learn and keep interviewing” (dimoobraznii_91655, me). I mean it even after you get the offer. Job security does not exist, and a better job might be open right now while you are not looking.

Lesson 0.4 — The psychological framing that survives rejection

A search this long, with a response rate this low, will produce a long run of silence and no. You need a framing for that before it happens, not after.

Mikhail, one of our members, put it in one sentence that I still think about:

I prone to consider any interview held as failed until I get another feedback.

It is a way to stop each single rejection from becoming a verdict on your whole search. You treat every interview as closed and move to the next one, and you only update your read of yourself when you get an actual offer, not on every silence in between.

If you treat each non-response as new evidence that you are not good enough, a 3-month search becomes unbearable. Pick the framing that lets you keep going.

Lesson 0.5 — Desperation is visible. Pick your mode instead.

It does not matter how urgently you need the job. If you are desperate, you are cooked. Recruiters and hiring managers can feel it in the first five minutes, and it costs you leverage at every step, from the screen to the offer. The best time to search for a job is when you do not need one. That is why Module 9 exists, and why I ask every member to keep searching after they land.

If you need one now, you still have a choice to make. Decide your mode before you send the first application, and write it on your baseline page:

Mode	What it means	Who it fits
Active	Apply daily. Every new posting that matches your role and tool pair goes out the same day.	You are out of work, or your current job is ending on a date.
Passive	Apply weekly. Only roles you have a high interest in: better pay, better stack, better team. Say yes to recruiter calls.	You have a job and want a better one.

Both are fine. Mixing them is not. An active search run with a passive attitude gets nothing out. A passive search run with an active attitude burns you out on jobs you did not want.

Lesson 0.6 — Work permission is not a detail

If you are applying to a country where you do not have permission to work, you are buying a lottery ticket. Not a long shot. A lottery. Companies that sponsor exist, but in 2026 they are few, they are slow, and they pick from a line of people who can already start on Monday. I have watched members spend six months on this and get nothing, while a search in their own market would have landed.

Be realistic. Put your legal status at the top of the baseline page, and plan the search around the markets where you can sign a contract today. Relocation is a separate project with its own steps. I wrote about it in From relocation to employment. Do it after the job, or in parallel, never instead of the job.

Action items

The goal of this page is measurable targets. Numbers you can check each month. One page per role and country. If you search for two roles, or in two countries, make two pages. Do not mix them.

• Start one page. Write today’s date at the top.
• Write your target role: DE, AE, DA or BI. One only.
• Write your market: the country where you can legally work today. Search there.
• Write your mode: active (apply daily) or passive (apply weekly, high interest only).
• Write your target date to land the job: 2 to 6 months from today. Closer to 2 if your skills match the market well and you have referrals. Closer to 6 if the market is thin or you are changing roles.
• Write your applications per week. Our community’s median is about 5. Active mode is more, passive mode is less.
• Write your expected replies. Plan with 3%: 100 applications means about 3 real responses. The rest is silence.
• Write one sentence you will tell yourself after a rejection. Mikhail’s is a good start.
• Write two 2026 market conditions from Lesson 0.3 that apply to your role and market.
• Put a monthly reminder in your calendar. Each month, compare the page with what happened.
• Keep searching: every quarter, even after you land the job, check the page against the market as it is then. The 3% and the months will move. Better to see it early than on the day you need a new job.

Example: a filled-in baseline page

This is what the page looks like when it is done. One role, one country. Numbers are one member’s example, not a template to copy. Yours will differ.

Baseline — Analytics Engineer, Canada
Written: 3 March

Target role:        Analytics Engineer
Market:             Canada (permanent resident, can start any time)
Mode:               Passive. Employed, want better pay and a dbt stack.
Target date:        3 June (3 months). Skills match, no referrals yet.
Applications:       5 per week, search "SQL dbt" and "SQL Snowflake".
Expected replies:   60 applications x 3% = about 2 real responses.
                    Plan for 58 silences and rejections before that.
After a rejection:  "Every interview is failed until I hear otherwise. Next."
Market conditions:  1. Interview rate fell from ~15% to ~8% for the same profile.
                    2. Live tests ban AI and watch the screen. Practice without it.

Monthly check:      first Monday of each month, compare this page to what happened.

Time to complete: 1-2 hours

You finish this module with:

• A target job title. One of DE, AE, DA or BI, checked against real postings.
• A one-line positioning statement. What you are, in one sentence.
• 5 real job descriptions. Saved in full, for that title.

Why this module exists

I have reviewed hundreds of resumes in our #resume-review channel. One critique comes up more than any other, for three years straight. It is one resume trying to cover Data Analyst, Data Engineer, and BI at once. It reads as unfocused. A recruiter scanning it for 6 seconds finds no clear match, so it matches nothing. I say some version of this almost every week.

This module exists to stop you from making that mistake before you write a single bullet point. Pick one role first. The resume work in Module 2 depends on this decision. You cannot write a focused, achievement-led resume for a role you have not chosen.

There is a second reason. The job title you search under can hide or reveal most of the market. If you search under the wrong title, you will think there are no jobs. Under the right terms, the same jobs appear by the hundreds. I want to fix that for you before you conclude the market is empty.

Lesson 1.1 — How the role families actually differ, in practice

We cover the roles and what each one is for in Module 1: Analytics Fundamentals of the main course. If you have not done it, do it first. The whole roadmap is built around these roles: a clear picture of each role, what it requires, and the path to get there. That is your baseline. If a role is still unclear after Module 1, ask in #ask-anything. I answer there.

Here is the whiteboard from my session on the roles, from the source systems on the left to the job titles on the right:

Watch the full session: Data Job Roles in Traditional Data Analytics.

Companies use these four titles loosely and inconsistently, which is part of why candidates get confused. Here is what I have seen in our community, from real interviews members reported.

• Data Engineer (DE). Builds and maintains the pipelines that move data from source systems into a warehouse. Owns ingestion, orchestration (Airflow), incremental loading strategies, schema drift, and pipeline reliability. Interview questions our members report center on SQL optimization, Python, Airflow internals, and system design for pipelines under budget constraints. For the system design part, read my DE system design cheat sheet. To see the work itself, look at our DE projects folder, for example the Spark transformations with a test framework project.

• Analytics Engineer (AE). Sits between DE and the business. Owns the transformation layer, typically dbt models moving data from Bronze to Silver to Gold. Nikita, who has done more AE interviews than almost anyone in our community, put the priority simply:

  For analytics engineer it’s crutial to know dbt - it’s the main tool. All other tools could differ, but you need to know in general how they work or learn one of each tools because they are similar. Like learn dbt, Snowflake, Airflow

  Interview questions center on dbt materializations, incremental models, SCD Type 2, and testing/documentation practices.

  Real interview: Analytics Engineer at Tucows (Ksenia, Aug 2025)

  • Dimensions vs facts
  • SCD types
  • Joins vs CTEs
  • Star vs snowflake schema
  • How she uses AI in her work

  Projects for this role: end-to-end analytics with dbt and Looker, the one I share most often as a first project, and dbt-core + Snowflake.

• Data Analyst (DA). Answers business questions with data. A manager asks “why did sales drop in March?”, and the analyst finds the answer in the data and explains it in plain words. Day to day that means SQL queries, dashboards, and agreeing on how metrics are defined. One member described the role from the inside, after a Data Analyst interview at a financial services company:

  The data analysts usually wors as a bridge between technical team and the client at this company.

  Interview questions lean toward SQL joins and window functions, business case studies, and explaining a result to non-technical people.

• BI Engineer / BI Developer. Builds the dashboards and reports the whole company uses, in tools like Looker, Tableau or Power BI, plus the semantic layer behind them, where metrics are defined once so every report shows the same number. The difference from a Data Analyst: the analyst uses dashboards to answer questions, the BI engineer builds them and keeps them fast and correct. Interview questions cover tool-specific performance tuning (e.g. Looker query performance, Tableau performance recording) alongside SQL. Projects for this role: BI admin with Tableau and Looker + Snowflake. Looker is quite popular.

These are not hard boundaries. Companies blend them constantly, and a “Data Analyst” posting at one company can be a BI Engineer role at another. So pick a title to aim at, then verify it against real postings. Do not trust the title alone.

Our data-projects repo has projects for each role family. It is the most-shared link in our whole archive. Once you pick a role, look at what a matching project looks like.

Lesson 1.2 — The title-search trap

Job titles on LinkedIn do not map cleanly onto the roles above, and this can make you think a whole role family barely exists. I watched this happen in our channel. Alexey ran the same search on the same day and got very different numbers depending on the title he typed.

The Analytics Engineer work is still out there. It is posted under Data Engineer, BI Analyst, BI Developer, and Senior Data Analyst titles instead.

Do not search by title alone. Search by tool pair instead:

• SQL + dbt
• SQL + Snowflake

Tool-pair search finds postings no matter what title the company put on them. It is more reliable than trying to guess every synonym a company might use for the role you want.

Lesson 1.3 — Build 2 to 3 resume variants, not one

Titles and role boundaries are this blurry. So build 2 to 3 separate resumes, each matched to one title, instead of one resume that tries to cover everything.

This is what I do myself. I never customize a resume per application. I keep several fixed “flavor” resumes ready (AWS DE, Azure DE, GCP DE, Snowflake+dbt DE, Databricks DE, Open Source DE) and I pick whichever one is closest to the posting. The variants differ in emphasis and vocabulary. The work history underneath is the same. You are not lying on any of them. You are choosing which true parts of your experience to lead with.

This does two things at once:

1. It forces you to actually decide what you are, at least for this application.
2. It removes the unfocused, multi-role resume that I keep flagging in #resume-review as the top mistake.

Module 2 covers how to write the bullets themselves. This module is about deciding, before that, which 2-3 targets you are writing bullets for.

Read: From relocation to employment: strategies, on picking the right toolset and use cases for your resume. When you get to the bullets, use the resume fix checklist.

Lesson 1.4 — Choosing by demand versus by interest

You have two pulls on this decision: what you enjoy, and what the market wants. Weigh both, but weigh demand more heavily if you are early in your search.

• If you are choosing your first target role and have little bargaining power, lean toward the role with more open postings under your tool-pair search. A DE search returning 400 listings gives you more chances to learn what companies want, faster, than a narrower AE search returning 30.

• If you are already employed and searching passively, you have more room to weight interest heavily, since a slower search costs you less. Nikita runs this kind of passive search himself:

  I’m always in a passive job search — if recruiters reach out, I’m open to talking. But my bar is high: I’m only considering fully remote roles with a 180k+ CAD salary because I already have a good income.

• Either way, verify your choice against real postings before committing. Do not choose a title based on what sounds impressive. Choose based on what 5 real job descriptions for that title actually ask for.

Lesson 1.5 — Self-locating with the community roadmap

If you are unsure which family you already fit, or which one you are closest to being ready for, use our own community’s career roadmap. I built it to help you place yourself on the path from beginner toward a specific data role, and I share it in our channel for exactly this.

Action items

• Pick the one role family that best matches both your current skills and the work you want to do day to day. Write it in one word: DE, AE, DA, or BI.
• Search LinkedIn (or your local job board) with at least two tool pairs for that role (e.g. SQL dbt, SQL Snowflake) and with the title alone. Write down the listing count for each search.
• Collect 5 real job descriptions that match your target role. Save the full text of each, not just the title and company.
• From those 5 descriptions, list the 5 tools or skills that appear most often.
• Write your one-line positioning statement: “I am a [target title] with [1-2 years / X years] of experience in [top 2-3 tools from your 5 postings].” If it takes two sentences to say what you are, it is not focused enough yet.
• Decide whether you will build 2 or 3 resume variants. Name what separates each one (e.g. “Snowflake+dbt DE” vs. “GCP DE”).
• Keep searching: every six months, even after you are hired, run the same tool-pair and title searches again. Check whether your target title still has the most openings. If another title has more now, add a resume variant for it.

More resources

• Surfalytics blog: all our posts, including the Data Analyst roadmap.
• Club500: our membership page.

Time to complete: 3-4 hours, plus review time from peers

You finish this module with:

• One role-matched resume. One page or two, aimed at the title from Module 1.
• Bullets written with the community formulas. Action, tool, result, number.
• A Google Doc link posted for review. In #resume-review, with comments open.

Why this module exists

I have spent three years in #resume-review. I have read hundreds of resumes there, line by line, and left comments on most of them myself. This module is that channel, written down.

The mistake I see most is one resume trying to cover Data Engineer, ETL, and BI all at once. I have said some version of this in maybe twenty threads.

“it is not clear who are you? DE, ETL, BI? you need to have specialisation”

“You would need to have 3 resume: Analytics Engineer, Data Analyst, BI Developer”

If Module 1 gave you one target role, this module gives that role a resume built for it, not one that also kind of works for two other roles. Not sure the role is right? Check where you sit on our data analytics career roadmap first.

The second most common problem I see is bullets that list a task with no result. You will spend most of this module fixing that.

Lesson 2.1 — The structure

We never agreed on everything in that channel. We did agree on this order:

Section	What goes in it
1. Contact	Name, city, phone, email, LinkedIn
2. Summary	2-4 achievement bullets, not a paragraph of adjectives
3. Skills	Grouped by category, not a flat list
4. Experience	Company blurb (1-3 lines) + 3-5 bullets per role
5. Education	Reverse chronological
6. Links	GitHub, Tableau Public, portfolio

Read: the free Tech Interview Handbook resume guide, which I have shared twice, and The Tech Resume, a book by a former Big Tech HR that mikhail_sh2488 found useful.

Two notes on this order:

• Skills placement is not settled. I usually tell people to put skills after the summary. One reviewer told a candidate to put skills at the very top instead.

  “Hey Maxim! So good resume, the only thing - I usually have technical skills on the top, but not sure what is the best practice- for me it worked.”

  Both work. Pick one and be consistent.
• Group your skills section. Do not list tools in one flat line. Group them: Programming languages, BI, Cloud, Data Platforms, Orchestration. This is the single rule I repeat in almost every review I do.

  “1. I agree with Dmitry that it would be better to leave only 3-5 key points for your most recent experience…
  2. I would structure Skills section:
  Programming languages: SQL, Python
  BI tools: …
  Cloud platform: …
  It will be easier to read”

Weak:

Skills: SQL, Python, Tableau, Snowflake, dbt, Airflow, AWS, Git, R, Looker

Better:

Programming languages: SQL, Python, R
Cloud & Warehousing: Snowflake, AWS, BigQuery
Transformation: dbt, Airflow
BI: Tableau, Looker

Other rules I enforce on structure, every time:

• Company blurb: 1-3 lines. State the niche, size, and what it does. Skip adjectives.

  “Provide short description of your project and your role in it. 3 lines max. I’d not use lots of adjectives like pivotal”

• No brackets around dates: write Dec 2021 – Current, not [Dec 2021 – Current].
• Include the month for the last 5-10 years of work history. Don’t hide dates by year only.
• Drop soft-skill bullets like “communication” or “problem-solving.” They are not searchable and not verifiable. Show the same thing through a quantified achievement instead.
• Cut connecting words. Facts only.

  “you don’t need to tell a story here, just leave facts, don’t use connecting words”

Lesson 2.2 — Bullets that work

Spend most of your time on this lesson.

After unfocused targeting, the thing I flag most is a bullet that describes a task with no outcome.

“even 45 features is like vanity metrics… 45 features not clear 0 what is it? metrics, charts? dashboards?”

“You need the result (in % or $ or time) almost in every point.”

I teach three formulas in the channel. Learn all three. Use whichever fits the bullet.

Formula 1: XYZ

Accomplished [X] as measured by [Y], by doing [Z].

Read: this XYZ resume format guide. Anna and I shared it three times between us.

Worked example, from a real rewrite (annatimoshenko_, 2024-08-15):

Before	After
Assisted new employees in training in data analysis.	Accomplished a 20% improvement in new employees’ data analysis proficiency, as measured by post-training assessments, by developing and delivering comprehensive training sessions.

The before sentence describes an activity. The after sentence names a result (20% improvement), names how it was measured (post-training assessments), and names the action (developing and delivering training sessions). Use all three parts every time.

Formula 2: TMTS — Time, Money, Team, Scope

Use this when you cannot find a percentage. Pick whichever of the four fits your work:

• Time: “Recruited over 500 staff in ~24 months”
• Money: “Saved $1.2M in agency fees”
• Team: “One of 5 Managers… leading recruitment in Canada”
• Scope: “Grew service from 1-5 provinces in 18 months”

I shared all four of these examples myself, from a “6-figure résumé” post I found and passed along to the channel.

Same source, three vague-to-specific rewrites:

Vague	Specific
Conducted complex data analysis	Analyzed over 20,000 data points from 1,500 participants
Led a cross-functional team	Led a team of 7 people across Marketing and Analytics
Significant improvement in sales	Grew sales by 12% in 3 months

Formula 3: The four-part branding statement (for your summary)

[Years of experience] + [Roles or responsibilities] + [Organization size and scope] + [A metric related to your field]

This is a rule I have handed out directly in review threads:

“Your résumé/LinkedIn branding statement should NOT be like this: ‘Dynamic and results-driven professional with a proven track record of fostering strong stakeholder relationships. Committed to driving organizational success through strategic execution exceptional service delivery.’ This type of content is: Generic / Uninformative / Commonly generated by AI. Instead, try this 4-step formula: [Years of experience] / [Roles or responsibilities] / [Organization size and scope] / [A metric related to your field]. Example: ‘[10+ years experience] in [agency and internal recruitment including leadership roles] at [global tech firms valued at $1B+ with up to 2,000 employees]. [Hired 700+ professionals across tech, business, and clinical roles]’”

If your summary could describe five other people, rewrite it with the four-part formula.

Watch: this video on value proposition I shared in 2026. Define your value, double down on direct experience, go top-down, and make it easy for someone to say yes.

Real before/after rewrites from the channel

These are real bullets that I and other reviewers critiqued, with the fixes. For an outside example, see how Nick Singh improved an exemplar resume (a free lecture in his course).

Before	Critique	After
”Drove the implementation of comprehensive business intelligence solutions"	"what tool? What is the impact? how many users? what was Data warehouse” — dimoobraznii_91655 (me), 2024-03-05	Name the BI tool, the warehouse, the user count, and the result. A vague verb plus a vague noun is not a bullet.
”Developed a reverse ETL system to manage 250+ HubSpot CRM properties"	"mentioned with what? OSS or vendor or Python?” — dimoobraznii_91655 (me), 2024-06-08	Name the tool. “Built a reverse ETL pipeline with [tool] to sync 250+ HubSpot CRM properties, cutting manual updates by X hours/week."
"Enhanced the corporate website by visually optimizing solution”	Solution stated with no result attached	”Enhanced the corporate website by visually optimizing [specific change], which reduced load time by 70%.” — tsebek, 2024-01-17
”Initiated SQL and Python code review”	Task, not outcome	”Implemented a CI/CD pipeline using GitHub Actions/Azure DevOps” — tsebek, 2024-07-14

Here is a full review I did, section by section, so you can see a whole review and not one bullet at a time:

“Things I would change:
Summary: instead of ‘interested’ write that you are expert and implemented BI (tools list) in different organisations and worked close with ML, DE, Product and so on.
Side bar: you don’t need it. Instead make the section under summary with skills and multiple bullet points like ‘BI’, ‘ETL’, ‘Cloud’, ‘Data Platforms’, ‘Coding’, ‘DevOps’.
Add more text in what you did as BI engineer, ask chat gpt for popular cases, highlight the tool, data warehouse, etl. You need more tools across the CV.
Overall, better use text vs PDF like Google Doc, it is fine to share with the PDF, but good to edit with text simple layout.”

Every fix, mine or anyone else’s, does three things: name the tool, name the action, name the number. A bullet missing any one of the three gets sent back for a rewrite.

Here is what the target density looks like once you have it, from a real BI Analyst rewrite:

“Built Snowflake data warehouse pipelines using Fivetran and dbt, cutting manual reporting time by 40%…”

Tool (Fivetran, dbt) + action (built pipelines) + result (40% less manual work), in one line.

Lesson 2.3 — Finding a number when you think you have none

The excuse I hear most is “I don’t have a number for this.” You almost always do. Three ways to find one:

1. Count something you already know. Rows processed, dashboards built, users served, reports automated, hours saved per week. If you built 12 dashboards, that is a number.
2. Compare before and after. Query time before your change vs. after. Manual hours before automation vs. after. Even a rough estimate (“about 3 hours a week down to about 30 minutes”) beats no number.
3. Use TMTS as a checklist. If you cannot measure the money or the time, measure the team size or the scope. Every piece of work touches at least one of the four.

If you cannot reconstruct a number, say so to your reviewer and ask for help estimating one from the description of the work. Do not leave the bullet as a bare task description.

Lesson 2.4 — Format rules I enforce

These are non-negotiable in the review channel. I have said each of these in roughly 10 threads.

• Google Doc for review, PDF for applications. Post your resume as a Google Doc link in #resume-review, with comments open, so reviewers can leave notes next to each bullet. When you apply for a real job, send a PDF exported from that same Google Doc (File → Download → PDF). A PDF made from a text document is easy for ATS systems to read. A PDF made from an image or Canva is not.
• No Canva. No image-based resumes. If your resume is a picture, an ATS cannot read it. Rebuild it as real text.
• No two-column layouts. They break ATS parsing and slow down human readers.

  “I’m not sure about the 2-column layout; I’ve seen recommendations advising against it.”

• Use a simple, single-column, text-based template. Do not use a branded internal-consulting template built for client presentations.
• Reference template: “Jake’s Resume,” a LaTeX template on Overleaf, widely used in tech resume circles. Use it as a format reference even if you build the final doc in Google Docs for review.

Template: our community resume template in Google Docs. Take it and update yours.

Watch: a very good and clean way to do a resume.

Read: this LinkedIn post on how recruiters scan a resume. The comments from HRs are the interesting part.

Lesson 2.5 — The length disagreement

People in my own channel still disagree on this. Do not treat it as solved.

Position 1: one page. This was the early and default norm, and it is still the norm in some countries.

ayse_45552 (2024-01-24): one page unless you have 5+ years of experience.

Position 2: two to three pages. I overturned the one-page rule myself, for my own resume and for others. Iakubovskii7 challenged me on exactly this, about my own resume:

“But I have one question Your resume has 3 pages but I know that it must have only 1 page”

My answer:

“2 is fine” / “I know this is RU thing about 1 page”

I personally use a 3-page resume. The “6-figure résumé” template I shared with the group also runs 3 pages.

What decides it: years of experience and the market you are targeting. Early career, or in a market where one page is the norm, one page still reads as normal. Mid-to-senior, especially in Canada or the US, two to three pages is accepted and sometimes expected. The content has to earn the extra length. Choose based on how much verified, quantified experience you have to show. Do not pad a one-page resume to two pages with restated content.

Lesson 2.6 — Regional tailoring: the western stack rewrite

If most of your experience is with on-prem or local tools, expect this note from me:

“I assume you all experience with On-premise that is highly desirable in Russia. But in Europe is is AWS/Azure/GCP, you may think about adding a copy of ‘west’ resume”

I have raised this in 15+ threads, more than any other regional point. Do not fake new skills. Build a second, parallel resume that describes the same work using cloud-market vocabulary:

Local / on-prem term	Cloud-market term
On-prem SQL Server / SSRS	Cloud data warehouse (Snowflake, BigQuery)
ClickHouse	Snowflake / Databricks
Legacy ETL scripts	dbt models, orchestrated with Airflow
In-house BI tool	Tableau, Looker, Power BI

The work stays the same. Only the words change to ones the hiring manager recognizes.

Other regional points to handle deliberately:

• Legal status placement. Canadian HR asks about work permit status early and often.

  “HR always ask what your legal status in Canada, if you are holding work permit, they ask when it is expiring”

• Relocation signals. If you are relocating, state it clearly rather than leaving the reader to guess from your address. I wrote more on this in From relocation to employment.
• Naming a current employer that reads as a geopolitical risk. I have seen this come up, and I have no fixed rule for it. Decide whether naming the employer helps or hurts this specific application. Do not default either way.

Lesson 2.7 — Tailoring per application

Keep 4-5 stack-specific resume variants ready (for example: DE-GCP, DE-Python, AE-Snowflake). Do not rewrite the whole resume for every job posting. Keep them current after you get hired too, because job security does not exist and the next good posting will not wait for you to update your resume.

Nikita shared his whole process in June 2025:

I also have 3 additional variations:

• Data Engineer (GCP)
• Data Engineer (Python)
• Analytics Engineer (Snowflake)

I don’t spend much time on tailoring them, just send one of the versions. […]

• ~10% current conversion from application to interview
• Spend ~20 min/day on job search

What to change per application:

1. Only the summary. Mirror the job description’s wording in your 2-4 summary bullets. Vianvong planned to do the same thing for his skills section:

   “In the skills section, I have indicated what I have worked with in the past. I plan to update this information every time by simply copying it from the job description.”

2. Read 10-15 job descriptions from strong companies before you write your summary variants, to learn the vocabulary they use.
3. Skip cover letters. I am blunt about this.

   “Cover letter is useless… I don’t think anyone has time to read it. Every job application has 500-1000 applicants.”

4. Submit in under 10 minutes. If tailoring is taking longer than that, you are rewriting instead of swapping in a prepared variant.

Lesson 2.8 — ATS and scoring tools

Two tools people use to sanity-check a resume before submitting: Resume Worded and Jobscan. If ATS is new to you, read the Jobscan guide to ATS resumes and TopResume’s explainer on what an ATS resume is first.

I want you to use them, but with a caveat one of our own members raised:

“they have some good pieces of advice there but sadly some their recommendations are just bullshit so I wouldn’t trust their”

Treat the score as a rough signal. Do not rewrite bullets only to raise it. The hiring manager is the one you need to convince.

One more point, about where your resume lands:

“Company’s Applicant Tracking System (ATS): As you mentioned, many companies prioritize internal career sites because they’re often directly integrated with their ATS. This means recruiters and hiring managers may have quicker, more structured access to applicants who come through their own portal.”

Teal HQ came up twice as a question and I never confirmed it was worth using. Treat it as unendorsed.

Lesson 2.9 — Getting your resume reviewed

Here is how the review works. I ran it:

1. Post your resume as a Google Doc link, not a PDF.
2. Reviewers comment inline, bullet by bullet.
3. The most useful reviews name the specific problem: missing tool, missing number, unclear role. “This is vague” is not useful feedback. “What tool did you use for this ETL job?” is.
4. Post a revised version after applying feedback. I check whether the fix landed.

When you ask for feedback yourself, ask specific questions: “Does this bullet have a clear result?” gets you a better answer than “What do you think?”

Here is what a review looks like in practice. A member posted this Data Engineer resume as a Google Doc in July 2025. Names and contacts are blurred. The comments on the right are mine and from other members:

Notice what the comments ask for. Nothing is “this is vague”. Each one names a fix:

• No education section. Add one, even if it is short.
• No GitHub link. Add the repo from Module 3.
• The summary is a paragraph. Convert it into bullets so it is easier to scan.
• The 2021 role has two bullets. Add Snowflake and dbt experience there, and more interesting points in general.

The resume is already strong on numbers: cost savings, percentages, record counts. That is why the review is about gaps, not about rewriting bullets. Get your bullets to that level first, then post.

Before you post, run your resume through our checklist for fixing your data resume. It catches the common problems, so reviewers can spend their time on the harder ones.

Inflating experience: what people in the community say

Some members, including me, say it openly: in today’s market, an honest resume is often not enough to get a first job or a step up. So they add to their experience. Below is what was said, in their own words. I am not telling you to do it, and I am not telling you not to. You decide.

“Unfortunately, in current market, it’s almost impossible to find a first job and being honest.”

“fake it in your resume”

“The problem is that they care more about your experience than real skills and impact. So just fake it like Dima said”

“I will change the experience and start applying for middle positions. I guess there is no other way except ‘fake it till you make it’”

What people talk about doing: adding a year or two of experience, listing tools they have learned but not yet used at work, covering gaps between jobs, and listing our community’s consulting company as a past employer.

This is not one person’s opinion. It has come up again and again in our channels, and the people saying it are some of our most experienced members, me included.

Action items

• Pick five bullets from your current resume that describe a task with no result. Rewrite two with XYZ, two with TMTS, and the fifth with whichever formula fits best.
• Check each rewrite has a tool, an action, and a number. Where you cannot find a number, write down which of the four TMTS categories you tried and why it did not work. Bring that note to review.
• Rewrite your summary as 2-4 bullets with the four-part branding formula, for one target role from Module 1.
• Regroup your skills section into categories: Programming languages, BI, Cloud, Data Platforms, Orchestration.
• Decide your page length (one page, or two to three) based on your years and target market. Write down why.
• If your experience is mostly on-prem or local tools, build a cloud-stack variant of the same resume.
• Move the resume into the Google Doc template and post it, with before and after versions of your five bullets, for review. Post the revised version after you apply the feedback.
• Keep searching: update the resume the week a project ships, with the tool and the number while you still remember them. Do not wait for the week a layoff hits.

More resources

• GitHub’s guide to the profile README, for the Links section of your resume. Step 5 shows what to put in it.
• An example of a resume hosted on GitHub. I know this person.

Time to complete: 1 to 2 weeks, on top of your existing work

You finish this module with:

• A public GitHub repo. With a README a recruiter can understand in 30 seconds.
• 3 to 5 resume bullets. Taken from the project, with numbers.
• One 20-minute project story. You can tell in an interview without notes.
• A GitHub profile page. Your role, your project pinned, your links.

Why this module exists

Your resume says you can do the work. A project lets someone check that. A certification mostly does not, because nobody looks at it:

“No one really check it.”

I hold five AWS certifications myself. Four are expired. I now tell people to build projects instead of chasing more certs.

“Pet projects are great, since you are not able to show your commercial work.”

Your employer’s code stays private, so a project you built yourself is the work you can actually show.

Lesson 3.1 — What makes a project count

Most job seekers build a notebook. A notebook has no pipeline, no structure, and nothing a recruiter can click through, so it does not count.

A project that counts has:

• Real data moving from a source to a destination
• A clear structure a stranger can follow
• At least one transformation step that shows judgment, not just a SELECT *
• A result you can state in one sentence

If your project is one Jupyter file with charts at the bottom, it will not hold up in an interview. Build something with stages. For a small example, see my local data platform with Docker Compose, Jupyter and Airflow.

Lesson 3.2 — Use the medallion pattern

I tell everyone to use the medallion pattern: Bronze, Silver, Gold. It gives you structure without you having to invent one.

• Bronze: raw data, landed as-is. No cleaning yet.
• Silver: cleaned, deduplicated, typed correctly. This is where you fix messy source data.
• Gold: aggregated, business-ready tables. This is what a dashboard or report reads from.

Read: the Databricks medallion architecture glossary explains the pattern in depth.

If you build with dbt, use incremental models to move data between layers instead of rebuilding everything each run. The official dbt docs on incremental models cover the strategies: DELETE+INSERT, MERGE, and others. Naming your folders bronze/, silver/, gold/ is enough to signal you know this pattern before anyone opens a single file.

Lesson 3.3 — Start from my project repo

Do not start from a blank folder. Start from github.com/surfalytics/data-projects. I built it, and I keep pointing people to it.

“This doc should help to prepare for DE system design interview. Just follow the steps. You need some pet projects as well to know the options.”

It is the most-shared link in the whole community. I have shared it 7 or more times myself over three years. It is the path I want members to follow from beginner to job-ready. It has:

• DE-specific projects (de-projects/) to learn Snowflake and dbt, including a dbt-core + Snowflake project
• An end-to-end dbt + Looker project, which I recommend repeatedly as a next step after a first project
• A BI-admin-with-Tableau project
• A Looker + Snowflake BI project
• A Spark project with a test framework

When I review someone’s resume, this is usually what I point them to next:

“I’ve added comments. Also, think about next projects;

• admin BI [link]
• Looker or Tableau
• dbt [link]”

Pick one project template that matches your target role from Module 1. Do not pick five and finish none.

For a member’s version, see Ksenia’s BigQuery + dbt + Looker project. She kept updating it based on feedback from the community.

Lesson 3.4 — Write the README so a recruiter gets it in 30 seconds

A recruiter will not read your code. They will read your README for 30 seconds, then decide whether to keep looking.

Structure it in four parts, in this order:

1. Problem: one or two sentences. What question does this answer, or what pain does it fix?
2. Stack: the tools, named plainly. “dbt, Snowflake, Airflow, Python.”
3. Architecture: a short description or diagram of Bronze → Silver → Gold, or your pipeline’s shape.
4. One measurable result: a number. Rows processed, query time reduced, a dashboard built from N sources. Pick one and state it plainly.

Do not write a wall of prose. Use headers and short lines. The reader is scanning.

Lesson 3.5 — Turn the project into resume bullets and interview stories

Once the project exists, mine it for two things.

Resume bullets. Use the tool + action + quantified outcome formula from Module 2. Example shape: “Built an end-to-end dbt pipeline (Bronze/Silver/Gold) processing 2M+ rows, reducing manual reporting time from 3 hours to 10 minutes.”

One interview story. Pick the hardest decision in the project, such as a data quality issue you had to handle, a modeling choice you had to defend, or a performance problem you fixed. Practice explaining it out loud for 20 minutes: what the problem was, what you tried, what you chose, and why. This is the story you tell when someone says “walk me through a project.”

I have seen a project carry an entire interview. One member’s Formula 1 pet project became this kind of story. In a live interview, the interviewer turned out to be an F1 fan, and they spent 7 to 10 minutes discussing the project on shared screen.

“Just had technical interview with CTO for the position Data Analyst… I could see that I answered some of his questions beforehand (thanks to Dima for the mock interview and recommendations).”

The member credited the project for a strong impression. The shared hobby was luck, but they still needed a project detailed enough to talk about for that long.

Some members go further and record the whole interview walkthrough, so they can reuse the explanation next time:

“I had interview for Sr DE. The project is migration of Redshift to Snowflake with dbt. I did record of the video… Overall, wasn’t complicate because I know more than they.”

You want that level of comfort with your own project story. Know it better than the person asking about it.

Lesson 3.6 — Post it publicly

A private repo helps nobody find you. Post the project publicly: GitHub, a personal blog, LinkedIn, a Telegram or Discord channel you’re active in. Keep posting after you get hired, because job security does not exist and the only answer I know is to keep studying, networking and building your personal brand.

Before you share the link, set up your GitHub profile page so it explains who you are. Lesson 3.7 shows how. For a personal site, avsemddm shared this engineering portfolio as inspiration, though it may be stale.

“‘modern tools not only fun but usually companies understand the value of data team and compensated well’ at this case i see only way to obtain position (in Canada 🙂 for ‘modern stack’ learn->pet project->short post about project in linked in with link to same online dashboard and link to GitHub code (‘Personal brand’ 🙂 as you calling it 🙂).”

The most dramatic outcome in the whole community started here. One member (olelle8) shared a baby-tracker dataviz project on a personal channel. A friend saw it and made a referral to Motorola. Result: 7 applications, zero screening interviews, one offer. Project, then network, then referral, then offer, in under a month.

I cannot promise you that chain. It only started because the project was public and not on a laptop.

Lesson 3.7 — Your GitHub profile page

Your resume links to github.com/your-name, not to your project. That profile page is what a recruiter opens first. If it is a list of tutorial forks and half-finished repos, your project gets lost in it.

Fix that in one evening with a profile README. Create a public repo named exactly like your username, for example jane-doe/jane-doe, and add a README.md. GitHub shows that file at the top of your profile. GitHub’s guide: Managing your profile README.

Keep it to about 10 lines:

• One line with your target role from step 3, and your stack. “Analytics Engineer: dbt, Snowflake, SQL.”
• Your project from this module, with one sentence on what it does and its result.
• Where to reach you and see more: LinkedIn, Tableau Public, a blog.

# Hi, I'm Jane Doe

Analytics Engineer: dbt, Snowflake, SQL, Looker.

- Project: [Retail sales pipeline](https://github.com/jane-doe/retail-dbt) —
  Bronze/Silver/Gold models in dbt, 2M rows, a Looker dashboard on top
- LinkedIn: [linkedin.com/in/jane-doe](https://www.linkedin.com/in/jane-doe)
- Dashboards: [Tableau Public](https://public.tableau.com/app/profile/jane.doe)

Then clean up what sits under it:

• Pin your project and one or two other good repos, so they show first. GitHub’s guide: Pinning items to your profile.
• Delete old tutorial forks and archive repos you will never finish. A fork of a public repo cannot be made private.
• Skip the badge walls and GitHub-stats widgets. They take up the first screen and say nothing about your work.

For a member’s version, see Nikita’s GitHub profile: role line, LinkedIn, a featured dbt project, certificates and articles.

Action items

• Clone one project from surfalytics/data-projects that matches your target role from Module 1. One, not five.
• Build it end to end with bronze/, silver/ and gold/ folders and at least one real transformation step.
• Write the README in four parts: problem, stack, architecture, one measurable result. Ask someone to read it for 30 seconds and tell you what the project does.
• Make the repo public and share it in at least one place where people who know you will see it, for example a LinkedIn post with the GitHub link.
• Create your profile README with your target role, your project and your links, and pin the project on your profile.
• Write 3 resume bullets from the project with the tool + action + number formula from Module 2.
• Pick the hardest decision in the project and outline a 20-minute interview story about it. Post the outline for peer review, then say it out loud once.
• Keep searching: make one public commit or one post about your work every month, even after you land the job, so your GitHub never looks abandoned when a recruiter opens it.

More resources

Members shared these. None of them replaces a finished project.

• Google Data Analytics Professional Certificate. I recommended it for business and metrics knowledge.
• dbt bootcamp on Udemy, from Nikita’s weekly study log.
• My take-home assignment solutions, as examples of how to structure a take-home, including system design write-ups.
• Nikita’s dbt take-home project: Kimball modeling, a SQL refactor, and dashboard feedback.

Time to complete: 1 week to set up the routine, then ongoing every week

You finish this module with:

• A written targeting filter. What you apply to and what you skip.
• A filled tracker. Every application, its status and its date.
• A referral outreach process. Who you ask, how, and when you follow up.
• A weekly routine. You can run for three months without burning out.

Why this module exists

Most job search advice tells you to do more. Apply to more jobs, send more messages. I watched this play out in our community, with people tracking their own numbers week by week. The data says the opposite of the advice. Volume is the weakest strategy I have seen measured. Targeting and referrals beat it by a wide margin.

This module gives you a weekly routine to run instead of grinding volume.

Lesson 4.1 — The conversion table

Three people in our community tracked their numbers, for months, in public, in #job-searching-and-interviewing.

Strategy	Who	Applications	Interviews	Conversion
Referral-first	makseshina	32	11	34%
Tight targeting	Nikita (nikita_volynets)	61	13	21%
High volume	tsebek	200+	~14	~7%

Look at what volume bought tsebek: roughly the same number of interviews as Nikita’s tight targeting (14 vs 13), for more than three times the applications. Makseshina got almost as many interviews as Nikita from half the applications, because most of hers came through referrals.

More applications is the worst of the three strategies, and it’s the one your gut reaches for. When a search stalls, the instinct is “apply to more.” That instinct pushes you toward the strategy that converts least.

Lesson 4.2 — What tight targeting looked like

Nikita applied to 61 positions over four months, January to April, and got 13 interview invitations. He posted his own numbers:

“I checked my statistics. From January to April (4 months) I applied to 61 positions and received 13 invitations to the interview. It means that I applied only 3-4 positions per week and my conversion to invitation for the interview is 21%.

It’s because I targeted only specific positions with the following criteria:

1. BI/Analytics/Data Engineer with the following data stack: DBT/Snowflake/Looker or similar. I didn’t apply for analysts positions or for pure Data Engineering positions with Azure/AWS/GCP stack.
2. Remote only
3. Salary from 130k CAD (if the salary in JD was lower I didn’t apply)

I made only one really good resume and applied to all positions with this resume. Also, I applied without any references but I monitored positions every day. I did’t spend time on Cover Letter and where possible I never included it.”

His three filters, all applied together:

• One stack only: dbt, Snowflake, Looker. He skipped roles outside this stack even if he could technically do them.
• Remote only.
• Salary floor: 130k CAD. No applying below it.

And three things he skipped:

• No cover letters.
• One resume version, never tailored per application.
• No referrals. This was pure targeting, without the referral boost.

Nikita did his targeting with the filter, not with the paperwork. If you are burning hours polishing each application, that time is probably better spent tightening your filter instead.

Lesson 4.3 — What referral-first looked like

Makseshina’s approach: get a referral before applying, almost every time. In her own words:

“The explanation is very simple. I try to get a referral to every position I apply for. And very seldom apply without it (because otherwise, the conversion rate for me is almost zero). 11 interviews = 6 with referrals + 3 from recruiters and HM found me on LinkedIn + 1 cold apply but with a good hometask (there was an unusual process when you need to answer several questions at the very beginning) + 1 cold apply So, you see, from these 11 interviews, I got only one by applying without any support. And that was a year ago, at the beginning of my career break, so now I don’t believe at all that someone will choose me just in the bulk of other’s CVs.”

Six of eleven interviews came through a referral. That’s over half her results from one channel, and she says it herself: a cold CV in the pile barely worked, even once.

Lesson 4.4 — How to actually get a referral

“Get a referral” is not a plan. Here is what it looked like for people in our community:

1. Post your project publicly first (Module 3). The strongest referral chain I’ve seen started when a friend saw someone’s portfolio project on a personal channel and referred her. Seven applications, zero screening interviews, one offer.

2. Ask inside communities you’re already in, not strangers. Job-search Discords, dbt Community Slack, alumni groups. People refer people they’ve seen contribute, even a little. That’s you, in here.

3. Message the hiring manager directly, not the recruiter. Yury found the Head of Data’s LinkedIn profile, saw she was a dbt enthusiast, and messaged her about his own dbt projects instead of applying cold:

   “Here’s how I did it: I found the Head of Data at the company, checked her profile, and discovered that she’s a big fan of dbt. I messaged her about my dbt projects, shared her enthusiasm for the tool, and explained why I’m a perfect fit for the role. She arranged an interview directly. LinkedIn Premium showed that around 1000 people had applied for this position.”

   That’s an interview skipping roughly 1,000 other applicants who went through the normal queue.

4. Lead with a shared interest, not a request. Yury’s message was about dbt, a thing they both cared about, not “can you refer me.”

5. Ask people at your target companies specifically, not your whole network generically. A referral only works if the person is inside the company you’re applying to.

6. When someone does refer you, follow up fast and make it easy for them. Send your resume and the job link in one message, ready to forward.

Referrals are the highest-converting channel in our own data. Treat asking for one as a core weekly task.

Lesson 4.5 — Avoid the title parity trap

In June 2024, alexg7ag searched LinkedIn Canada for “Analytics Engineer” and got 27 listings. The same search for “Data Engineer” returned 300 to 470. Many of the same jobs sit under both titles. Only the search title changed, and the visible pool changed a lot.

Don’t search by job title alone. Search by tool pairs instead: “SQL” + “dbt”, “SQL” + “Snowflake”. The role you want hides under titles like BI Analyst, BI Developer, Sr Data Analyst. If you only search your exact target title, you miss most of the market.

Lesson 4.6 — Seasonality is real

There’s a dead zone in hiring, roughly December 10 to January 20. Interview volume drops hard in this window. I’ve seen this from the recruiter side too. Yury talked to a recruiter he knew and asked directly why the market felt so dead:

“I’ve just talked to a recruiter, he seemed like a nice guy, so I’ve decided to ask him details about why the market is so dead right now. Here are some of the insights:

• In Canada some really big projects got shut down in recent months, teams were layed off, a lot of candidates are looking for new options
• on the other hand, some companies have budget leftovers, they’re still looking for workers, this somehow levels the situation
• still, the economy is slowing down, less vacancies
• Dec 10 - Jan 20 is the dead period, very little number of interviews are conducted
• he’s hoping, the market will start growing in Feb”

Don’t read a quiet December as your resume failing. It’s the market. Hiring picks back up in spring and fall. If you can, save your highest-effort pushes (a new resume launch, a big outreach round) for those windows instead of the holidays.

Lesson 4.7 — Apply within the first hour

Apply the same day a posting appears, ideally within the first hour. Later applicants land in a much larger queue as more people apply over time. Pair a fast application with a short, personalized message to the recruiter, not a form cover letter. Write one specific line about why this role.

Lesson 4.8 — Go direct, not Easy Apply

I said this to the whole community and I still believe it: applying directly on a company’s website, or reaching a hiring manager directly, beats LinkedIn Easy Apply.

“@everyone ⚠️ I think we should stop using LinkedIn for submitting applications, especially the ‘Easy Apply’ option. Instead, we should go directly to the company website and apply there.

My hypothesis is that LinkedIn is too accessible to recruiters, and they may not thoroughly check applications that come through it, as they also receive a significant number of applications directly from the company’s website.

PS: This totally depends on the integration between LinkedIn and the company’s HR system, but I assume the internal career site has a higher priority.

What are your thoughts? Answer in 🧵”

Avsemddm replied with the same instinct from her own habits:

“I’ve never used the Easy Apply button, to be honest. I usually click ‘Apply,’ which redirects me to the company’s website, or I apply directly on their site. […] From what I know, many big companies use Workday, which compiles a massive list of candidates from various sources (internal and external). They can filter this list based on specific criteria.”

The clearest proof is still Yury’s story from Lesson 4.4: a direct message to a hiring manager beat 1,000 applicants in the normal queue. Easy Apply is high-volume and easy for a recruiter to ignore. A direct application signals more intent.

Lesson 4.9 — Tools that work, and tools that don’t

Worth using:

Tool	Use
hiring.cafe	Aggregates postings from company career pages directly, infers salary with AI
dbt Community Slack, jobs channel	Best source specifically for Analytics Engineering roles
wellfound.com	Startup job board; useful for one member’s senior contract role, mostly US-resident-friendly
levels.fyi	Compensation research
Apollo.io	Finds recruiter and hiring-manager emails for direct follow-up after applying
A plain spreadsheet or Notion	Tracking applications — the most-endorsed tool by a wide margin

Tried and rejected by the community:

• Teal HQ: widely judged not worth paying for
• finalroundai.com: US-only, no Microsoft Teams support
• simplify.jobs: limited or no reported benefit
• LinkedIn Premium: not worth it outside hiring season

I’ve seen this many times: people pay for job-search products and are disappointed. What moved their numbers was a rewritten resume and a tighter filter, not a subscription.

Lesson 4.10 — Personal brand as inbound

Some interviews come to you. Three of makseshina’s eleven came from recruiters and hiring managers who found her on LinkedIn, not the other way around. I keep saying this out loud, because people don’t want to hear it:

“this is the point about Job Security. It is not exists, you need to study more and build your networking and personal brand by writing posts, commit to git and be active here and in Linkedin. Otherwise you are in higher risk.”

The method is public, ordinary work: writing about dbt and SQL, keeping GitHub activity visible, posting on LinkedIn. It’s the same “post it publicly” principle from Module 3, stretched from one project into an ongoing habit. It costs time, not money, and it keeps working while you’re not actively applying.

Read: this LinkedIn profile checklist before you start posting. Annatimoshenko_ also pointed members to their LinkedIn SSI, LinkedIn’s own score for your profile activity.

Nikita treats his own search the same way, even when he’s not job-hunting for real:

“I’m always in a passive job search — if recruiters reach out, I’m open to talking. But my bar is high: I’m only considering fully remote roles with a 180k+ CAD salary because I already have a good income.

Every 6 months I do an active job search to practice interviews, update resume, check what skills are in demand, and see if I can get a higher compensation. In today’s market, it’s important to stay in interview shape, so if a layoff ever happens, you can find a new job quickly.”

This is the one rule of this course, not a side note: never stop searching, even after you land your next role. Stay visible and do an active round every six months, like Nikita, because the search is a skill that fades without use, and a better job might exist right now.

Lesson 4.11 — The weekly routine

Run this every week during an active search:

• Application target: a fixed number, chosen from your targeting filter (stack, location, salary floor from Module 1 / Lesson 4.2), not from a volume instinct.
• Outreach target: a fixed number of referral asks or direct hiring-manager messages.
• One practice session: a mock interview or a solo drill (Modules 5 and 7).
• One learning block: closing a real skill gap, not busywork.
• Tracked: every application, referral ask, and outcome logged in your spreadsheet or Notion.

Aysek4460 shared a tip worth stealing for how you triage postings before applying:

“one more thing, maybe you already do this, but still lemme tell you. first look at the jobs and save the convenient ones for you, after that start to apply like machine”

So collect the postings you want first, then apply to all of them in one block. If you mix browsing and applying, browsing takes the whole day.

Set the numbers low enough to sustain for three months. If you drop the routine in week three, you get nothing from it. A smaller routine that you keep gives you more.

Action items

• Write your targeting filter in one sentence, like Nikita’s: one stack, one location rule, one salary floor.
• Set up your tracker (spreadsheet or Notion) with 5 columns: company, role, source (referral / direct / job board), date applied, status.
• Name 3 people, in your network or in communities you’re part of, who could refer you to a target company. Draft one message to each, leading with a shared interest, not a request.
• Send at least 1 of those referral asks this week, and log it in the tracker.
• Join the dbt Community Slack and save 2 searches by tool pair (for example “SQL” + “dbt”) on hiring.cafe or LinkedIn, not by job title.
• Write your weekly routine with real numbers: application target, outreach target, one practice session, one learning block. Pick numbers you can keep for 3 months.
• Keep searching: keep the tracker open after you sign the offer. Log at least one recruiter conversation a month, even when you’re happy at work, and do one active round every six months, like Nikita.

More resources

• dataengjobs.com: a data jobs board, shared by tonya9262.
• Data Engineering Jobs on LinkedIn: a LinkedIn page that posts DE openings, also from tonya9262.
• LinkedIn “Top Choice” help page: how the feature works. Olelle8 doubted it helps much.

Time to complete: 6-8 hours, spread over a week or two

You finish this module with:

• Written answers to the 20 questions most likely for your target job. You generate them with AI from a real job description.
• Three behavioral stories in STAR form. Situation, task, action, result.

Why this module exists

You can be strong technically and still lose. I’ve seen it happen in our community again and again, and it’s happened to me.

One member got through a full interview loop at KOHO in February 2025, looked like a strong fit, and was still rejected. Looking back, the reasons were clear: the dbt answers were too vague, and the candidate and the interviewers used different words for the same things.

“there are many DE jobs but even if you are fit 100% and solve 100% interview nothing guarantee”

What separates offers from rejections is preparing for each type of round, and especially for the behavioral one. This module covers both.

Lesson 5.1 — How an interview process usually goes

Most interview processes have 3 to 6 rounds. Some have more. The order changes from company to company, but the shape is usually the same:

1. A screening call with a recruiter
2. Sometimes, a recorded video or AI interview
3. A round with the hiring manager
4. One or more technical rounds
5. A final round with senior leadership or business stakeholders

Here is a real example. After a member’s recruiter call at Wealthsimple, the recruiter laid out the rest of the process:

“Next Steps:

1. Hiring Manager interview (30 min)
2. Technical Loop:
   • SQL coding test (1 hour)
   • Technical problem-solving interview (1 hour)
3. Final interviews with senior People leadership (2 interviews - 30 min each)”

Big companies add more rounds. Mikhail’s Stripe process had a recruiter screen, a technical interview, and then a set of five interviews of 45-60 minutes each. Small companies and referrals can skip steps. Olelle8 was referred for a Data Visualization Engineer job and “didn’t have any screening interviews”, only a talk with the director of the division.

Expect the whole process to take a few weeks to two months. Ask the recruiter in the first call what the next rounds are and how long each one takes. Most recruiters will tell you, and then you know what to prepare.

Recruiter screen

Who gets it: almost every role.

A 15-30 minute call. The recruiter checks that you match the job on paper and that nothing blocks a hire: your experience, why you want this job, salary, work permission, location, and notice period. A member’s recruiter screen at Granum is a typical list:

“There were no deep technical questions. The main questions were:

• Can you walk me through your experience?
• […]
• What recent project are you most proud of?
• Which technologies are you most comfortable with?
• Why are you interested in this company and role?
• Why are you considering leaving your current position?
• […]
• How do you use AI and agentic workflows in your work?
• […]
• Are you able to work Eastern hours?
• Does the posted salary range meet your expectations?”

Your answers may be scored by AI, not only by the recruiter. More and more recruiters run an AI note-taker on the call. It records and transcribes what you say, and some tools also score your answers against the job description. The recruiter may only read that summary later, together with the hiring manager. So answer for both of them:

• Use the exact words from the job description. Say “dbt”, “Snowflake”, “Airflow”, “stakeholder management” out loud. A transcript only contains the words you actually said.
• Name things, don’t point at them. “I built the dbt models in Snowflake” scores better than “I built them there”.
• Say your numbers clearly: years of experience, team size, data volume, the result of your project.
• Answer the question first, then add detail. A short, direct first sentence is easy for a person and a tool to summarize.
• Use a good microphone and a quiet room. Bad audio means a bad transcript.

Expect a few technical questions. Most recruiters are not engineers. When they ask a technical question, they usually read it from the screen and compare your answer to an expected one. The questions are simple, but you still have to know them. A Life360 recruiter asked:

“5. How do you decide what goes into Staging vs. Marts in dbt?
[…]
6. What happens if you choose the wrong partitioning, clustering, or materialization strategy?
[…]
7. What orchestration tool do you use?”

A Wealthsimple recruiter asked how you validate data pipelines and how you handle sensitive employee data. Tsebek’s recruiter at a gaming company asked him to rate how often he uses Python, SQL, AWS or GCP, Snowflake and Airflow, on a scale from 1 to 5. Give short, correct answers with the right terms. The recruiter cannot follow a long technical story, and neither can the scoring tool.

You can fail this round, even with a lot of experience. One member did, more than once, in 2026:

“I’ve also failed a few recruiter screening rounds. It could be because I’ve been more relaxed and less focused on interview prep, maybe not using enough relevant keywords, or it could just be increased competition.”

How to prepare:

• Have a 2-minute answer to “tell me about yourself”, aimed at this job, with the words from the job description in it.
• Prepare short answers to the basics of your stack: what each tool is for, and one or two common trade-offs. The questions are simple, but you have to say them in your own words.
• Know your salary number before the call. Step 10 shows how to pick it.
• Have clear answers on work permission, location and notice period. They are yes-or-no filters.
• Ask what the next rounds look like, and what the team cares about most. One Life360 recruiter said A/B testing was important and to prepare it before the next round.

Recorded video or AI interview

Who gets it: sometimes, any role. More common at big companies.

Instead of a call, you get a link. Questions appear on the screen, or an AI voice reads them, and you record your answers on camera. Nobody is on the other side. A person or an AI reviews the recordings later.

Avsemddm did a HireVue interview for a Senior Data Engineer role and described exactly how it works:

“The interview consisted of five video questions, and for this position all responses will be evaluated by real team members, not by AI.
First, they give you a chance to practice with some sample questions. […] For the real questions, they give you about one and a half minutes to prepare and three minutes to answer.

I didn’t try to use all three minutes - I always aimed to give clear, structured answers of about one and a half minutes.”

Her questions were standard ones: introduce yourself and your motivation, your leadership style, why you are the best candidate, an end-to-end project, and one design question. Here is how she prepared:

• Short STAR stories for her main topics: a pipeline modernization, messy data, working with other teams, ownership.
• Short bullet notes next to the camera, so she stayed structured without looking away.
• Answers of about 1.5 minutes, not the full 3.

Look at the camera, not at another screen. Avsemddm read that some platforms mark answers as “not confident” when you keep looking away, and she thinks that is why she failed these interviews before.

Hiring manager round

Who gets it: almost every role.

Usually 30-60 minutes with your future manager. This round is about your experience in depth: what you built, what your part was, how you work with people, and why you want this job. Some managers add a few technical questions. Tsebek’s hiring manager round for a Data Engineer job was mostly one long walk through his recent project:

“Questions were related to my previous projects only:

• Tell me about yourself
• Please walk me through your recent project. What kind of data you were dealing with? Who were the primary stakeholders […]
• what was your role in the entire project?
• What about, testing? Testing your pipelines, the data quality testing. Do you have any strategy for that as well?
• what about alerting and monitoring? […]
• How do you collaborate in the team?
• how do you manage different priorities? Especially when you have multiple competing priorities […]”

Match what you talk about to the role. One member was turned down after a hiring manager round for a Senior BI Engineer job, and the feedback was clear:

“[The candidate] is enthusiastic and motivated, particularly in the field of engineering. However, there are concerns regarding his lack of emphasis on analytics and limited experience with Looker.

So I was too focus on engineering side😆”

How to prepare:

• Pick one project and know it end to end: the business problem, the data, your part, the hard decision, and the result with a number.
• Prepare 3-4 behavioral stories. Lesson 5.2 shows how, with STAR.
• Read the job description again and lead with the part of your experience it asks for most.

Technical rounds

Who gets it: every role, but the content depends on the role.

Usually one to three rounds: live coding, a take-home, a case study, or a system design interview. Sometimes it is a panel with several engineers. Match your prep to what each round tests, not to “studying everything”. For a general prep flow, the Tech Interview Handbook interview guide is a good free start. Below are the round types members got, with the links people in our community shared for each.

SQL

Who gets it: almost every data role, analysts included.

A SQL round usually has two parts: write a few queries, then answer short questions about how SQL works.

1. Query tasks. Usually 2 to 4 tasks on one or two tables, from easy to medium. The same types come up again and again:

• Top N, or the second highest (second best seller, top 5 customers)
• Window functions: running total, % of total, rank, LAG/LEAD
• The latest row per group (each customer’s most recent order)
• Rolling metrics, like 7-day active users
• User activity: active vs inactive users, simple cohorts
• Remove duplicates
• Self joins (pairs of employees, pairs of products)

The easy task is often followed by “now write it another way”: without window functions, or without CTEs. A Valtech interviewer did exactly this in May 2026:

“Today I had a live SQL interview for Sr DE position at Valtech.
The tasks were simple but the interviewer asked a lot of additional question to understand my thought process.
[…]
For the second tasks my first solution was with CTEs but the interviewer asked me to rewrite it to have just one query without any CTEs or subqueries.”

Window functions are where most members fail. alexg7ag failed a technical round on a % of total (SUM() OVER ()).

2. Trick questions. Short questions with a catch, usually about NULLs and joins:

• Which of these is true: null = null, null <> null, 1 <> null?
• How many rows can an INNER or LEFT join of 10 and 5 rows return?
• WHERE vs HAVING, UNION vs UNION ALL, RANK vs DENSE_RANK vs ROW_NUMBER, DELETE vs TRUNCATE.
• Why does cast(created_date as varchar) > ... make the query slow? (The function on the column stops the index from being used.)

3. Optimize a query. More common for senior roles. You get a slow query and explain what you would change. alexg7ag got SELECT * FROM database.spans on a 500 TB table, partitioned by day. The expected answer: select only the columns you need, filter on the partition, and ask what the stakeholder really needs.

The format varies: a live Google Doc with no autocomplete, a timed test on CoderPad, HackerRank or CodeSignal, or a recruiter reading questions out loud. Whatever the format, think out loud. Read the task, ask about edge cases (NULLs, ties, duplicates), and check your result before you say “done”. Interviewers grade how you think as much as the final query.

SQL links:

• Read: the DataLemur SQL interview guide. Then solve DataLemur’s SQL questions: kazarmax says if you solve them all, you’re ready.
• Try: LeetCode Top SQL 50, recommended by Dmitry.
• Try: real SQL tasks from a PartnerStack round and from a Karat Sr DE screen.
• Watch: a Surfalytics mock SQL interview. Ask in Discord for your own mock.
• Read: window functions in SQL. alexg7ag shared it after failing a technical interview on window functions.
• Read: SQL query optimization techniques (PDF), for the “optimize this huge table” questions.
• Try: my SQL tests doc.
• Try: the Stack Exchange Data Explorer, a free SQL sandbox on StackOverflow’s own database.

Python

Who gets it: data engineers most often; analytics engineers sometimes; analysts rarely.

Python rounds come in three kinds. For data engineers, the first one is the most common.

1. Data tasks. You get messy data and turn it into a clean table, the way you would at work. Real tasks from our members:

• Call an API, handle pages and rate limits, save the result as CSV.
• Flatten nested JSON into rows.
• Join a CSV file with a JSON file and write one flat table.
• Aggregate a file too big for memory.

tsebek got this one at Samsung for a contract Data Engineer role:

“Customer and Events data are ingested from source systems.
Customer data in CSV. Events data in JSON.
[…]
Using Python show how the input data above can be transformed into a table with the structure below:
customer_id, customer_name, device_model, event_ts, device_status”

A Valtech round in 2026 was the same idea with stricter rules: a deeply nested JSON file, native Python only, no pandas. The candidate had to explore the structure, count the geometry types, and flatten coordinates nested three levels deep.

2. Short coding puzzles. Easy problems on lists, dicts and strings. They come up often enough to practice. Run-length encoding ("aaaaabbb" → "a5b3") came up three times in our community. Others: the intersection of two lists without set, the most frequent number in a list, and counting all subordinates per manager. Some go harder. iakubovskii7 failed a Bloom filter implementation, on what the interviewer called an “easy” task:

“First section - System Design of analytics dashboard […] Second section - Python online coding
Task: realize bloom filter (more in thread)
I did not managed with this easy task.
Reject message on the next day.”

3. Theory questions. Short questions about how Python works: list vs tuple, dict vs set, which types can be dict keys, and why a mutable default argument keeps data between calls. Senior roles add threads vs processes, the GIL and async. One candidate failed a senior high-frequency trading interview on exactly that: “we felt there was a lack of depth… which are quite crucial in our environment.”

Python links:

• Try: a real Python technical round: nested JSON, BigQuery from Python, and pulling data from an API. Solve them yourself before you look at the answers.
• Read: the Requests quickstart and Python’s json module. Then build one small script: API → flatten JSON → CSV. Add paging and a retry on error 429 (too many requests).
• Try: run-length encoding. nkotlyarov got “write Python code for RLE compression” as a real interview task.
• Try: Climbing Stairs on LeetCode. It came up in bariscamli_’s ML Engineer intern round.
• Try: pythonsandbox.io. One employer used it to test alexg7ag’s Python live.
• Try: the CoderPad screen IDE before a CoderPad test. Read CoderPad’s own candidate prep guide and this Reddit thread with CoderPad tips.

Data modeling

Who gets it: analytics engineers most often; data engineers and BI developers often; analysts rarely.

Data modeling comes in two forms: theory questions inside another round, or a full round where you design a model live.

1. Theory questions. Asked in almost every analytics engineer and data engineer interview. The most common ones:

• What is a fact table, and what is a dimension? Is a customer table a fact or a dimension?
• What are the SCD types? How do you build SCD Type 2 in dbt? (This is the single most asked modeling question in our community.)
• Star schema vs snowflake schema. Normalized vs denormalized: when do you use each?
• Surrogate keys vs natural keys. How do you build a surrogate key?
• How do you handle late-arriving facts?
• Kimball vs Data Vault: what’s the difference, and which have you used?

These sound basic, and people still fail on them. One member failed a round in 2026 on normalization vs denormalization in a warehouse vs a transactional database, and said: “Still nervous a little bit during the interview and try to give the quick answer.”

2. Design a model live. You get a business case and design the tables, usually in 45-60 minutes, in a doc or on draw.io. Real cases from our members: Uber (riders, drivers, trips), Instacart (grocery orders from creation to delivery), a restaurant chain, a purchase-order system, and website traffic at Pantheon:

“Pantheon hosts websites for customers. Business wants to understand site performance metrics, traffic patterns, and resource usage across our customer base.
How would you model this?
[…]
Types of business questions to answer:

• Which sites have the highest traffic by month?
• What’s the average response time by subscription plan type per month?
• Which customers are approaching their resource limits on their subscription plans?”

Often the next task uses your model. At Pantheon, the SQL questions came from it. At Instacart, the second task was writing a monthly invoice query on top of the model you had just designed. A weak model makes the SQL part hard too.

A simple order that works:

1. Ask which business questions the model must answer.
2. Name the business process: an order, a trip, a page view. That is your fact table.
3. Say the grain out loud: “one row per order item”. Most mistakes start here.
4. List the dimensions: customer, store, product, date.
5. Add keys, and say how the tables connect (one-to-many, many-to-many).
6. Say which dimensions change over time and how you track them (SCD2).
7. Check the model against the business questions from step 1.

This is where people lose. annatimoshenko_ got this feedback after the Uber case:

“Her data model design was a bit too basic and didn’t incorporate best practices, such as constraints, data redundancy, extensibility or usability. She also had difficulty identifying relationships between the tables.”

3. “How would you track history?” A common follow-up after a take-home or a project walkthrough: “A business changes its type from ‘carpenter’ to ‘financial institution’. How do you keep both, without breaking the joins in your fact tables?” The expected answer: an SCD2 snapshot with valid-from and valid-to dates, and fact rows joined on the key and the date.

Data modeling links:

• Read: Practical data modelling with SQL. Dimensional modeling hands-on in DuckDB, written to help you answer these interview questions.
• Read: dbt snapshots, the usual way to build SCD2 in dbt.
• Read: The Data Warehouse Toolkit by Ralph Kimball. Members read the first chapters before interviews; it’s where facts, dimensions and SCDs come from.
• Read: One Big Table vs dimensional modeling, a good answer to “why not just one wide table?”
• Read: this ER diagram explainer. A recruiter sent it to a member before a data-modeling round and said the cardinality section mattered most.
• Try: the dbt data modeling challenge (NBA edition). Paradime’s challenge page is gone, but this solution shows the task and the dbt + Snowflake models.
• Try: take one case from above (Uber, Instacart, Pantheon) and design it yourself in 45 minutes: tables, columns, grain, keys. Then write one SQL query on top of it.

Tools: warehouse, dbt, pipelines, cloud

Who gets it: data engineers most often; analytics engineers often (mostly the warehouse and dbt parts); BI developers sometimes; analysts rarely.

There is rarely a coding task here. These are questions, asked in the recruiter screen, the hiring manager round and the technical rounds (see above). The job post decides how deep they go. If a tool is in the post, expect detailed questions on it. Some companies spend a whole round on one tool: Snowflake, Azure Data Factory, Redshift. Members who had not used the tool hands-on failed those rounds.

Real questions members got:

• Warehouse: What is a virtual warehouse? What is Time Travel? Partitioning vs clustering? How do you load files from S3? A query is slow: what are your debugging steps?
• dbt: table vs incremental vs view. How do you structure the project? Which tests do you run? How do Slim CI and defer work?
• Pipelines: full vs incremental load. How do you capture changes (CDC)? How do you rerun a failed job without duplicates? What if the source schema changes? How do you ensure data quality? (This is the most common technical question of all.)
• Airflow and cloud: executors, passing data between tasks, how dbt runs in Airflow. Which AWS, Azure or GCP services have you used, and for what?

Two habits help. Know the numbers of your own project: data size, number of models, run time, cost. And only mention a detail you can explain: one member mentioned dbt’s defer, and the interviewer immediately asked how it works.

Tools links:

• Read: Snowflake key concepts, how dbt projects are structured, and Airflow core concepts.
• Try: the Snowflake + dbt-core hands-on lab.

System design

Who gets it: data engineers, mostly from mid-level up; sometimes analytics engineers; analysts rarely.

A LinkedIn post someone shared in our community names the most common mistake:

“Most candidates hear ‘design a data platform for X’ and immediately start listing tools… The strongest candidates pause. They ask: what decisions is this data supporting? How fresh does it need to be? What breaks if this pipeline is late”

One member’s system design round at Granum is the best example I have. It was 60 minutes with a VP of Data and a Senior Manager, and the task was an internal data platform for a SaaS company. They kept asking if the candidate even needed Airflow, and budget came up right away. That’s normal now: some companies in our community moved off Fivetran to Airbyte or self-hosted tools just to save money. The member rated the round 7 out of 10, and said a mock interview with a friend before the round was “extremely valuable.”

So practice this order out loud, before you name a single tool.

1. Ask what decisions the data supports, and how fresh it needs to be.
2. State your assumptions and constraints: data volume, budget, team size, compliance.
3. Sketch the shape (sources, ingestion, storage, transform, serving) before naming vendors.
4. Only then attach tools, and say why each one fits the constraints you just stated.
5. Cover the parts interviewers expect regardless of stack: observability and alerts, security, infrastructure-as-code, documentation, cost monitoring. This part is the same for any stack.

System design links:

• Read: my DE system design cheat sheet, the full prep sequence.

Take-home

Who gets it: any role and level. Most take-homes in our community were for senior jobs.

Take-homes range from a 30-minute SQL test to 4-6 hour projects. The common types:

• SQL or written answers: a timed HackerRank test with no interviewer, or a short written answer, like “this query on a 500 TB table is slow, what would you change? (500 words max)”.
• A dbt project: build a small Kimball model from raw data, refactor a query, review a pull request.
• An analysis or dashboard: explore a dataset, find patterns, present the findings to a stakeholder.
• A small pipeline: pull data from an API, load it into a database, often in Docker.

The long ones are a real cost. As sstrukov_99163 put it, “if every company starts asking that, job searching becomes an unpaid full-time job.” You can say no to one, and some members did.

Doing more does not win. I once spent about 20 hours on an assignment that asked for 3, and was rejected:

“Zappier told me my home assignment wasn’t good. I spent 20 hours instead of 3 and put my all Databricks knowledge into it.”

Expect a review call. After you submit, you usually walk the team through your solution, and they push on every choice. tsebek’s review: why SQL and not something else, what changes with many airports and new data every 6 hours, what the time complexity is, and whether the GROUP BY is expensive. Know why you made each choice, and how it would scale.

How to handle one:

• Time-box it before you start.
• Hand in a smaller piece that works and is documented, not a big half-finished one.
• Write a short README: what you built, what you skipped, why, and your assumptions. One 2026 take-home said it directly: “Depth over coverage. If anything is unclear, make a reasonable assumption, note it, and keep going.”
• Check whether AI tools are allowed. More and more take-homes allow them.
• Afterwards, put it on GitHub as a portfolio project, if the company doesn’t mind. Reword the task if it’s confidential.

Take-home links:

• Watch: Real Analytics Engineer assignment analysis and Senior Analytics Engineer home assignment review, two Surfalytics walkthroughs of real take-homes.
• Read: a dbt take-home (Kimball models, a SQL refactor, a PR review) that passed to the next round.
• Read: my three take-homes, including the failed Zapier one with the company’s feedback.
• Read: a short written take-home (SQL refactor, rolling average, dbt commands) that got a member to the next round.

Final round

Who gets it: almost every role, especially from mid-level up.

The last conversation is often with senior leadership: a director, a VP, the CTO, or business stakeholders. By now they believe you can do the work. This round checks fit: your motivation, how you explain things to non-technical people, and how you handle trade-offs. Sometimes it is two or more short interviews on the same day.

Tsebek’s final round for a Risk Analyst job was with the director of risk, and it was all about fit:

“At the third (and final) round with director of risk there was more cultural fit:

• How do you feel to work at startup compare with banks?
• What is better for you - deliver rough numbers in the output and meet the deadline or deliver high quality analytics but miss the deadline?
• How do you manage with situation when you don’t have enough historical data for analysis?”

A member’s final round with the CTO at Granum had questions like “Why do you want to leave consulting?”, “Tell me about a time you challenged a business request”, and two that are easy to miss in prep:

“5. Explain something technical to me as if I don’t know it.
I chose dbt.
I first clarified what level of explanation the interviewer wanted. […]

6. What would you change about yourself?
I said that I can sometimes be too direct. […] I am learning to adjust my communication, explain my reasoning more carefully and be more diplomatic when needed.”

How to prepare:

• Prepare your “why this company, why now” in two or three sentences.
• Practice explaining one tool or project to someone non-technical in under two minutes.
• Bring 2-3 questions of your own. One member asked how the role would split with the Data Insights manager’s, and how the company uses AI. Good questions show you are already thinking about the job.

Passing the final round still does not guarantee an offer. Lesson 5.5 covers that.

Lesson 5.2 — Behavioral is where technically strong people lose

Strong technical people lose here more than anywhere else. It has happened to members of our community, and it has happened to me.

One member was a strong technical match for a role, and still got this feedback after a round with a VP and a Director:

“fell short from the behavioural perspective… searching for candidates who have more experience with engagement around driving products and companies to success via data.”

I was rejected from Blackline Security for lacking “management skills”, for a job that looked like a hands-on role with no team to manage.

Tonya9262 used to interview candidates at Amazon. She says soft skills count there as much as technical ones:

“for Amazon soft skills part [is] as important as tech skills check… Bar Raisers usually conduct 1 hour behavioral interview”

That is a full hour of behavioral questions, and it counts as much as your technical rounds. Prepare for it like you prepare for SQL.

Use STAR. Situation, Task, Action, Result. It’s the method our community uses most, and interviewers often ask for it directly. Some ask follow-up questions in a chain: what was the situation → what did you give up → how did that affect the result → what was the outcome → what was your role.

Or use CARL. Context, Action, Result, Learning. Here is a video that compares STAR and CARL. CARL ends with “what did you learn”, which works well when the story is about a mistake.

For Amazon, know the Leadership Principles. A Bar Raiser round checks several of them in one hour. Prepare a STAR story for each principle you’re likely to get, instead of making one up on the spot. “Disagree and Commit” came up many times in our community, so have a story ready for it.

Prepare one full story about a data project you drove. Some form of it comes up in almost every round: “tell me about a time requirements were unclear”, “a disagreement with a stakeholder”, “your biggest technical achievement”, “why are you leaving”. One member said it simply, and I think about this one a lot:

“From my experience if you are able to pass all technical interviews for the role, you can do this job. […] it’s important to build good relationships with the team members and the stakeholders - maybe even more important than being super technical.”

Watch for unusual questions too. Real ones members got:

• “If you had all the money in the world, what would you do?” (Aritzia)
• “What would former colleagues say about you?” (a Lead DE round)
• “Something you changed your mind about in the last year related to data modeling” (Lightspeed)

They test the same thing as the standard questions: can you think clearly on an open question. Only the wording is unusual.

• Read: this Notion guide with example answers to “Tell me about yourself”, “Why this company”, strengths and weaknesses. Vitaliy_schwabra found it.
• Try: Google Interview Warmup, a free tool to practice answers out loud with AI feedback.

Lesson 5.3 — How to answer when you don’t know

This matters more than how much you know. Fakegodh was suddenly asked what RBAC is and didn’t know the term. That happens to everyone. My advice for this moment is always the same: think out loud. One member passed a hard SQL round this way:

“Very useful tip that helped me to pass 2nd SQL task where I struggled: say your thought out loud and ask questions, interviewer will see how you are thinking and most probably will give you hints.”

Silence looks like you have nothing. A guess with your reasons, said out loud, shows the interviewer how you think, and that is what the round tests. If you don’t know a term, say what you’d guess from the name, then ask a question. That is a better answer than “I don’t know.”

Lesson 5.4 — AI in interviews, both directions

Some companies ban AI in interviews. Others want to see how you use it. Prepare for both.

Some companies ban AI and check it. They run live tests where you share your screen, sometimes with the camera on, so you can’t cheat. ksuna92 and tonya9262 both had this. Tonya put it well:

“Just finished a behavioral interview and a Python task — they asked me to share the entire solution. Honestly, it feels even harder now than before the AI era… back then I could just Google things, but now it’s trickier!”

If a round says no outside tools, they mean it. Practice solving these problems without help. You won’t have ChatGPT open to save you.

Other companies check how you use AI. Interviews now ask directly: “how do you use AI in your work?”, “which AI tools do you use?”. At Granum, a member got this in the recruiter screen (see above) and again in the hiring manager round:

“What is your perspective on using AI with data tools and business users? Which AI development tools do you currently use?”

A manager at Butter said it directly about their case study: “we will see how you use it to solve the problem, because that’s what’s needed in real life”. One member says talking about Claude Code was one of their strongest answers, at both Granum and Life360. Don’t hide your AI use. Explain it with details: what you use it for (dbt, SQL, Airflow, documentation, code review) and how it changed your work.

The simple rule: before each round, find out whether AI is allowed, and follow that exactly. If nobody says, you can talk about how you use AI, but don’t use it live for basic things you should know yourself.

Lesson 5.5 — Nothing guarantees an offer

Passing every technical round does not mean you get an offer. This happened to me at Dandy, a US dental company, after several weeks of interviews:

“After several weeks of interviews at Dandy (dental), a US company, I had a call with HR. They interviewed me on Manager of DE (6 people team). But because I did it like 4-5 weeks, they told me that they’ve hired manager already.

HR told me they can consider myself for IC role like Sr DE. I told them that it is great, I wanted to have IC role instead. I asked about comp. For Staff DE ideally and comp ~ 250k CAD.

But, she told me that comp = base + 40/50% options (not real money) + 6% bonus. I.e. base like 130-150k CAD. WTF”

A member had the same experience after a strong loop for a Senior Analytics Engineer role: “After 4 rounds of interviews over the past 2 months… ‘we’ve made the difficult decision to pause hiring for this role until January’” (2025-05-09).

The only protection is to have more than one process going at a time. Don’t stop applying when you reach a final round, and don’t treat any one company as your only chance. That’s what the people who got offers did. I did too: I got an offer from a different company through wellfound.com, remote, with Snowflake, Fivetran, AWS and Airflow, as the only data engineer on the team (2025-07-19).

This is the rule for the whole course: never stop searching, even after you sign. Any process can end at any stage, and you lose the search skill when you don’t use it.

Action items

• Take one of the job descriptions you saved in Module 1. Give it to ChatGPT, Claude or another AI tool with this prompt: “Here is a job description. List the 20 interview questions I’m most likely to get for this job: about 12 technical ones, based on the tools and skills in the description, and about 8 behavioral ones. Group them by interview round.”
• Compare the list with the real questions in this module. Replace 3-5 generic ones with real ones from the rounds your role gets.
• Write a full answer for each of the 20. Full sentences you could say out loud, not bullet points. For SQL and Python questions, write the actual code.
• Take one SQL answer where you used a CTE and rewrite it as one query with no CTEs or subqueries, like the Valtech interviewer asked.
• Write three behavioral stories in STAR form: one success, one failure or mistake, one “disagreed with a stakeholder” story. About one minute each, spoken.
• Say all three stories out loud once before Module 6. If a sentence feels unnatural to say, rewrite it. A story that reads well on paper but sounds stiff is not ready.
• Run the 5-step system design structure from Lesson 5.1 out loud on one prompt, for example “design a data platform for X”. Name no tool before step 4.
• Keep searching: take one real interview every quarter, even when you’re happy at work. After each one, add the new questions to your bank and write down which round types changed. The AI questions in Lesson 5.4 are the kind of change you miss if you stop.

More resources

• Steve Yegge, The Last Technical Interview: an essay on technical interviewing.
• Complete dbt bootcamp on Udemy: a member used it to prepare for dbt questions.

Time to complete: 45-60 minutes to read and set up. The habit takes 10 minutes per interview

You finish this module with:

• A working recording setup. Tested once before a real call.
• A ChatGPT prompt. That turns any transcript into a Q&A list.
• Your first question bank entry. From your next interview, or a past one you remember.

Why this module exists

This is the most useful habit I know. I use it myself, every time I interview.

Every interview you take should make the next one easier.

Most people do the opposite. You walk out of an interview, feel relief or dread, and move on. Within a day, you remember maybe 10% of what was asked. The exact wording of the tricky SQL question is gone. The follow-up you fumbled is gone. The name of the tool the interviewer mentioned is gone.

I built a different habit, and so did people in our community. Record the interview. Turn it into a transcript. Turn the transcript into a clean question-and-answer list. Post that list to the community. Save it to a shared repo. Do this every time, and your one-off interviews add up to a question bank. It starts as your own bank and becomes the community’s, and it gets more useful with every interview anyone takes.

Even when I have a job, I keep taking some interviews, so my bank keeps growing and my interview skills don’t fade.

This module is that workflow, tool by tool, including the mistakes I’ve made along the way.

Lesson 6.1 — The workflow, step by step

The workflow is a handful of steps. None of them is hard. The value comes from doing all of them, every time.

Step 1: Start the recorder before the call starts.

This sounds obvious. It is the step I fail most often, and I am not the only one.

“Today I had intervire for Sr DE in Joist. I forgot to click ‘start’ on record:(”

That was me. I lost the whole interview. No transcript, no question bank entry, nothing to review. Now hitting record is part of joining the call for me. I hit it the moment I open the link, before I even say hello.

Step 2: Let it run passively.

Once it is on, I don’t touch it again. A good tool sits in the background, on your desktop or joined as a calendar bot, and captures audio for the whole call. Don’t manage the recording during the interview. Pay attention to the interviewer.

Step 3: Pull the transcript right after the call ends.

I do this immediately, not later that day. The tool has already done the transcription work. Open it and copy the text while the interview is still fresh, in case you need to fill gaps the transcript missed.

Step 4: Turn the transcript into a Q&A list with ChatGPT.

This step makes the raw transcript useful. I do it every time:

“I had interview with Toronto startup for Sr data Engineers. I used limitless to collect all the text and chatgpt to summarize for you. In the thread.”

Here is the prompt I use:

“Here is a transcript of a job interview I just had. Extract every question the interviewer asked me, in the order asked. For each question, write: (1) the question, cleaned up for clarity but keeping the original meaning, (2) a short summary of how I answered, (3) the topic or skill it tests (e.g. window functions, system design, behavioral). Format as a numbered list. Do not invent questions that were not asked.”

Paste the transcript after this instruction. You can adjust it to also ask ChatGPT to draft a stronger version of your answer. If you do, keep that in a separate, clearly labeled section, so you don’t confuse what you actually said with what you wish you had said.

Step 5: Post the Q&A list to the community.

Once I have a clean list, I post it. This is how our #job-searching-and-interviewing channel built up years of real interview questions. I’ve done it myself, repeatedly:

“@someone amazing! You can record transcription of the interview and share the questions for the future interviews. 200k is ok, but for Sr I want target base starting 160k”

“@someone nice, you need to get some interviews to try, don’t forget to record all questions with Limitless or Notion, to extract questions and share with us”

If you’re taking this course outside our community, post it wherever your study group or cohort lives. Your interview becomes someone else’s prep material.

Step 6: Consolidate into a shared repo.

Don’t let the Q&A list live only in a chat message that scrolls away. Move it into a shared, searchable place: a repo, a shared doc, a wiki. che_chill_ did this for our community:

“I collected a few SQL tasks from interviews and prepared sample datasets for them. Maybe someone will be interested in practicing)”

Step 7 (optional): Publish the recording itself.

Some of us go one step further and publish the raw interview recording as teaching content, once we have our own consent to share it (it is your interview). This is optional and separate from the private review use case. Don’t publish a recording of someone else’s spoken words without thinking through consent first. More on this in Lesson 6.4.

Lesson 6.2 — The tools, and why the “best” one keeps changing

There is no single tool we all agree on. My own stack has changed twice in two years, and I’m mid-transition again right now. I’ll give you the history so you don’t chase a dead tool the way I sometimes have.

Limitless AI was my default from mid-2024 onward, and a lot of the community’s too. It linked to your calendar, joined calls automatically, and gave 10 hours of transcription free per month:

“You can use this app https://www.limitless.ai/ and it will record all audio into text and gives you summary! this might be very helpful to learn from interview and share with us summary and questions!”

It had real limits. Early on I struggled to get it working at all:

“PS Record interviews is great! I failed to run Limitless AI to collect all texts but tomorrow we will be ready with Tsebek on one more DE interview, also will record.”

And I was never fully comfortable with what it asked for:

“Yes, I use free version of Limitless. Sometimes when I have overlap meetings I can use it to transacribe the meeting in case they call my name:) I don’t share my contacts and email. But idea is great. I doubt security as well.”

annatimoshenko_ liked that you could re-listen:

“Limitless records it as well! Just found out, that’s very convenient, because it not always transcribes correctly and you can listen once (twice, etc) again to better understand what it was about”

It also could not capture headphone audio on Windows:

“It turns out that on Windows it can’t capture the sound from headphones. I couldn’t find any apps on Windows that could do the same thing…Since using transcription from MS teams or Zoom is not always an option, seems like only buying Mac can help”

Then Meta acquired Limitless and shut it down. If you were relying on it, you need a new tool now. avsemddm asked in our channel if anyone uses something else to get live transcriptions during an interview. Nobody had a clean answer yet. That’s roughly where the community stands.

Notion has been my go-to for transcribing meetings since. I’ve said so more than once, as late as early 2026.

Hedy is Nikita’s current tool:

“I use Hedy, I believe Dima is using Notion to record.”

Granola.ai is the newest option on my radar. It is a meeting transcription tool that works like Limitless used to, and it has a free tier. I moved to it myself and now use it instead of Notion for meeting recording.

Big Interview (biginterview.com) is a paid, structured mock-interview platform. You answer pre-loaded questions and it grades your tone and eye contact with AI feedback. Use it for solo practice, not for recording real interviews.

OBS Studio is a free, open-source screen recorder. It does not transcribe. Use it if you just want a video file, and pair it with a separate transcription step.

Webex (free tier) transcribes automatically and is easy to share your screen with, but caps calls at 30-40 minutes:

“Webex (even free version) can do transcription, config audio output, it is easy to share the screen and highlight things on the screen. Only problem - 30 or 40 minutes limit for the call.”

It is fine for a short screen, but not for a full technical round.

Google Interview Warmup is free and gives you AI feedback on practice answers. Good for solo drilling. More on this in Module 7.

The open question: I haven’t settled on a definitive Limitless replacement, and neither has anyone else I know here. Hedy, Notion, and Granola are all in active use by different people right now, and none of us has compared their transcription accuracy. Pick one, test it, and move on. Don’t wait for a consensus. vitaliy_schwabra asked Nikita for his method once:

“Nikita, please share your approach of recording the interviews/questions/answers because I usually just remembering it afterwards but it is not very nice way))“

Lesson 6.3 — Practical setup, learned the hard way

A few concrete things to check before your next real interview:

• Two-monitor trick. Keep your recording tool’s window on a second monitor. That way it never appears in your shared screen during a technical round. If you only have one monitor, keep the tool minimized to the taskbar.

• Test headphone audio capture, especially on Windows. This tripped up more than one of us, as you saw above. Some tools cannot pick up audio that goes through your headphones rather than your speakers. Find this out on a low-stakes call, not during a real interview. I shared this video on mapping audio streams for this part of the setup.

• Use a secondary email with calendar-linked tools. alexg7ag flagged this:

  “@someone amazing video! do you use https://www.limitless.ai/ to record it ? (if yes do use use pay version bind to you primary email or dummy /secondary email becuse application want to have access to you contacts and calendar…)”

  Any tool that connects to your calendar sees who you are meeting and when. Use an email you don’t mind a third-party tool having deep access to.

• Test the whole chain on a mock call first. Before you rely on a tool for a real interview, run it end to end on a practice call: start recording, end call, pull transcript, paste into ChatGPT, check the output. Find the failure points when nothing is at stake.

Lesson 6.4 — Consent and legality: read this carefully

This is the weakest-sourced claim in the whole course, and I want you to treat it that way.

I have exactly one explicit legal statement on recording interviews from our community. It comes from Nikita, in direct reply to a member asking whether they should tell the interviewer they are recording:

“I use Hedy, I believe Dima is using Notion to record. In Canada, you don’t have to tell anybody that you are recording as long as you are using these recordings for personal usage, so don’t tell recruiter that you are recording.”

Here is what this statement is, and is not:

• It is one person’s understanding, not a lawyer’s opinion.
• It names one country: Canada.
• It is tied to one condition: personal use only.
• Nobody else in our community has confirmed it, questioned it, or added a different jurisdiction.

Recording consent law is not the same everywhere. Some places are “one-party consent”: if you are a party to the conversation, you can record without telling anyone. Other places are “two-party” or “all-party consent”: everyone on the call must agree. These rules differ by country, and inside some countries they differ by state or province. A rule that is true in Canada does not automatically transfer to where you live, or to where the interviewer is.

This is not legal advice. Before you record any real interview without telling the other side, check the law in your own jurisdiction and in the interviewer’s, and check whether your employment or NDA agreements say anything about recording. If you have any doubt, disclose that you are recording, or don’t record at all.

Action items

• Pick one recorder from Lesson 6.2 (Hedy, Notion, or Granola are the current active options) and set it up.
• Run a 5-10 minute test call on a mock or practice call: start the recorder, talk, end the call, and pull the transcript.
• On the same test call, check that the tool captures audio through your headphones, especially on Windows.
• Paste the transcript into ChatGPT with the prompt from Lesson 6.1, Step 4. Check the output: does it capture every question, and is the topic tagging useful?
• Save the resulting Q&A list as entry #1 in your own interview question bank. Keep it as a single running doc or repo.
• Look up the recording consent rule in your own location, and the interviewer’s, before you record a real interview.
• After your next real interview, post the Q&A list in #job-searching-and-interviewing (or wherever your study group lives).
• Keep searching: record every interview you take, including the ones for jobs you would decline, and add the questions to your bank the same day. Keep doing it after you land the job.

More resources

• CV reviewer GPT: a custom ChatGPT GPT that checks a CV for grammar mistakes (shared by aksimemor, 2024-02-06).

Time to complete: 30-40 minutes to read, plus one mock session of 30-120 minutes

You finish this module with:

• A mock interview booked or done. With a member, in #mock-interviews.
• A two-column feedback note. What went well, what to fix.
• A narration drill. You repeat before every mock or real interview.

Why this module exists

A mock interview is the closest thing to a real interview that doesn’t cost you a real offer if it goes badly. We’ve run these in Surfalytics for years. The feedback I give and hear back keeps naming the same one or two weaknesses, across dozens of different candidates. This module covers those weaknesses, how we run mocks, and how to drill the fix before your next one.

Two of the 13 offer-holders in our community’s archive credited mock interview prep directly for their result. That’s a small sample, but it is two real, named people.

Lesson 7.1 — The two formats we run

Mocks in our community fall into two tracks, and I run one of them myself.

SQL live-coding mocks, run almost every week by Nikita since February 2024. Format: one candidate at a time, a scheduled slot, a live call, and Nikita works through SQL tasks with the candidate live. Spectators are welcome to just watch. Sessions are often recorded and later published as public teaching material. If nobody signs up, the session gets cancelled.

Behavioral, technical, and system-design mocks, which I run myself. Before the session, I ask for your resume and the URL of a real job posting. The mock then targets the exact role you are going for, not a generic interview. I also run separate system-design sessions for your preferred cloud platform: AWS, Azure, or GCP.

Each format trains something different. Nikita’s SQL track builds execution speed and pattern recognition. My resume-and-posting track trains you to talk about your own experience under real interview conditions, for the job you want.

Lesson 7.2 — The feedback format: two columns

Every mock ends the same way: two labeled lists, “Good points” and “Areas for improvement.” Nikita’s feedback after a mock is a good template for the shape:

“Hey @someone! Thanks for joining today - it was great meeting you and practicing SQL together. You did a really good job, and your SQL skills are solid, so no worries there. The main thing to improve is attention to detail. I recommend reading the task out loud, asking any clarifying questions, and double-checking your solution once you’re done. You can also walk through the task step by step to make sure you covered everything. If you want to practice more or have any questions, feel free to reach out - happy to help anytime!”

This feedback is specific. “Attention to detail” comes with three concrete habits: read it out loud, ask clarifying questions, double-check before you call it done. Use this shape for feedback you give and feedback you ask for: name the skill, name the specific gap, name what to practice.

Lesson 7.3 — The single most repeated weakness: silent problem-solving

Across many mocks and many candidates, I keep seeing the same gap. Candidates go quiet and solve the problem in their head instead of narrating out loud. Nikita shared the fix, and it’s the most useful tip I’ve seen in our channel:

“Very useful tip that helped me to pass 2nd SQL task where I struggled: say your thought out loud and ask questions, interviewer will see how you are thinking and most probably will give you hints.”

shiryaevva, who landed an offer after six rounds, credited the same skill for the technical rounds:

“Huge thanks to @someone for the mock interview prep – the comments really helped for the technical rounds since explaining each step in detail was key for the interviewers.”

The interviewer cannot see inside your head. A candidate who gets the wrong answer while narrating a sound approach often scores better than a candidate who gets the right answer in silence. With the silent one, the interviewer has no evidence of how they think.

The narration drill. Practice this on its own, separate from solving the actual problem:

1. Pick any SQL or coding task you have already solved, so you know the answer.
2. Solve it again, out loud, from a blank state, narrating every step: what you are reading, what you notice, what you are about to try, why, and what you expect to happen.
3. Record yourself doing this (see Module 6 for tools). Play it back. Count the silent gaps: any stretch of more than 5-10 seconds where you said nothing while working.
4. Do it again on a new task, aiming to close those gaps: “I’m going to check whether this needs a GROUP BY… let me look at the aggregation… okay, I think a window function handles this better because…”
5. Repeat until narration feels automatic. You should sound like you are thinking out loud, not reciting a script.

Do this drill before every mock and before every real interview, the same way you’d warm up before a workout.

Lesson 7.4 — The second recurring note: attention to detail

The second most common piece of feedback is about care, not knowledge. Look back at Nikita’s feedback in Lesson 7.2. The SQL skills were solid, but the gap was attention to detail. The fix was three habits:

• Read the task out loud before you start solving it. This slows you down enough to catch details you would otherwise skim past.
• Ask clarifying questions before assuming what the interviewer wants. This is also part of the narration habit above. It shows your thinking, not only your typing.
• Double-check your solution once you think you are done. Walk through it step by step against the original task. Don’t stop the moment something runs.

Lesson 7.5 — Recording your mock and reviewing yourself

Everything from Module 6 applies here. Record your mock the same way you’d record a real interview. Then review it yourself.

Watching or listening to yourself is uncomfortable, and it is useful. You will hear the silences the narration drill is meant to close. You will hear the moment you stopped explaining and just started typing. That is the gap to work on next.

Lesson 7.6 — Solo practice when you have no partner

A live mock with another person is the strongest format. There are also solo options:

• Google Interview Warmup is free. You answer practice questions and get AI feedback. Good for a quick, no-cost warmup before a real interview.
• Big Interview (biginterview.com) is paid. It is a structured platform where you answer pre-loaded questions and get AI feedback on tone, eye contact, and content, in addition to what you said.

Neither replaces a live mock with a real person watching your thinking in real time. Use them to warm up between live sessions, not instead of them.

Keep practicing after you land a job, because interview skill fades without use. Nikita runs an active job search every 6 months to practice interviews.

Action items

• Book or run one mock in either format from Lesson 7.1: a live SQL mock with Nikita, or a behavioral/technical mock with me. For mine, send your resume and the URL of one real job posting.
• Record the mock with your setup from Module 6.
• Before you hear the interviewer’s feedback, write your own two-column note: Good points / Areas for improvement. Then compare it with theirs.
• Play back the recording. Count the silent gaps longer than 5-10 seconds where you solved a step without narrating it.
• Run the narration drill from Lesson 7.3 on one task before your next mock or real interview.
• Add the questions from the mock to your question bank from Module 6.
• Keep searching: do at least one mock a quarter, even when you have a job you like, and run the narration drill before each one.

Time to complete: 2-3 hours, plus practice before each real call

You finish this module with:

• A written script for the salary question. Said out loud at least once.
• Your own number. The floor you will not go below, and the number you ask for.
• A decision rule. For when to say no to an offer.

Why this module exists

An offer is the start of a negotiation.

Most people freeze here. They say a number too early. They accept a bad fit because they are tired of searching. I have negotiated my own offers, more than once, in public, in our own channels. This module teaches the script I use, word for word.

Lesson 8.1 — The four-step script

My rule is simple. Never say your number first.

Once you say a number, the negotiation is over. Now the employer knows your ceiling. So the first goal in any salary conversation is to make the other side say a number first.

Step 1: Deflect the early question.

Recruiters often ask for your number in the first call. Use this line:

“I’d rather understand the role and level first. What range is budgeted for this position?”

If they push again, say:

“I’m flexible and open to discussing a fair number once we’re both sure this is the right fit. What does the range look like on your end?”

Two of our members confirm this works: “I usually try to do everything not to say a number first… The last 2 times I was able to get a range from the recruiter” (tonya9262).

Step 2: Anchor on your current position.

If they insist you give a number, do not invent one. Anchor on where you already are:

“I am currently making [X], and I would not go below that.”

This is safer than naming a target number. It is a fact about you, so it does not sound like a demand. It also sets a floor.

Here is what this looked like for me, live, with Dandy in 2025. They’d already told me the manager role was filled and were trying to slot me into an IC role for less money, dressed up with options:

“After several weeks of interviews at Dandy (dental), a US company, I had a call with HR. They interviewed me on Manager of DE (6 people team). But because I did it like 4-5 weeks, they told me that they’ve hired manager already. The target comp was 270k CAD.

HR told me they can consider myself for IC role like Sr DE. I told them that it is great, I wanted to have IC role instead. I asked about comp. For Staff DE ideally and comp ~ 250k CAD.

But, she told me that comp = base + 40/50% options (not real money) + 6% bonus. I.e. base like 130-150k CAD :WTF

I told her, I don’t care about options, I want 250k base. She will ask team. Also, they told me, they are US company!!! but pay cheaper than good Canadian company giving you ‘fake money’ with options. Also, they don’t have real legal entity here and payroll is through the Deel.com.”

I held my number. A week later:

“I got an offer from Dandy eventually, for Sr DE level 2 for 250k CAD base + 8% yearly bonus + 160k options over 4 years (basically 0). Need to decide what to do next :)”

I got my base. The options I never counted as real money, and I was right not to.

Step 3: Use a specific comparable posting.

If your current number is low, or you are changing roles, bring outside evidence. Find one real job posting for a similar title, similar seniority, similar stack. Quote it directly.

I did this in an interview with a US hardware startup in 2024:

“I mostly chatted about my experience in space manufacture, Alexa and Xbox devices (hardware + software and their telemetry) and used knowledge from business books about netflix, amazon, startup culture and etc. Asked questions about market size, VC money, pricing strategy, competitive and so on. I’ve share link from Nikita about Sr Analytics Engineer at Grammarly with their salary up to 300k. I might be too naive, but worth trying.”

It does not have to land perfectly. It moves the anchor.

Step 4: Name a real competing offer.

This is the strongest lever I know. If you have a second offer in hand, use it:

“I have another offer at [number]. I’d prefer to join your team, but I need you to be close to that.”

Nikita has this documented twice, for himself. One offer moved from 145k to 150k CAD plus a 15k signing bonus. A later offer moved from 165k to 175k CAD. Across 2024 and 2025 his own base rose from 127,000 CAD to 175,000 CAD, partly through this tactic. He used it honestly, with real competing numbers.

A caution: only pull this lever when the competing offer is real. Naming a number you cannot back up is a risk if the employer asks for details.

Practise saying these four lines out loud before your next call. Nervous delivery undoes a good script.

Lesson 8.2 — Real compensation data

Job-search advice is useless without real numbers. Here is what our community reported, with dates. Dates matter because the market moved during this period.

Date	Role	Compensation	Region
2024-05	BI Engineer	127,000 CAD + 10% bonus	Canada
2024-10	Data Engineer	$115,000 USD + 20% bonus	Seattle, US
2024-11	Junior Analytics Engineer	$85,000 + bonuses	Canada
2025-04	Lead Databricks Engineer (freelance)	€425/day, rising to €450+/day	EU client
2025-06	Sr Data Engineer	$150,000 CAD + $15,000 signing bonus	Canada
2025-07	Sr Data Engineer (contract)	remote, US fintech startup, paid via Deel, found on wellfound.com	US (remote, worldwide)
2025-07	Sr Data Engineer, Level 2	250,000 CAD base + 8% bonus + 160k options over 4 years	US company, Canadian payroll (Dandy)
2025-08	Snowflake Developer (contract)	$175,000 CAD (~$84/hr)	Canada
2025-09	Analytics Engineer	$100,000 + $25,000 stock	Canada
2025-09	Senior Data Engineer	€72,000 (~50% raise over prior job)	Europe

The two 2025-07 rows are mine. Everything else is self-reported by other members in our #offer-stories channel. These are self-reported numbers, so treat them as informal signal. New numbers show up in #offer-stories as people post them, so check it for your role and region.

To check a number against the market by company, location and level, use levels.fyi. Pay is only half of a level. For what changes in scope and responsibility between levels, I shared this post comparing $100k and $200k roles: https://www.linkedin.com/posts/jrlasak_whats-the-difference-between-a-100k-200k-activity-7391066626286137344-82iO

Do this check before an offer arrives, because once a recruiter gives you a deadline there is no time left to research the market.

European day rates, as reported by one member working the freelance market:

Region	Day rate
Portugal	€200-350/day
Eastern Europe	€350-450/day
Central Europe (Germany, Netherlands)	up to €560-600/day
Nordics / UK, Lead or Architect level	€650-750/day

Non-local contractors are often capped below local rates. One example from the community: a Nordic client capped an external contractor at €560/day against €1,000/day for a local hire on the same role.

Why dates matter: Nikita went from 127k CAD in May 2024 to 175k CAD by August 2025. That is one person’s growth in bargaining power and seniority. It does not show a market-wide trend. But the market also moved in that time. Application-to-interview rates fell over the same period, and several of us describe 2025 as harder than 2024. Read any number here against its date.

Lesson 8.3 — Declining offers

Not every offer deserves a yes. In our archive, one member received 4 offers and declined 3. Another received 2 offers and declined 1. This is normal.

A misaligned offer usually shows up under time pressure: a recruiter with a Monday deadline, while your preferred offer is still in process. My advice for this situation:

• Tell your preferred employer directly: “I have another offer, I need an answer by end of week.”
• With the offer you don’t want, ask for more time honestly: “I’m still weighing this against another process. Can I have until [date]?”
• If you must decline, do it in one clear message. You do not owe a long explanation.

The pressure to accept “anything” is real. One member described social pressure to take any job, and pushback that not accepting meant she might not belong in the market she was searching in. Her own account: she held out, and the eventual right-fit offer came later. Holding a clear bar under pressure takes practice, so practise it.

Write your own refusal line now, before you are under pressure:

“Thank you for the offer. After thinking it through, this isn’t the right fit for me right now. I appreciate the time you spent with me.”

Lesson 8.4 — Contract versus permanent, and the day-rate math

Contract and freelance roles are common in this market, especially in Europe, and I have taken them myself. The 2025 fintech contract I mentioned above was paid through Deel, not payroll. A day rate looks big. It is not the same as a salary.

Converting a day rate to an annual equivalent:

day rate × billable days per year = gross annual equivalent

Use roughly 220 billable days per year as a starting estimate. That accounts for holidays, sick time, and gaps between contracts. Do not assume 260.

Example: €450/day × 220 days = €99,000 gross equivalent.

What the day rate must cover, that a salary does not:

• Your own taxes and social contributions (an employer normally pays part of this for you)
• Time between contracts, when you earn nothing
• Your own equipment, software, and often your own health insurance
• No paid vacation, no sick pay, no employer pension contribution
• Business-side costs: accounting, invoicing, a legal structure if one is required in your country

Where you’re incorporated changes the math a lot. I run contract income through the mechanics that fit my own situation. Some of it goes via Deel, and the legal entity and tax rate depend on where I book the income. A day rate that looks like double your old salary can still land close to your old net once you account for all of this. Do the math before comparing a contract offer to a permanent one.

Lesson 8.5 — Reading the total package

A job offer is rarely just a base number. Read every part before you compare offers:

Component	What to check
Base salary	The guaranteed number, before anything else
Bonus	Is it guaranteed or target-based? What has actually been paid in past years?
Stock or equity	Vesting schedule, and whether the company is public, private, or pre-IPO
Signing bonus	One-time only — do not treat it as part of ongoing comp

Our archive shows real examples of each: a 10% bonus on a BI Engineer offer, a 20% bonus on a Data Engineer offer, a $25,000 stock grant on an Analytics Engineer offer, a $15,000 signing bonus on a Senior Data Engineer offer, and my own Dandy offer with 8% bonus plus 160k in options.

On that last one, my own read on the options: treat pre-IPO equity as close to worthless unless you have strong reason to think otherwise. I said as much when Dandy tried to make options do the work of base pay. “Basically 0” is how I put it, and I still negotiated as if that were true. Do not let a large equity number replace a fair base.

Lesson 8.6 — The overqualification rejection

Sometimes you get rejected as “overqualified.” This can feel like a compliment that costs you a job. Here’s how I think about it:

“I think the key, for Max, the role and pay is shit. The team is shit, same as recruiter skills. I know you are desparate for the job, but shit jobs not what you want.

I agree with Aizhan, overqualification is a myth. It is just low budget and low expectation, like they hire monkey for minimum wage and will micromanage.”

The rejection usually means the role’s budget or scope does not match what you are worth. It says nothing bad about you. Do not chase that role further. Spend the energy on a role that matches your level.

Lesson 8.7 — Red flags in the process

Watch the process itself as well as the final number. One flagged pattern from our archive:

“Asking for references before the offer is a bit red flaggy.”

References normally come after an offer, or right before one, as a final check. A request for references early in the process, before any offer discussion, can mean the company is unsure or testing candidates cheaply. It is one data point, not proof of a bad employer. Notice it, and weigh it against everything else you know about the process.

Action items

• Write your answer to “What are your salary expectations?” using Step 1 and Step 2. Say it out loud five times, until you can say it without hesitating.
• Write down your floor number: the lowest base you would accept today.
• Find one real job posting for your target role and level. Note its disclosed or estimated range. Save it as your Step 3 evidence, ready to quote.
• Check that range against levels.fyi and against the numbers in #offer-stories for your role and region.
• Do the day-rate math for one contract posting you have seen (day rate × 220). Compare the annual equivalent against a permanent role at the same level.
• Write your one-line refusal script from Lesson 8.3. Save it somewhere you can find it fast.
• Keep searching: every quarter, check your floor number against 3 live postings for your role and update it. Then when an offer lands, you already know your number and you are not guessing.

Time to complete: 1 hour to set up the routine, then ongoing

You finish this module with:

• A monthly routine. Low cost, written on one page.
• A current resume and number. Kept fresh while you are employed.
• A question bank that stays alive. One interview a quarter, even when you are not looking.

Why this module exists

Start this routine on day one of the course. Keep it running while you search, and keep it running after you sign an offer. Landing a job does not switch it off.

My philosophy is simple, and I’ve said it in our channels more than once. Nikita says it like this:

“In today’s market, it’s important to stay in interview shape, so if a layoff ever happens, you can find a new job quickly.”

Job security, in the classic sense, does not hold anymore. The search is a skill, and it fades if you stop using it. A better job might also exist right now, while you are not looking. Every module before this one taught one part of the search. This module keeps all of them running.

Lesson 9.1 — Job security does not exist. Readiness does.

I said this plainly back in 2024, and I still stand by it:

“This is the point about Job Security. It is not exists, you need to study more and build your networking and personal brand by writing posts, commit to git and be active here and in Linkedin. Otherwise you are in higher risk.”

You need a plan for it. Here are two real patterns from our community:

• Nikita runs a passive search that is always on, plus an active search every six months, to stay sharp. He stays ready to leave, even when he is not looking.
• Another member changed jobs four times in under three years. He said the frequent moves were his mobility strategy.

Both approaches treat the job search as a skill that fades without use, so you practise it on purpose.

Lesson 9.2 — The always-on passive search

“Passive” means low effort, spread thin, always running. Here’s Nikita describing his own version of it:

“I’m always in a passive job search — if recruiters reach out, I’m open to talking. But my bar is high: I’m only considering fully remote roles with a 180k+ CAD salary because I already have a good income.

Every 6 months I do an active job search to practice interviews, update resume, check what skills are in demand, and see if I can get a higher compensation. In today’s market, it’s important to stay in interview shape, so if a layoff ever happens, you can find a new job quickly.

Break it into habits:

• Keep your LinkedIn profile current and marked open to opportunities, even quietly.
• Say yes to a recruiter call now and then, even with no plan to move. It costs one hour and keeps your interview skills from going stale.
• Glance at job postings for your role monthly to track where the market sits. Note the range, the stack, the title.

This costs a few hours a month. Compare that to the 2 to 6 months it took our own case studies to land a new offer once a real search started. Passive readiness shortens that number if a layoff ever forces the question.

Lesson 9.3 — Keep the question bank alive

Module 6 taught you to build a question bank from every interview you take. Do not let it go stale once you are employed.

• Once a quarter, take one interview, even for a role you would decline. Add whatever new questions come up to your bank.
• Re-read your bank before that interview. If a question stumps you, better to find out now than during a real layoff.

If you stop adding to it, your bank slowly goes out of date. Interview norms and question styles shift, as Module 5 and Module 0 both show. Keep it current.

Lesson 9.4 — Know your number, continuously

Module 8 taught the negotiation script. That script only works if you always know your own floor number, even when no offer is on the table.

• Update your target number every few months against real postings for your role. Use levels.fyi to check it by company, location and level.
• If your current pay has fallen behind the market, that is worth knowing now, not the day you get an offer and have thirty seconds to decide if it is fair.

Lesson 9.5 — Personal brand as insurance

Two of the 13 tracked offers in our archive came inbound, from recruiters who found the candidate first. Neither of those two candidates was actively searching at the time.

I’ve said this to our members more than once:

“Personal brand is important! Do you do anything for your personal brand and writing?! Share in 🧵 I assume this is the key to success career long term.”

The method is visible public work. Write about your stack, keep GitHub activity visible, post on LinkedIn. This is the same personal-brand advice from Module 4, applied here as insurance rather than as an active search tool.

You do not need to post daily. It is enough that a recruiter searching your stack and title can find you before you ever open a job board.

Lesson 9.6 — A note on overemployment

Some members in our community hold two or three contracts at once, sometimes called “2x is better than 1x.” My own view on where it fits:

“But hear we more about: get technical knowledge, pass the interview, land the job of good company with decent pay and salary. The oe is just an option if you want to have enough money to good quality life and job security, it is not the ultimate goal, just nice feature.”

Some people in our community use it. It is an advanced path with its own risks and logistics, and it has its own course under Club 500. This module does not teach it. If it interests you, look there.

Action items

• Add one recurring calendar block for checking the job market, 30-60 minutes a month. Note the range, the stack, and the title for your role.
• Update your LinkedIn profile and mark it open to opportunities, even quietly.
• Set one trigger for a “just in case” interview each quarter. Add every new question to your question bank from Module 6.
• Write down one current number: what you would ask for today, if an offer landed tomorrow. Check it against levels.fyi.
• Keep your resume from Module 2 current, whether you are searching or employed.
• Pick one recurring personal brand action (a post, a commit, a comment) and a cadence you will keep.
• Keep searching: write all of the above on one page as your monthly routine, and run it every month from today. If a layoff happened tomorrow, you would already know your number, have a current resume, and have a question bank less than three months stale.