DEV Community: simali dud

Publish nothing you would not want opened on a projector

simali dud — Wed, 30 Sep 2026 18:15:59 +0000

Every linked artifact is an interview waiting to happen

When you open a portfolio, a recruiter is not looking for a polished show‑case.

They are looking for evidence of a workflow that can be trusted, of decisions that can be defended, and of a culture of continuous delivery.

In that sense, every link you expose on your résumé becomes a scheduled interview slot.

It is a cue to a conversation, and the content of the link must be ready to answer the questions that will come next.

Half‑finished demos teach them you ship half‑finished

The first rule of portfolio engineering is to publish early.

A demo that is incomplete is still a demo.

It signals that you are willing to expose your work, that you accept feedback, and that you ship on schedule.

When a recruiter sees a demo that is still under development, they see an engineer who can iterate quickly, who can surface issues, and who can push a minimal viable product to the next milestone.

Avoid the temptation to perfect every line of code before sharing.

Your goal is to demonstrate the value of the feature, not to exhibit a flawless code base.

If a demo is only half‑finished, make that explicit in the description: " "
“Version 0.5, shipping the core feature; polishing pending.”

This turns the demo into a live case study of an engineering sprint, of backlog grooming, of a realistic delivery window.

A tiny repo with a README that explains decisions outscores a big one that does not

Size is not a metric of impact.

A 500‑line repository that documents why a particular algorithm was chosen, how the trade‑offs were evaluated, and how the design aligns with product goals speaks louder than a 10,000‑line monolith that offers no context.

The README is the first thing a recruiter reads.

It is a written interview where you narrate the problem, the solution, and the rationale.

A concise README should contain:

Problem statement, what business need or technical constraint prompted the work
Solution overview, a high‑level sketch of the architecture and key components
Decision record, why you chose this approach over alternatives, citing trade‑offs in performance, maintainability, or cost
Testing strategy, a brief outline of unit tests, integration tests, and coverage metrics
Next steps, what would you change if you had more time, or what is on the roadmap

If a repository is large but the README is empty, the recruiter is left guessing.

They will see that the code exists, but they cannot assess whether the engineering choices were sound.

By contrast, a small repo with a thoughtful README demonstrates the same depth of thought in a more efficient way.

If it would embarrass you in the room, pull it now

A portfolio is a curated set of artifacts, not a museum of every commit ever made.

Anything that reveals a learning curve, a debugging session that ended in failure, or a code smell that you later refactored is a signal that you learn from mistakes.

However, if an artifact contains a mistake that you could not correct, or if it shows a misunderstanding of fundamental concepts, it is better to remove it.

Think of the portfolio as a “show room.”

Just as a real‑estate agent will not display a property that needs a new roof, you should not expose a code base that still uses a deprecated API or a hard‑coded path that you know is a security risk.

Pulling such artifacts is not a sign of weakness; it is a disciplined choice to keep the narrative clean and focused on the value you bring.

When you remove an embarrassing piece, replace it with a lesson.

A comment in the code or a short note in the README that explains how the issue was identified and fixed can become a talking point in an interview.

The mechanics of a clean portfolio

Track what you publish, keep a simple spreadsheet that lists each link, the date added, the status (demo, repo, blog), and the last updated date.

This gives you visibility into how frequently you add new content and how long artifacts remain stale.
Apply the 30‑day cooldown, after you submit a job, give each role or employer a 30‑day window before you reapply.

The same rhythm applies to the portfolio: if a project has not been touched or updated in 30 days, consider it for removal or rework.
Human approval gate, before any link is made live, run it through a quick checklist: does it compile? does it run? is the README clear?

No link should be shared without a final click.
Automate reminders, set up a cron job that emails you every month with a reminder to review each artifact, to note any that have become outdated, and to plan an update if necessary.
Keep the voice consistent, the tone of your README and demo description should mirror your personal brand: clear, concise, and technically grounded.

Avoid jargon that might be misread and steer clear of buzzwords that dilute credibility.

Why the focus on artifacts matters

Recruiters, career coaches, and hiring teams are pressed for time.

They scan a portfolio to decide whether to schedule a deeper conversation.

If every link they follow is an interview in miniature, they will see patterns: how you think, how you solve problems, and whether you fit the team culture.

When you publish a demo that is intentionally incomplete, a recruiter learns that you are comfortable iterating.

When you expose a tiny repo with a thoughtful README, they see that you can communicate complex ideas in simple words.

When you remove an embarrassing artifact, they learn that you are self‑aware and proactive.

All these signals are measurable.

They can be tracked as part of your personal operations: number of links added, number of updates per quarter, average time from commit to demo release.

A brief note on tooling

If you need a lightweight system to manage these artifacts, consider a self‑hosted solution that gives you full control over when and how content is shared.

It can automate the approval gate, enforce your 30‑day cooldown rule, and track the metrics that matter for a disciplined engineering workflow.

Try the demo zip at https://gethunta.pages.dev/downloads/hunta-demo-1.0.0.zip and see how a simple, open‑source tool can keep your portfolio as clean and operational as your code.

Boards publish on a rhythm; set alerts to it

simali dud — Wed, 30 Sep 2026 18:15:54 +0000

Understanding board cadence

Every job board follows a publishing schedule that is shaped by its audience and its internal workflow. Some boards refresh in the early hours of the work week, others batch new listings over the weekend and release them on Monday morning. The cadence is rarely random; it is a product of the board’s source feeds, the contracts it has with employers, and the editorial pipeline that curates the postings.

When a board publishes a batch of roles, those listings sit at the top of the feed for a limited period before the next wave pushes them down. That window of prominence is the only time a recruiter or a candidate can see a role before it is buried under newer entries. Recognising the exact days and times when a board pushes new content is the first step toward turning the posting schedule into a tactical advantage.

Mapping the freshness window

The practical way to capture a board’s rhythm is to keep a simple log. Record the date and hour when a new batch appears, and note when the same board shows a noticeable drop in fresh listings. Over a couple of weeks a pattern emerges: for example, Board A tends to surface fresh roles at 09:00 GMT on Tuesdays, while Board B spikes at 14:30 GMT on Thursdays.

Once the pattern is clear, the “freshness window” can be defined. In the Tuesday‑morning example, the window begins as soon as the first listing is visible, typically around 09:00, and narrows as the hour progresses because competing applicants also start to notice the same batch. The ideal moment to act is therefore within the first 30‑45 minutes of the window, when the competition has not yet saturated the pool.

Automating alerts without endless scroll

Manually refreshing dozens of boards in hopes of catching the first listing is both time‑consuming and mentally draining. A more reliable method is to set up alerts that trigger as soon as a new posting appears. Most boards offer RSS feeds or webhook endpoints; if they do not, a lightweight scraper can poll the board’s HTML at a configurable interval (e.g., every five minutes).

When an alert fires, it should deliver a concise payload: the role title, employer name, posting URL, and the timestamp of detection. Deliver the payload to a channel that you already monitor-email, Slack, or a personal notification hub. The key is to avoid the endless scroll that follows a generic “new jobs” email; a focused alert tells you exactly what has changed and why it matters.

Because the alert is tied to a specific board’s cadence, the noise level stays low. You only receive notifications when a board you care about publishes, and you can mute boards that do not align with your target schedule. This approach preserves mental bandwidth and keeps the process feeling purposeful rather than frantic.

Timing the follow‑up application

The first application should land within the freshness window, but the work does not stop there. Many employers continue to review applications for several hours after the posting appears. A well‑timed second touch-usually a brief follow‑up message or a refined version of the cover letter-can reinforce the initial impression without appearing pushy.

Research on email open rates suggests that a follow‑up sent roughly one hour after the original message enjoys a higher probability of being seen, simply because the recruiter has moved beyond the initial influx of submissions. Apply the same principle to job applications: after the first submission, schedule a second, more targeted outreach (for example, a concise note referencing a specific project from the employer’s website) to be sent about sixty minutes later.

The second outreach should add new information rather than repeat the original content. If the first application highlighted a relevant skill set, the follow‑up might reference a recent achievement that aligns with a key responsibility in the posting. This layered approach respects the recruiter’s workflow while keeping the candidate’s profile active in the applicant tracking system.

Integrating cadence into a workflow

A practical workflow that incorporates board cadence looks like this:

Identify target boards, pick the boards that list roles most relevant to your field.
Log cadence, spend a week noting the exact times new batches appear.
Configure alerts, use RSS, webhooks, or a simple scraper to push a notification at the moment of publication.
Prepare a template, have a modular application template ready, with placeholders for role‑specific details that can be swapped in minutes.
Submit within the window, fire the first application as soon as the alert arrives, aiming for the first 30 minutes.
Schedule a follow‑up, set a timer for sixty minutes after submission; send a brief, value‑adding note that references a fresh piece of information about the employer.

By treating the posting schedule as a predictable rhythm rather than a random stream, the process becomes repeatable and less stressful. The cadence‑driven approach also reduces wasted effort: you no longer waste time scrolling through stale listings, and you avoid the anxiety of “missing out” on a role that has already been buried.

For teams that want to codify this method, the open‑source version of hunta provides a self‑hosted demo zip that includes a basic alert engine and a role‑scoring module. The demo can be downloaded from https://gethunta.pages.dev/downloads/hunta-demo-1.0.0.zip and run locally without any subscription.

Applying a disciplined cadence to board monitoring turns a chaotic job‑search landscape into a series of small, measurable actions. The result is a clearer view of when the market is freshest, a faster response loop, and a workflow that feels less like a gamble and more like a well‑orchestrated operation.

Six prompts that do the boring 80% of your job search (copy-paste)

simali dud — Sun, 20 Sep 2026 16:51:38 +0000

Every job-search advice article argues about wording. Almost none of them argue about the actual bottleneck: the volume of reading, scoring, tailoring and following-up that sits between a job board and an interview. That part is language work, and language work is exactly what these six prompts are for. They are deliberately boring. That is the point: your judgment stays on the five decisions that matter, the machine carries the two hundred boring ones.

One rule before you start. These prompts are for the pipeline, not for the performance. Everything that leaves your name stays in your voice, edited by you. An interview measures you; a draft is just logistics.

1. The job description deconstructor

Read the following job description. Split it into: (a) the requirements they state, (b) the requirements they repeat or front-load, which are the real ones, (c) what this role is secretly for, inferred from team context, reporting line and the problems they describe, (d) the seniority this actually is, regardless of title. Be blunt about uncertainty. JD: [paste]

Most of the value here is (b). A description that lists "owns priorities" three times wants a different candidate than one that lists it never.

2. The honest fit score

Here is my CV and a job description. Score fit 0-100 against the REAL requirements you identified, and output: the top three evidenced matches with the CV line that proves each, the top two gaps, and a one-paragraph verdict on whether I should spend an application on this at all. Do not be encouraging. CV: [paste] JD: [paste]

The instruction that changes everything is "whether I should spend an application on this". Applications are not free; they cost the twelve minutes of tailoring and the emotional toll of the silence after. Score the role, not just the match.

3. The tailored one-page pass

Tailor my CV for this role. You may reorder, reweight and rephrase; you may NOT add experience, numbers, tools or employers that are not in my input. For every bullet you change, note which JD line it now answers. Keep total length to one page. CV: [paste] JD: [paste]

The "note which JD line it answers" trick does double duty: it gives you the tailoring and it gives you the interview prep material in one pass, because "why is this bullet here" is the second question every interviewer asks.

4. The three-sentence reach-out

Write a 3-sentence message from me to the hiring manager for this role, sent when the posting is fresh. Sentence one: the specific thing in the JD or their company's work that shows I did two minutes of reading. Sentence two: the single strongest evidenced match. Sentence three: a zero-pressure line about availability. No flattery, no "I hope this finds you well". Context: [JD + your one-line pitch]

Three sentences because hiring managers read these on a phone between meetings, and anything longer is instantly pattern-matched to mass mail.

5. The five-day nudge

Write a 40-word follow-up to my earlier application for [role]. It must add one new piece of information (a relevant result, a shipped thing, an answer to a question the JD raised) so it does not read as begging. Refer to my earlier message without apology.

Follow-ups with new information get answered; "just floating this" follow-ups teach people your name is noise.

6. The rejection post-mortem

I applied to [company/role] and got the standard rejection after [how long]. Write the two-sentence email that politely asks for one piece of specific feedback, targeted at the recruiter rather than the system, and phrased so that answering takes under a minute. Then list five patterns from my recent rejections (attached list) worth tracking.

You will get maybe one reply in ten. One reply is one datapoint, and five datapoints beat any career coach who has not seen your actual numbers. Keep the replies; they are the only ground truth in the whole pipeline.

The operating cadence that makes these work

Prompts alone just speed up bad habits. The boring 80% only pays when three operational rules ride along: apply within hours of a posting rather than days after polishing (a fresh average beats a stale perfect entry into a pile that grows by the hour), batch the pipeline reads into fixed windows instead of doom-scrolling, and keep one plain table of status for every live application so nothing rots untracked.

hunta is what it looks like when that cadence is the product instead of the habit: mailbox ingestion, scoring against the JD, tailored drafts behind a human approval gate, follow-ups on schedule, caps and cooldowns so the machine cannot send you into burnout. The demo is free and self-hosted. But the six prompts above run the honest version of this pipeline on nothing but a free LLM tier, and that is genuinely enough to change a month of searching. Your move on the other side of every draft still matters more than the tool. That part is not automatable and I would not trust anyone selling it.

I treat job applications as a pipeline, not a resume problem

simali dud — Sun, 20 Sep 2026 15:11:21 +0000

Every piece of career advice still assumes the bottleneck is the document. Polish this, quantify that, beat the ATS parser with the right keywords. None of it disputes that the words matter. All of it ignores that most applications never reach a human because of where and when they were aimed, not what they said.

Here is the failure order I keep observing, roughly in order of damage:

The role was wrong for you and you knew it, but a blank Sunday said otherwise.
The application went out four to nine days after posting, into a pile of hundreds.
The letter was generically excellent and specifically empty, so the reader felt the form letter.
Only then, maybe, does a parser or a recruiter glance at the resume itself.

A CV tweak fixes item three at best. The real fix is operational: treat the search as a small production system with sourcing, screening, drafting and a quality gate. This post is about the one I built and run for other people, hunta, and specifically the architecture, because the architecture is the part worth stealing even if you never touch my code.

The nightly hunt

A scheduler (in our case free GitHub Actions, four in the morning local time) walks a configured set of sources: PNet, Careers24, PiH, the PSVAC government gazette, LinkedIn's public job search, and a few niche feeds. Each source is a scraper plus an adapter, because there is no other honest word for it: the gazette is unstructured PDF, one board blocks bots at the edge (which incidentally protects legitimate small pipelines from the four-hundred-application crowd), another returns RSS, another a JSON API pretending to be a website.

The interesting part is what happens on nights with zero results. Zero is not a bug report, it is market data: global remote boards genuinely rarely pay off for a Harare or Johannesburg profile, and a pipeline that measures that lets you stop taking it personally. We log every source's yield and it changes how people aim.

Scoring against a truth file

Every candidate role gets scored against two documents: the CV, and what we call the truth file. The truth file is a short list of verified facts: projects, dates, numbers, technologies, contexts. Its whole purpose is negative: the model may only cite what appears there. If it is not in the truth file, it does not exist for the application.

This is the single most underrated control in any LLM drafting system. Not tone, not temperature. Provenance. A drafter constrained to a truth file produces boring, checkable prose, and boring prose that survives a reference call beats confident prose that does not. Our scorer also learns, gently: when a candidate taps "no" on an approval card, the reason codes feed back into ranking, so the same category of bad fit comes back less often.

The queue, and the brake

Drafted applications land as interactive cards on Discord (or Telegram): role, company, salary if posted, the fit score with reasons, and a preview of the letter. Each card has exactly the actions you would want to exist: approve and send at the scheduled time, edit the draft, reject with a reason, snooze.

Nothing sends without a yes. That rule is not a disclaimer, it is the design. Every auto-apply product I have seen fails the same way: it optimises volume, reply rates collapse, sender reputations burn, and the human stops reading their own applications. A pipeline that sends on your behalf without a gate is not a job-search tool, it is a reputation destroyer with good marketing. The approval step is where your judgment enters the loop, and judgment is what the market actually pays for.

Caps are enforced in software, not in promises: candidates per night, sends per month, usage counters persisted on disk next to the state, and the machine simply stops and asks when a cap is hit. Demo builds get small caps; paid tiers raise them; nobody gets a surprise invoice from a runaway agent because runaway is not representable in the system.

Why it runs on your infrastructure

The whole thing is a Python package plus a repo with a scheduler. The data plane (CVs, truth files, queue state) lives in your GitHub repo or your own box; the only third party it talks to is the LLM provider you choose, and a failover chain of them, so one provider's rate limit does not starve a hunt mid-run. There is no account to make with us, no database of your candidates sitting on someone else's server, and when you stop paying, the pipeline keeps running because it was never hosted by us in the first place. That is also why payment is honour-based: the hosted service is convenience, the capability is yours.

What I would tell you to copy

If you would rather build your own, and honestly you should if this is your day job, steal the shape:

Measure source yield nightly and let zero-days retarget you.
Constrain the drafter to a provenance document. Boring beats brilliant.
Freshness beats fit: submit within hours of posting or do not bother.
Keep a human on the trigger and put the caps in code.
Log every rejection as training data; your no is smarter than your yes.
Run it where your data lives. Automation that needs you to trust a stranger's database will eventually give you a reason not to.

The machine is a small factory with one employee and one quality gate, and the gate is you. Everything else is plumbing, and the plumbing is the part you are allowed to buy.

LLM Cost Calculator — free, no signup

simali dud — Tue, 08 Sep 2026 19:52:56 +0000

Per call, per day, per month, across eight models side by side. Free, no signup, nothing leaves your browser.

Get it here

API Error Retryability Classification

simali dud — Tue, 08 Sep 2026 17:59:59 +0000

This dataset classifies common API error messages and HTTP status codes into 'retryable' or 'permanent' categories. It helps developers implement robust error handling strategies, distinguishing between transient issues that warrant retries and fundamental problems requiring immediate client-side correction.

Get it here

LLM Refusal Detector — free, no signup

simali dud — Mon, 07 Sep 2026 20:32:07 +0000

Soft failures are the expensive kind: no error, no alert, just useless output flowing downstream. Paste model output and find out if it actually refused.

Dataset: https://github.com/simalidudu-boop/model-refusal-phrases

Get it here

API Error Retryability Classification

simali dud — Mon, 07 Sep 2026 18:47:49 +0000

This dataset classifies common API error messages and HTTP status codes into two categories: 'retryable' or 'permanent'. Developers can use this to build robust error handling logic, distinguishing between transient issues that can be retried automatically and permanent failures that require user intervention or code changes.

Get it here

Prompt Injection Tester — free, no signup

simali dud — Sun, 06 Sep 2026 19:06:36 +0000

Most prompt-injection filters are a regex someone wrote once. This one scores against a real corpus of documented attacks, and the corpus is public domain so you can just take it.

Dataset: https://github.com/simalidudu-boop/adversarial-prompt-injection-dataset

Get it here

Labelled Cron Expressions with Human-Readable Descriptions

simali dud — Sat, 05 Sep 2026 16:53:24 +0000

This dataset provides a collection of common cron expressions, each paired with a clear, human-readable description and a note explaining its typical use case. It serves as a reference for developers to quickly understand or implement scheduling patterns. The accompanying tool allows for looking up these descriptions and parsing cron expressions into their constituent parts.

Get it here

HTTP Status Code Guide for Ambiguous API Scenarios

simali dud — Sat, 05 Sep 2026 13:49:44 +0000

This dataset provides guidance on selecting appropriate HTTP status codes in common, yet ambiguous, API development situations. It helps developers make consistent and semantically correct choices, improving API predictability and client integration.

Get it here

Battle-Tested Regex Validations

simali dud — Sat, 05 Sep 2026 13:23:59 +0000

A curated collection of 25+ reliable, tested regular expressions for common validation tasks such as emails, URLs, and phone numbers. Each entry includes the pattern, a test input, and a note explaining its real-world applicability. Ideal for developers who need dependable validation logic without reinventing the wheel.

Get it here