A job application form that accepts a CV

A job application form that accepts a CV

A job application form needs three things a contact form does not: a file field that reliably accepts a CV, a record that keeps the CV attached to the person who sent it, and no barrier between a candidate and the submit button. This is one complete build of that, on your own careers page, with the files landing in your own Google Drive.

The barrier point is not a detail. Every extra step in an application form costs you candidates you never hear about, and the strongest ones have the most alternatives. A form that asks someone to create or sign in to an account before they can attach a CV is the most expensive friction on the page.

Decide the record before the form

Write down what you want to be looking at when fifty applications have arrived, then build the form backwards from that. For a role you are actually hiring for, that is usually: who they are, how to reach them, which role, when they can start, a short answer that lets you sort quickly, and the CV.

Resist the extra questions. Each one is a place to abandon the form, and most of what people add at this stage is asked again at interview anyway. If a question would not change whether you reply, it does not belong on the first form.

The form

<form action="YOUR_SUBMIT_URL" method="POST"
      data-webtzm-form="YOUR_WORKFLOW_ID">
  <input name="name" placeholder="Full name" required>
  <input name="email" type="email" required>
  <input name="role" value="Frontend engineer" readonly>
  <input name="start_date" type="date">
  <textarea name="why" placeholder="Why this role?" required></textarea>
  <input name="cv" type="file" accept=".pdf,.doc,.docx" required>
  <p data-wtzm-send-status></p>
  <button>Send application</button>
</form>
<script src="YOUR_SCRIPT_URL"></script>

Two details in there are deliberate. The role field is filled in and read-only so the record says which job this was without asking the applicant to pick from a list — put one form per role on each role's page and the field is answered for free. And accept is narrow: a CV is a PDF or a Word document, and letting the picker offer everything invites the screenshot of a CV that you then cannot search.

The three placeholder values are filled in for you when you create the workflow. The script runs the upload, reports progress into the status element while the file moves, and clears the form afterwards.

What happens when someone applies

The answers are submitted first, together with a short description of the chosen file — its name, its type, its size. Those are checked against what the field allows before a single byte moves, so an applicant who picked the wrong file is told immediately rather than after a slow upload on a phone.

The submission is accepted at that point. Only then does the browser send the CV itself, to a single-purpose address that covers exactly that one file and expires shortly after it is issued. The applicant never authenticates, never sees a folder, and never holds anything reusable.

That order has a consequence worth knowing: if the upload fails halfway, you still have the application. The name, the email, the answer and the role are all there, flagged as having an attachment that did not finish, so you can ask that person to send the CV again instead of never learning they applied.

Choosing the record

A workflow delivers to one Google output, so this is a real decision rather than a checkbox.

A spreadsheet row is right when hiring is a list you work through. Each application is a row with the name, the email, the role, the start date and the answer — and one column per file slot holding the link to the CV in your Drive. You sort by role, filter to this week, add a status column, and open the CV from the row you are reading. For most hiring, this is the correct answer and the rest of this section is optional.

A PDF per application is right when each one has to leave your team as a fixed record: sent to a hiring manager who should not edit it, filed against a role for a compliance window, or attached to an interview pack. The layout is a Google Doc template you control, so you design the application record once and every applicant arrives in that shape.

If you genuinely need both the working list and the filed copy, that is two workflows, and two is an accurate description of two different jobs rather than a workaround.

Where the CVs live

Uploads go into a folder in your own Google Drive named after the workflow, inside a single Webtzm folder — or into a folder you already use, if you point the workflow at one. Each file is named after the workflow and the submission reference, which is what keeps a folder of cv.pdf and resume-final.pdf from becoming unusable.

Worth setting expectations honestly: this is one folder per role, not a folder per applicant. If you want a subfolder created per candidate, or a folder path built out of their answers, that is something Google Forms add-ons like Document Studio do well and this does not. The record is the row or the document, and the file is named so it can be traced back to it.

A hiring form also collects personal data in a way most forms do not, so two things are worth doing deliberately. Keep the retention window short enough to defend and long enough to be fair. And remember the folder is in your Drive under your own sharing rules — which means the access you grant a colleague is the access they have to every CV in it.

What the form refuses

• Only the extensions the field lists, and the declared type has to agree with the extension. A file renamed to slip past the picker does not get past this.

• Executable and script types are refused unless deliberately allowed. On a public careers form there is no reason to allow them.

• There are ceilings on file size, on the number of files a field takes, and on the total per submission, and a field can be tightened below them. A CV that will not fit inside a sensible ceiling is usually a scan that should have been a PDF.

File upload allowances are part of the plan a workspace is on; the pricing page carries the current figures.

When a hiring tool is the better answer

Use a form builder — Jotform, Typeform, AidaForm — if you want a job application form today with no markup, a template to start from, and a dashboard to read replies in. That is a genuinely good trade for a small team hiring occasionally, and the honest cost is that the form lives on their domain and the applications live in their system.

Use an applicant tracking system if you are hiring continuously. Stages, scheduling, scorecards, multiple interviewers and rejection emails are a real product, and a form plus a spreadsheet is a poor imitation of one once you are running several roles at once.

Build it this way when the application belongs on your own careers page in your own design, the CV should sit in your own Drive rather than a vendor's, and you would rather not ask a candidate to make an account with anybody in order to apply.