Hacker News Hiring: Make a Reply Plan Before You Post

Posting in Hacker News Who is hiring comes with a commitment to reply to applicants. Before you publish, give one teammate responsibility for reviewing applications, choose a working application route, and agree on what applicants will hear after review. HN sets no numeric reply deadline; the schedule is yours to make and keep.

The October 2026 thread makes that commitment part of its posting instructions. It is easy to spend an afternoon polishing the comment and leave the work after an application arrives undecided. Who reads the inbox? Who can say no? Who tells the applicant when the hiring manager is away?

A useful preparation document answers those questions before you publish. It can fit on one page. Here is how to build it, along with an illustrative post and messages you can adapt.

Check which Hacker News hiring rules apply

Use the instructions at the top of the current monthly thread as your posting checklist. Keep them separate from the rules for dedicated YC company job ads.

The October thread asks you to state the location and distinguish unrestricted remote work, remote work restricted to particular countries, and onsite work. You must personally belong to the hiring company. Recruiting firms and job boards cannot post, and each company gets one post. Explain what your company does if it is unfamiliar. You must be actively filling a position and committed to replying to applicants. These are the monthly thread’s requirements.

The monthly thread is open to everyone, according to HN’s job guide. Your startup does not need to be a YC company to comment there. That guide also describes a separate route for YC founders to submit dedicated job ads. Its title limits, ad queue, and repeat interval belong to that route. Do not carry them over as requirements for a monthly comment.

HN does not specify a fixed response time in the October instructions. It does not require a salary range or prescribe an applicant tracking system. A compensation range and an honest review schedule can still make your post more useful. Present those as information your company chooses to supply.

The commitment begins with a real vacancy. Confirm the role is approved and someone can make a hiring decision. A comment that invites applications while the budget is undecided gives applicants a process you cannot finish.

Give the reply commitment an owner

Assign one reviewer and one backup before publishing. A shared inbox helps people see applications; responsibility tells them who must act on them.

The owner should be able to review an application, ask the relevant interviewer for input, and send the next message. If only the founder can approve a rejection or interview invitation, record that dependency. Otherwise, the person checking the inbox can appear responsive while every decision waits elsewhere.

Write down these details:

These are example choices, not an HN policy or a recommended universal cadence. A founder reviewing between customer calls might need a different schedule from a team with a recruiter. Choose one you can maintain during the week you intend to post.

Before publishing, check the team’s capacity. Put time on the reviewer’s calendar and identify the decisions they can make without a meeting. If the team cannot review the applications it already has, resolve that queue or revise the plan before inviting another source of applications.

Keep the role’s responsibility clear when staff change. A person leaving the team should hand over open applications, promised review dates, and messages awaiting approval. Forwarding an inbox without that context leaves the new owner to reconstruct each commitment.

Choose and test one application destination

Give applicants one clear route and make that route usable before linking it from HN. You can accept email or use a public application page; either choice needs an agreed review process.

A direct email address can work for a small queue. Decide who checks it, where applications are recorded, and how someone else takes over. If applicants also use a form, decide how you recognize the same person arriving through both routes. Avoid asking them to apply again merely because the first reviewer cannot find the email.

A form can keep the role, application, and conversation together. Keep its required fields relevant to the first decision. Read the application instructions as a candidate: can someone tell what to send, whether a résumé is required, and what happens next?

Test the complete route while signed out. Open the link on a phone, submit a harmless test application, check the receipt, and confirm the reviewer can find it. Then send a test reply and check that the reply reaches the intended inbox. A form that returns a success screen while hiding applications from the responsible person is not ready.

Kit’s hosted career portal gives an applicant a confirmation page and an email link to their candidate portal. The portal shows their current stage and an awaiting-review state when applicable. The candidate experience documentation describes that sequence. The acknowledgement is useful evidence that the application arrived; a person still needs to make and communicate the next decision.

You can link an HN comment to a Kit job page. Kit does not post the comment or ingest HN discussions for you. Keep the connection simple: the comment directs an interested person to the application route your team monitors.

Write a post that helps the right person apply

State the work, employment conditions, and application route in terms an applicant can evaluate. Put your reply expectation beside those details so it survives the move from the HN comment to the job page.

Here is a fictional example for an October posting. The company, compensation, and schedule are illustrative:

Northbank Tools | Senior Rails Engineer | Remote: Germany or Poland | Full-time

We build scheduling software for independent repair shops. Customers use it to book repairs, assign work to mechanics, and tell customers when their vehicle is ready.

You would work on our Rails application, especially calendar synchronization and customer notifications. The engineering team has four people. The role includes production support during agreed working hours.

The gross annual base salary range is €75,000–€95,000. We can employ someone resident in Germany or Poland. We cannot currently sponsor a visa for this role.

Apply through the job page with your résumé and a short description of relevant work. You do not need to write a separate cover letter: [your public job URL].

Our engineering manager reviews applications on Tuesdays and Fridays. We aim to send a next step or an outcome within seven calendar days of receipt. If review takes longer, we will email a revised date.

Only promise the final paragraph if the owner and backup have agreed to it. Seven days is an example chosen by this fictional team. HN has not imposed that interval, and publishing it does not make it feasible.

Be precise about remote eligibility. A person outside the countries where you can employ them should learn that before preparing an application. A time-zone overlap requirement also deserves plain wording. “Remote” alone does not answer either question.

Use the same conditions on the linked page. If the comment names two eligible countries while the form says “anywhere,” the applicant has to guess which is current. Review both surfaces when pay, location, or the role’s scope changes.

For a less familiar company, a sentence about the product gives applicants something concrete to assess. The October instructions explicitly ask unfamiliar companies to explain what they do. The example does that without expecting readers to visit several pages before understanding the vacancy.

Plan the receipt, review, and outcome messages

Define what your team means by replying at each point in the application. A receipt confirms arrival. A review message explains the next action. An outcome tells someone whether this application will continue.

HN’s wording does not define these categories. They are a practical way to carry its commitment through your own hiring process. A team could send one combined message after a quick review; another might acknowledge immediately and communicate the decision later. Make the sequence clear to the applicant.

Acknowledge receipt with a useful expectation

A receipt should identify the role and explain when the applicant can expect a review. Avoid a confident date if nobody has reserved time to do the work.

Thanks for applying for our Senior Rails Engineer role. Your application arrived today. Maya, our engineering manager, will review it by 9 October. We will email you with a next step or an outcome. If that date changes, we will let you know here.

Use an actual date calculated for the application when you send this message. Do not leave a fixed date in a template that continues running after it passes. Keep the reply address monitored so a candidate can correct missing information or ask a relevant question.

Send the next step after review

When inviting someone forward, explain the next activity and any preparation it needs. You can also say who will participate and whether the next conversation is already scheduled.

We would like to arrange a 30-minute conversation with Maya about your Rails work and the calendar problems this role covers. No task is required beforehand. Please use the scheduling link below, or reply if none of the available times work for you.

If you need more information, ask one concrete question. “Can you tell us more about yourself?” pushes the review work back onto the applicant. “Which part of the synchronization service did you own?” explains the gap you need to resolve.

Revise a date before it becomes an empty promise

A delayed review still needs a message. Name what remains undecided and offer a date the responsible person has accepted.

We have not finished reviewing your application. Our engineering manager is away this week, and the next review is scheduled for 13 October. We will send you an update by then. You do not need to submit anything else.

Send this only when the revised review is arranged. Repeatedly moving the date without a decision needs an internal conversation about whether the role can continue. Applicants should not carry the uncertainty of an unapproved position.

Review unresolved applications alongside the inbox

Keep a short record of what each applicant is waiting for. Counting new applications tells you how much arrived; the next action tells you what the team owes.

There is a broader reason to prepare for review work. Ashby’s September 2026 report analyzed more than 180,000 EMEA jobs from January 2021 through June 2026 and found that inbound applications per hire doubled over that period. That is a vendor dataset covering many hiring sources, not an HN sample or a forecast for your vacancy. It offers context for checking reviewer capacity before opening another route. Ashby’s EMEA recruiter productivity report.

For each open application, record the reviewer, current stage, last message, next action, and the next date you have promised. A small team can begin with a shared list. As more people participate, keep that record beside the conversation so the backup can continue without reading private notes in another tool.

Work through the queue in this order:

1. Messages from applicants that need a reply.
2. Review dates you have already promised.
3. Decisions waiting for another teammate.
4. New applications ready for their first review.

This is a suggested operating routine, not an automatic ranking rule. Adjust it for a booked interview or another time-sensitive commitment. The point is to see existing obligations before clearing new mail.

Keep a drafted message in the open queue until it is sent. In Kit, an assistant can prepare a candidate reply as a pending draft. A teammate must open it and choose Confirm & send. A chat instruction cannot release that draft. The Hiring AI and MCP documentation explains the review boundary.

Kit shows pending, failed, and delivered send states. “Delivered” means successful handoff to the mail server, not confirmed arrival in the candidate’s inbox. Inspect a failed attempt before treating it as sent. None of these states confirms reading or understanding, and an unsent draft remains a draft.

For an agreed future action, you can set an internal contextual reminder with a due time and eligible teammates. It prompts your team; it does not email the candidate or enforce the date you published on HN.

Close the role and the remaining applications deliberately

Treat a role closing as another review of outstanding commitments. Stopping new applications and informing existing applicants are separate actions that both need an owner.

First, list everyone whose application remains open. Separate people you intend to hire, people awaiting a decision, and people continuing in another agreed process. Check for accepted offers before preparing any broad rejection message. Resolve ambiguous cases individually.

For someone you are declining, keep the message clear:

Thank you for applying for our Senior Rails Engineer role. We have completed our review and will not be moving your application forward. For this role, we need deeper experience owning calendar integrations in production. We appreciate the time you spent sharing your work with us.

Use a reason only when it reflects the decision and you can stand behind it. Do not manufacture personalized feedback from an application you did not review. If the vacancy has been cancelled, say that instead of implying an assessment of the applicant’s ability.

Then update the public job page and any application instructions you control. Update the original HN comment if editing is available. HN’s job guide says monthly threads close to new comments after two weeks, so the linked page needs to carry the current status independently of further discussion there.

In Kit, closing a role records whether it was filled or closed without a hire. You choose whether remaining applications stay open for follow-up or receive rejection emails using the configured delay. Keeping them open sends no rejection email. Recording a hire also does not send an offer or hiring confirmation. Review those consequences in the role closure documentation before confirming.

Finally, inspect the remaining queue and scheduled messages. A closed vacancy can still have active applications if you chose follow-up. Give those people a next action and an owner. A closed job badge does not mean the conversation is finished.

Use Kit to carry the plan after the HN post

Put the application record, stage, conversation, and next action where the hiring team can review them together. That gives your HN reply commitment a place to live after the comment leaves the front page.

Kit can support that work with a public application page, candidate portal, role team, shared pipeline, pending reply drafts, and internal reminders. Configured anti-stall reminders can also nudge waiting hiring work. These features help the team see and perform its next action; Kit does not supply an HN integration or guarantee your published response time.

Start with the vacancy you intend to advertise. Name its reviewer and backup, test the application route, and write the first review date into the team’s plan. Before posting, have the owner read the reply expectation you will publish. That is the sentence they will need to carry through every application that follows.