DEV Community: Payanai

What Google, Amazon, Microsoft and Meta actually say about their interviews (and a free prep site I built from it)

Payanai — Thu, 01 Oct 2026 01:12:43 +0000

Most interview prep online is a mix of leaked questions, hearsay and "Top 75" lists. I wanted the opposite: what each company says about its own interview process, in one place, with practice questions I could trust.

So I read the official hiring pages for Google, Amazon, Microsoft and Meta, and turned them into free guides on Nokku: nokku.payanai.com/interview-prep. No sign-up.

Here's what stood out, then how I built it.

What the companies actually say

Google describes structured interviews: every candidate for a role gets the same questions and the same scoring rubric. Its own guide names role-related knowledge, problem solving and leadership. In 2025 Google also said it's bringing back at least one in-person round, citing AI-assisted cheating in virtual interviews.

Amazon runs a phone screen of 30 to 45 minutes, then a loop of 4 to 6 interviews of 45 to 60 minutes each, including a Bar Raiser: a trained interviewer from outside the hiring team. Every interview checks for its 16 Leadership Principles, and about half of a technical loop is behavioural. Amazon suggests STAR answers of about 2 to 3 minutes.

Microsoft is refreshingly specific: code in your strongest language, no pseudocode, know at least one O(n log n) sort in detail (preferably two), and manage your time in a ~45-minute round. It also says it looks for a growth mindset.

Meta describes a 45-minute tech screen (roughly 5 minutes of intros, 35 of coding, 5 for your questions), then a loop of coding, design and behavioural interviews. The process usually takes about 2 to 3 months. And the big change: Meta's hiring page says technical interviews now include an AI assistant built into the environment.

The common thread across all four: think out loud, get to working code, then improve it. Meta says it plainly: non-optimal but working code beats just an idea.

How I built it

A few decisions mattered more than the code:

Official sources only. Every guide lists its sources and a "facts checked" date. If something is widely reported but not official (for example Google's "Googleyness" or its hiring committee), the guide says so.
Original practice questions. No leaked or copied problems. Each one is written in the style of common interview questions, with hints you reveal one at a time and a full solution.
Every solution is tested. Each one is che version on thousands of random inputs before it ships. Writing the test caught one of my own wrong "expected answers".
Content as Markdown. Guides are plain `.m rendered with the same components as the site's courses: flashcards, quick checks, step-throughs, and a new "practice question" block.
Infographics from data. Each guide's "at rs, a timeline, how time splits) is generated from frontmatter. The facts live next to their sources, and the hub builds a side-by-side comparison of all four companies from the same data.

What's inside each guide

The process as a step-by-step timeline
What interviewers score you on
Pattern flashcards (two pointers, sliding winn's Leadership Principles
Behavioural scenarios with feedback on each choice
3 original practice questions with tested sol
A 4-week prep plan

Try it

👉 nokku.payanai.com/interview-prep

It's free, with no account. I'd love feedback: which company or topic should I add next? And if you've interviewed at one of these recently, does the process match what

I had 30 remote jobs and 2,000 more I wasn't showing. Here's what fixing it took

Payanai — Tue, 29 Sep 2026 15:01:55 +0000

I run Nokku.ai, a free site for job-market trends, courses and remote jobs. Its remote jobs page had a problem I didn't notice for weeks: it listed 30 jobs from the last 30 days.

That looked like a quiet market. It wasn't. We collect from three job boards (RemoteOK, JSearch and Arbeitnow), but the page only read from one of them. The other remote listings were sitting in the database, unused.

Here's what it took to turn that into a page with ~200 live remote jobs from 150 companies, and to make it something Google can actually index.

1. Merge the sources, then deal with the mess

Reading all three boards is one query each. The work is in what comes back:

The same job shows up twice. A company posts on LinkedIn, and two boards pick it up. I remove duplicates by company and title, and keep the copy that lists pay.
"Remote" isn't always remote. Boards marked as remote-only still return titles like "Senior Developer – DC + Hybrid". If the title says hybrid or on-site, it's out.
Some links aren't links. Anything that isn't http(s) is dropped before it reaches the page.

const NOT_REMOTE = /\b(hybrid|on-?site|in[- ]office)\b/i

const key = (job: RemoteJob) =>
  `${norm(job.company)}|${norm(job.position)}`

// Keep one copy per job, preferring the one that lists pay
if (!existing || (!existing.salary && job.salary)) byKey.set(key(job), job)

2. The bug that made "Go" the hottest skill

Once everything was merged, Go was tagged on 102 of 201 jobs. That's not a market signal, it's a bug.

Older rows had been tagged with substring matching, so "Go" matched "good", "AI" matched "email" and "Java" matched "JavaScript". I'd already switched to word-boundary patterns, but rows scraped before the fix still carried the old tags.

Rather than rewrite the database first, the pagfix rows when it reads them, from the title and
the board's own tags:

if (row.scraped_at >= SKILL_FIX_DEPLOYED) returreturn extractSkillsFromText(`${title} ${boardTags}`)

"Go" dropped from 102 jobs to 11. That's why I til I've looked at the rows behind a surprisingnumber.

3. Google was seeing an empty page

The old page was a client component that fetched jobs after the page loaded. Google got a spinner.
Now /jobs is rendered on the server and refreshed every 30 minutes, so the first 25 listings are in the HTML. Filters
live in the URL (/jobs?skill=Python), so filtand the canonical still points at /jobs.

4. One page per role and skill, but only whe

People don't search for "remote jobs". They seas" or "remote data analyst jobs". So every roleand skill gets its own page:

/jobs/remote-python-jobs
/jobs/remote-software-engineer-jobs
/jobs/remote-jobs-with-salary

The risk with generated pages is thin content. Two rules keep it honest:

A page with fewer than 5 listings is noindex and left out of the sitemap. It still works for visitors, and it goes back into search on its own when jobs arri.
Every intro is written from that page's data, not a template with a keyword swapped in:

18 remote jobs from the last 30 days ask for Python, at 17 companies. The skills most often listed alongside it are AI,
AWS and Java.

5. Only show numbers that can bear the weigh

My first header showed "Median listed pay: $1t came from **3 listings.

A median of three is an anecdote, so the page nngs with pay before it shows one. Until then it
just says "With pay listed: 3". It's less impressive, and it's true.

The same goes for the "New" badge. With a two-day window, 13 of the first rows had it, so it meant nothing. Now it marks
only the newest day's listings.

6. Small things that made the list easier to

Company first, in colour. Each row leads the same colour as its initials tile, then the title, location and up to four skills.
Where you'll apply. "via LinkedIn", "via te", with the site's favicon. The icons are served from our own /public folder instead of a favicon service, which would send every visitor's IP address to a third party.
Links out are nofollow, and each board is credited on the page.

What I'd tell anyone building a job aggregator

Count what you show against what you store. My problem wasn't a lack of data.
**Treat surprising numbers as bugs until prov
Generated SEO pages need a quality floor, and a way to get back out of the index.
**Don't headline a statistic you wouldn't def

It's free, with no sign-up: [nokku.payanai.conai.com/jobs)

Next I'm adding more free job-board feeds, and . If you've built something similar, I'd like to hear how you handle duplicates across boards. Mine is still fairly simple.

Building a Restaurant Finder With $0 in API Costs (OpenStreetMap, Open-Meteo, No Google Maps)

Payanai — Mon, 28 Sep 2026 15:43:54 +0000

VibeEats is a small food-discovery app: pick a mood ("cozy," "date night,"
"quick bite"), or search for what you're craving, and it matches nearby
places that are actually open, weighted by the weather and time of day.

I want to write about the part that was actually interesting to build: it
runs on $0 in API costs. Here's how, and what broke along the way.

The problem

The first version used Google Places for search, Google Geocoding for
locations, and Google Weather. A single user search fanned out into a
Nearby Search call plus ~20 Place Details calls (for photos, hours, ratings)
plus photo fetches. That's the standard Google Places pattern, and it adds
up fast — the bill got bad enough that I turned the whole discovery feature
off for a few months and left up a bare coupon page.

The rebuild: free, public data only

Places: OpenStreetMap via the Overpass API — free, keyless, and the data is often better-tagged than I expected (more on that below)
Geocoding: Photon with Nominatim as a fallback
Weather: Open-Meteo (free tier is licensed for non-commercial use, worth knowing if you're building something you'll monetize)

No API keys anywhere in that stack. The only paid things left in the whole
app are hosting (Vercel) and the database (Supabase), both well within free
tiers at this scale.

The catch: no ratings, no photos, no prices

Google/Yelp give you a star rating, photos, and a price level out of the
box. OpenStreetMap gives you none of that. So instead of faking it, I built
the ranking entirely from what's actually tagge
features (outdoor seating, takeaway, wheelchair access...), distance, and
current weather/time of day. Roughly:

\ts // simplified — the real scoring blends ~6 weighted signals function scorePlace(place, vibe, weather, hour) const kindFit = KIND_WEIGHTS[vibe][place.kind] ?? 0.1; const cuisineFit = bestCuisineMatch(place.cuiutral, not punished, if untagged const weatherFit = place.hasOutdoorSeating && isNiceOut(weather) ? 0.35 : 0; const openBonus = isOpenNow(place) ? 8 : -25; return blend([kindFit, cuisineFit, weatherFit]) + openBonus + proximityScore(place.distance); } \\

I did the same thing for price. There's a $/$$/$$$ filter in the app now,
and before building it I actually checked: I pus
across three cities (Austin, Bengaluru, New York) and looked for any
price-related OSM tag. Zero had one. Not pathe
price filter is a heuristic from venue type + cuisine + chain status,
labeled "estimated" everywhere it shows up, nev
number. It's a small thing, but I think "check before you build" mattered
more here than usual — it would've been easy to
levels exist somewhere in OSM and ship something that quietly lied.

Caching, because Overpass is slow

Public Overpass instances are free but not fast — a cold query can take
10–30 seconds, and they rate-limit. Calling tha
non-starter. So places are cached by geo-cell: the world's cut into ~2km
tiles (falling back to ~9km in sparse areas), e
served to everyone after that. Cache layers are memory → local disk →
Supabase, in that order, so a serverless cold sond
wait for every visitor.

Search over tagged data has a fun problem

Free-text search ("biryani near me") searches within the places already
loaded for the area — no extra API call. The inap
tags dishes more literally than I expected. Querying restaurants near
Hyderabad, India, for cuisine=biryani returns
not everywhere — so there's a small synonym table (biryani → also match
indian/pakistani/mughlai cuisine tags) as
specific dish isn't a literal tag. Tested against real data, it correctly
surfaced well-known local biryani spots that weot
biryani — the fallback earning its keep, not just theoretical.

What I'd tell someone trying this

OSM data quality varies a lot by city — dense in places with an active local mapping community, thin elsewhere. Buil (fall back to a wider search radius) rather than assuming uniform density.
Don't call public Overpass instances per-reqund consider hedging across mirrors since any single instance can be flaky.
If a data source doesn't have a field you wan, resist the urge to synthesize something that looks authoritative. Label estimates as estimates.

https://vibeeats.app

Happy to answer questions about any of this, es
built on top of Overpass/OSM data before — curious what I'm missing.

How I stopped my AI resume writer from inventing achievements

Payanai — Fri, 25 Sep 2026 22:47:04 +0000

Ask most AI resume tools to "improve" a bullet like "worked on the website" and you'll get something like "Spearheaded a website redesign that boosted conversions by 35%."

It sounds impressive. It's also made up. And the first time an interviewer asks "how did you measure that 35%?", it falls apart.

I recently built a free resume builder, and the one rule I cared about most was: the AI may reword what you wrote, but it may never add facts. Here's how I tried to enforce that, what I tested, and a strange PDF bug I found along the way.

The problem: LLMs are trained to be "helpful"

Language models are very good at producing text that sounds like a strong resume. Strong resumes have numbers, tools and outcomes, so when a model sees a vague bullet, the most "resume-like" completion includes a number, a tool and an outcome, whether or not they're true.

So "be helpful" and "be honest" pull in different directions. You have to make the honest option the only acceptable one.

Layer 1: Tell the model exactly what it can't do

Vague instructions like "don't make things up" aren't enough. I listed the specific kinds of invention I'd seen:

const HONESTY_RULES = `Rules you must follow:
- Only use facts the user provided. Never invent employers, job titles, dates, numbers,
  percentages, tools, technologies, awards or achievements.
- If a bullet has no measurable result, do not add one. Make it clear and specific
  with the facts given instead.
- Do not use placeholders like [X%] or "N users".
- Write in plain, professional English. No buzzwords like "synergy", "rockstar"
  or "results-driven".`

Two details mattered more than I expected:

Banning placeholders. Without that line, models "politely" add [X]% for you to fill in, which nudges users to invent a number themselves.
Saying what to do instead. "If a bullet has no measurable result, make it clear and specific with the facts given" gives the model a path that isn't "add a number".

Layer 2: Check the output's structure in cod

Prompts are guidance, not guarantees. So the cof the response before showing it to the user:

const out = await complete(systemPrompt, JSON.stringify({ role, company, current, bullets }))
const improved = (Array.isArray(out.bullets) ?
  .map((b: unknown) => clean(b, 600))
  .filter(Boolean)

// One output per input, or it's not a safe dro
if (improved.length !== bullets.length) throw new Error("Unexpected AI response")

Requiring **exactly one rewritten bullet per ins two useful things:

The model can't sneak in an extra "achieveme
The model can't merge or drop bullets, so the user can compare each one before and after.

If the check fails, the user sees an error instead of a questionable rewrite. I'd rather fail loudly than show something plausible but wrong.

I also use JSON output mode (`response_format: so parsing is reliable, and a low temperature
(0.4) to keep rewrites conservative.

Layer 3: Test it with inputs that tempt invention

The best test cases are vague bullets that almost beg for a made-up number:

Input	Output
worked on the website	Developed features for the website.
helped with customer support tickets	Assistickets.
fixed bugs in the checkout page using React	Resolved bugs in the checkout page using React.
made the product page load faster	Optimizeder loading.

No numbers, no new tools, no invented outcomes.and that's the point: they're clearer, but still
true.

I also ran an automated check that flags any output containing digits, % or technology names that weren't in the input.
It's crude, but it catches the most common kind

The UI still tells users to **read the result bt is perfect, and the person whose name is on
the resume should have the final say.

Bonus bug: why "SKILLS" became "SKI L LS"

The PDF export is simply the browser's print-to-PDF of a single-column HTML preview. That gives real, selectable text, which matters because many employers run resumeng systems (ATS) that read the text.

To check that, I extracted the text from a gene

text EDUCATION SKI L LS CERTI F ICATIONS

The cause was my section headings: uppercase wi`. With wide tracking, PDF text extraction
sometimes decides the gaps between letters are word breaks. A human sees "SKILLS"; a parser may see three words.

The fix was one line: remove the letter-spacing from the headings (and add a thin divider so they still stand out). After
that, extraction gave clean "SKILLS" and "CERTI

Lesson: **if machines will read your output, te, not just what it looks like.

Keeping it free without runaway costs

Every AI action costs money, so there's a limit per day. I store the counter in the user's
server-only metadata (Supabase app_metadata, which users can't edit), and only successful actions count against the
limit:

const usage = aiUsageToday(user)
if (usage.remaining <= 0) {
  return NextResponse.json({ error: "You've used all 20 AI actions for today." }, { status: 429 })
}
// ...call the model...
const ai = await recordAiUse(user) // only afte

Editing, saving and PDF export aren't limited at all. Only the part that costs money is.

What I'd tell anyone building AI writing features

List the specific ways the model tends to go wrong, not just "be accurate".
Give the model an honest alternative to
Validate structure in code. Prompts guide; code enforces.
**Test with inputs designed to tempt failuremples.
Test what machines see, whether that's parsed PDFs, screen readers or search crawlers.

If you want to try it, the resume builder is free at nokku.payanai.com/resume-builder. I'd genuinely like to hear if you can getit to invent something. That's the kind of bug report I want.