DEV Community: simali dud

Boards publish on a rhythm; set alerts to it

simali dud — Thu, 22 Oct 2026 10:16:19 +0000

Job boards do not publish roles randomly throughout the week. They push batches on specific days, often tied to internal recruiter syncs or weekly budget approvals, which means the market has an internal clock. If your target board updates every Tuesday morning, visiting it on Thursday afternoon puts you behind the freshness window before you even open a listing.

Infinite scroll is designed to keep you on the page, but it destroys your energy for drafting. A better approach is to map the posting rhythm of your niche and set alerts that match those specific windows. When a relevant card drops, speed matters more than polishing a cover letter for three days. The right second application is often sent one hour after the right first, while the employer is still clearing their notification queue. Treat the board like an API feed rather than a social media stream, and you stop wasting hours reading stale listings.

Rejections arrive in batches, and so does silence

simali dud — Thu, 22 Oct 2026 06:16:24 +0000

Rejections arrive in batches, and so does silence, because hiring teams do not review submissions the moment they hit the queue. They wait until a calendar block opens or a requisition reaches a critical headcount.

A quiet week often means nobody has read anything yet. When your inbox stays empty for five straight days, the temptation is to rewrite your cover note or tweak your resume keywords. That reaction assumes a continuous pipe where humans evaluate applications as they arrive. In practice, review cycles are discrete sweeps.

Map each role's likely review rhythm instead of reacting daily. Enterprise teams often run weekly triage meetings. Smaller shops review in batches once a pile crosses twenty candidates. If you track when responses actually land, patterns emerge. A rejection on a Tuesday morning usually follows a Monday sync where a hiring manager cleared out stale records.

Judge your aim on the cycle, not the hour. Checking status dashboards every sixty minutes turns an operations problem into an emotional one. Build your pipeline to feed the intervals, then let the calendar run its course while you write code or build systems that actually belong to you.

JSON can parse perfectly and still invent a fact

simali dud — Wed, 21 Oct 2026 20:18:16 +0000

A successful parser is not a truth detector. Here is a small learn-by-doing exercise you can run without uploading any personal data. The books below are fictional. The faulty output is deliberately constructed to illustrate a failure mode; it is not a measured result from a particular model.

1. Keep the source beside the output

Paper Signals — A. Dube — 2021 — rating 4. Quiet Circuits — T. Moyo — 2023 — rating 5. Small Useful Things — N. Rao — year unknown — rating 3. The contract is exactly three records with lowercase title, author, year and rating keys. Year is an integer or null; rating is an integer from 1 to 5.

2. Inspect this constructed failure

[
  {
    "title": "Paper Signals",
    "author": "A. Dube",
    "year": 2021,
    "rating": 4
  },
  {
    "title": "Quiet Circuits",
    "author": "T. Moyo",
    "year": 2023,
    "rating": 5
  },
  {
    "title": "Small Useful Things",
    "author": "N. Rao",
    "year": 2020,
    "rating": 3
  }
]

The array is valid JSON. It also has the requested fields, integer years and ratings within range. Yet the final year, 2020, is invented: the source says unknown. A shape validator can accept this while the factual comparison fails.

3. Run three separate checks

Syntax: does JSON.parse accept the string? A trailing comma should fail here.
Shape: are there three records, the exact keys and the correct types/ranges? A rating of 9 should fail here.
Source truth: do the values match the fictional input? An invented but well-typed year fails here.

4. Correct the missing value

[
  {
    "title": "Paper Signals",
    "author": "A. Dube",
    "year": 2021,
    "rating": 4
  },
  {
    "title": "Quiet Circuits",
    "author": "T. Moyo",
    "year": 2023,
    "rating": 5
  },
  {
    "title": "Small Useful Things",
    "author": "N. Rao",
    "year": null,
    "rating": 3
  }
]

Null is not a claim that the book has no publication year. It records that the year is missing in the supplied source. If the real task needs the year, flag it for verification instead of silently filling it.

5. Try a constrained prompt

Convert only the three supplied fictional book records to a JSON array. Use exactly title, author, year and rating. Preserve unknown year as null. Do not add authors, titles or dates. Return JSON only. After generation, I will separately check syntax, shape and each value against the source.

Now change one thing at a time: add a trailing comma, make rating a string, use rating 9, or replace null with a plausible year. Write down which check should catch each change. A polished output is a starting point, not evidence that it is correct.

Practice, not a product pitch

I maintain Open Practice, an independent, non-accredited collection of practical AI activities. The complete exercise includes a fictional fixture, a local JSON checker, editable notes and an offline export. Learning materials are free; optional hosted AI tools have their own limits. You can inspect the reference manually without an AI account.

Try the complete exercise: https://open-practice.zlnew.workers.dev/activities/json-data.html?src=devto

Original source: https://open-practice.zlnew.workers.dev/demonstrations/valid-json-wrong-facts.html

Tag where every role came from

simali dud — Wed, 21 Oct 2026 14:16:04 +0000

Every application should carry a source tag - board X, referral, recruiter. After three months count interviews per tag; the ratio is the only metric you truly control. Keep the tags that consistently convert, retire the rest. Your spreadsheet becomes a map, not a graveyard.

Recruiters search booleans, not keywords

simali dud — Wed, 21 Oct 2026 10:16:19 +0000

Recruiters search booleans, not keywords. When a hiring manager opens an ATS or a sourcing extension, they do not type a list of friendly concepts and hope for the best. They construct strings like python AND (django OR fastapi) NOT legacy. If your CV is a flat list of buzzwords separated by commas, it fails the query shape before a human ever looks at the page.

A single word passes a literal scan, but a project sentence passes a boolean. If you list Python in a skills section at the bottom, it sits in isolation. When the query looks for Python paired with specific framework context and concurrency constraints, the isolated keyword floats unattached. It has no proximity score to the terms that matter.

Write the stack inside the sentence where you used it, at the scale you used it. Instead of a detached bullet point for PostgreSQL, write about migrating a million rows of session data in PostgreSQL under strict latency limits. Now the nouns and verbs sit within five words of each other. They trigger proximity operators in automated searches.

Optimize for the query shape, not the word list. Think about how a domain expert narrows down a pile of fifty candidates to five. They filter by exclusion, mandate intersections, and require specific version markers. Build your experience notes to match those distinct logical branches so you survive the initial trim.

Verbs beat adjectives on a CV

simali dud — Wed, 21 Oct 2026 06:16:40 +0000

Adjectives are claims. Verbs are events.

When you write that a system was robust, scalable, and fast, you have told the parser and the reviewer nothing they have not read on every other application in the pile. You have used words that require subjective interpretation.

When you write that a system sustained three million daily requests after the query layer was migrated, you have stated an event.

Reviewers and automated parsers look for the shape of work. They look for what changed because you were in the room. A strong verb paired with a hard metric does this work cleanly. It removes the need for persuasion.

Take a standard bullet point and look at the load-bearing words. If the first word is managed, coordinated, or assisted, the sentence is hiding the actual labor. Swap it for reduced, engineered, re-routed, or renegotiated. These words point directly to a mechanical intervention.

Delete every soft descriptor on your CV today. If an adjective tells the reader how to feel about your work, cut it. Replace it with the exact mechanism of change.

Parsers match the event. Humans trust the event. Keep the verbs.

The referral ask that does not make people wince

simali dud — Tue, 20 Oct 2026 14:19:10 +0000

Most referral requests fail because they hand the recipient a blank sheet and a chore. When someone asks you to put in a good word, they usually want you to summarize their entire work history from scratch, which is work nobody wants to do on a Tuesday afternoon.

Here is the one sentence you should send instead: "If you know anyone on that infrastructure team, would you mind dropping this two-line note into their Slack: [Your Name] is spinning up self-hosted engines and wants to talk about operational toil, not boilerplate."

Attach the two-line blurb right in the message. Never make them write your pitch. Give them the exact text they can copy, paste, and send without opening a text editor.

Shift your focus to the team rather than the vacancy. Vacancies change daily, but team bottlenecks persist for quarters. Ask about who is carrying the pager or what part of the pipeline is currently on fire.

Remember that a referral skips the intake pile, but it does not skip the engineering bar. Your advocate is spending political capital to save you from the keyword filter, not to bypass the review. Make sure your technical foundations are solid before you ask anyone to burn that token on your behalf.

Polish plateaus after pass two

simali dud — Tue, 20 Oct 2026 10:16:17 +0000

Perfectionism in job hunting often looks like polishing the third paragraph of a cover letter until midnight. It feels like work, but it is actually a hiding mechanism. The plateau arrives around pass two of any application draft. Once the spelling is clean and the core skills match the job description, further tuning yields zero change in external response rates.

Reply rates are decided by timing and aim far more than by wording. An application sent within hours of a listing going live, aimed at a role where the core stack matches your recent history, outperforms a meticulously crafted essay sent a week late. The hiring manager is reading the first fifty submissions with tired eyes. They are checking boxes, not admiring prose.

Most people spend twenty hours on three applications instead of two hours on twenty because rejection feels less personal when you can blame bad luck after massive effort. The math works against this strategy. Job boards reward volume and speed over literary merit, provided the baseline requirements are met.

Send the best few early in the cycle, measure what happens, and iterate against actual reply rates rather than hypothetical objections. If a template does not pull a response after twenty tries, rewriting the adjectives will not save it. Change the targeting criteria or the timing instead. The draft is finished when it is legible. Stop polishing and let the queue run.

Decoding recruiter silence

simali dud — Tue, 20 Oct 2026 06:16:16 +0000

Recruiter silence is usually read as a personal rejection. It is more often a logistics failure or a calendar event that has nothing to do with your code. When a submission sits for two weeks with no movement, candidates tend to cycle through self-doubt, rewrite their resume, or assume their stack is outdated.

Three distinct states cause most ghosting. State one is internal delay. The hiring manager is traveling, or the team is dealing with an outage, or two interviewers have not submitted their feedback forms. The application is alive, but the pipeline has stalled.

State two is a requisition freeze. The headcount was approved on paper, but finance pulled the budget last Tuesday because Q3 numbers missed by four percent. The role remains listed on public boards because shutting down ATS integrations requires a ticket that nobody wants to prioritize.

State three is the quiet no. The team found someone with specific domain knowledge in their exact niche, or they filled the seat internally, and the automated rejection email is queued behind three thousand others in a batch script that runs on Sundays.

None of these three states respond to emotional follow-ups. Sending a message that asks if they received your materials resets nothing. Sending a message that provides one new data point, such as an open-source pull request that solves a known issue in their public repository or a concise note on a technical architecture shift relevant to their product, forces a re-evaluation. If they are in state one, your note attaches to your file. If they are in state two or three, no nudge helps, and you spend your energy elsewhere.

Three stories, every interview

simali dud — Mon, 19 Oct 2026 14:16:31 +0000

Most loops use three prompts to see how someone operates under pressure, handles disagreement, and takes responsibility for a messy outcome. The specific phrasing changes, but the core inquiries stay constant. If you walk into each call improvising narratives about past projects, you pay an adrenaline tax that drains working memory.

Write down three distinct episodes before sending another batch of applications. Pick a failure where a deployment went sideways, a conflict where a teammate wanted a different technical direction, and an instance of ownership where you fixed something outside your formal scope. Keep each account to a single paragraph focused on constraints, actions taken, and what changed afterward.

Once these notes exist, they stop being interview prep and become drafting material. When a form asks why you left a previous role or how you handle legacy systems, draw from the same repository. Having the raw text ready prevents the repetition that creeps in when generating responses under a deadline.

This preparation compounds across weeks. Instead of spending hours tailoring every text field from scratch, you pull verified episodes and adjust the framing to match the target context. The work shifts from creative writing during high-stress moments to editing stable modules.

One line of proof per bullet

simali dud — Mon, 19 Oct 2026 10:16:54 +0000

Job applications often turn into an exercise in synonym matching. You open a thesaurus, swap out an ordinary verb for something more dramatic, and hope the parsing software notices. It is a slow way to waste an afternoon.

Tailoring is not word replacement. It is evidence mapping.

Every line in a job description represents a problem the hiring team needs to solve. Every bullet on your resume should represent a verifiable fact from your past work that matches one of those problems. When you treat the document as an evidence sheet rather than a promotional flyer, the mechanics change completely.

Start by placing the requirement on the left side of your page and the corresponding proof on the right. If the role asks for low latency data ingestion, your matching bullet cannot simply claim familiarity with pipelines. It needs to point to the specific system you maintained, the volume it handled, and the constraint you solved.

This pairing does double duty. When you get the call, you do not have to scramble to remember what you did on that project. The proof is already tied directly to the requirement they care about. Your preparation time shrinks because your own document has become your study guide.

The danger in this process is invention. When a requirement feels just out of reach, the temptation to stretch a truth is high. If you built internal dashboards, it is a short leap in your head to claim you designed enterprise analytics suites. That is where tailoring crosses the line into fabrication. Keep the map honest. If the evidence does not exist in your history, no amount of vocabulary adjustment will make it true.

Link every claim to a concrete artifact, keep the vocabulary plain, and let the facts do the work.

Repeated requirements are the real ones

simali dud — Mon, 19 Oct 2026 06:16:46 +0000

Most job descriptions read like a committee tried to please everyone who ever worked in the building. They start with a wish list of twelve programming languages, five cloud providers, and a degree in a field that did not exist when you graduated.

If you spend your afternoon matching your resume to every line of that wish list, you are optimizing for the noise.

The signal lives in what the text repeats. When a hiring team sits down to write what they actually need, their anxiety leaks into the document. They mention scaling bottlenecks in the first paragraph, and then they bring up high concurrency again under databases, and a third time when describing the team structure. They do not care if you know every framework on the list. They care that the site went down twice last month during peak hours, and the person coming in has to fix the queue.

Reading for the problem rather than the checklist changes how you draft your opening message.

Instead of listing twenty technologies you touched once in 2021, you point to the operational pain they keep circling back to. If the text obsesses over documentation and slow handoffs between product and engineering, your response should lead with how you untangle legacy codebases and write runbooks that junior staff can actually follow.

Two minutes of counting how many times a requirement appears will tell you more about the day-to-day reality of the role than two hours of keyword optimization. Match the frequency, not the breadth.