A Google Form is a perfectly sensible way to start taking job applications. It costs nothing, it takes twenty minutes to build, and it beats asking candidates to email a CV to an address that three people check. For a single role with a dozen applicants it is hard to justify anything else.
The trouble starts at a scale most teams reach faster than they expect. Not at ten thousand applications, where Google's own documented thresholds begin to bite, but at around fifty, when a spreadsheet stops being able to answer the question "has this person been replied to yet". This article covers how to build the form well, the one setting that silently costs you candidates, and what specifically breaks as the pile grows.
Building the application form so it does not need rebuilding
A form holds up to 300 pieces of content, which counts questions along with section descriptions, images and videos, and up to 75 sections. That is generous, but a form rebuilt every hiring round by duplicating the last one accumulates old descriptions nobody reads, so it is worth auditing rather than assuming.
Structure it in sections rather than one long list. Contact details, then eligibility, then experience, then the open questions. Sections give you two things: candidates see progress, and you can use conditional logic to skip branches that do not apply, which is the difference between a five minute form and a twenty minute one.
Keep the field count down, and be ruthless about it. Every optional question is a column in the spreadsheet, multiplied by every application you will ever receive. If nobody is going to filter or sort on an answer, it is not an application question, it is a question for the interview.
It also pays to decide up front which answers exist to screen people out and which exist to inform a conversation later. The screening answers should be structured: dropdowns, checkboxes, dates, yes or no. Those are the ones you will filter on, and free text cannot be filtered. The conversational answers can be open text, because nobody sorts a spreadsheet by paragraph. Mixing the two up is how teams end up with a column of three hundred short essays that somebody has to read one by one to find six eligible candidates.
One setting worth knowing about: draft responses are autosaved for 30 days after a candidate's last edit. That is helpful for a long application someone fills in over two evenings. It is unhelpful if the form is ever opened on a shared computer, where the next person can land in somebody else's half finished application. It can be switched off per form under the presentation settings.
The sign in wall on file uploads
This is the single most consequential thing to know, and it is easy to miss until applications are already open.
A Google Form that includes a file upload question requires respondents to sign in to a Google Account. The files have to land in Drive and be attributed to someone, so there is no way around it from inside Forms. Several other settings push in the same direction: collecting verified email addresses, limiting to one response per person, and allowing candidates to edit after submitting.
For internal recruitment inside an organisation that already runs on Google, this costs nothing. For a public job advertisement it is a real filter. A candidate reading the ad on a phone, signed into a work account on another provider, hits a screen asking them to sign in to Google before they can attach a CV. Some will. Some will decide to do it later and never come back. You do not see the ones who leave, which is what makes this so easy to underestimate.
There are two workarounds and both have costs. You can drop the upload question and ask candidates to paste a link to their CV instead, which trades the sign in wall for broken links and permission errors. Or you can ask them to email the document separately, which puts half of each application in a different system from the other half. If attachments matter and the audience is public, this is usually the point where teams look at an intake tool that accepts files without any sign in.
What actually breaks, and at what point
Google publishes thresholds where the interface degrades while the form keeps collecting. For a single role these are unlikely to matter, but for a long running careers form they do arrive.
| Applications on one form | What stops working |
|---|---|
| Over 10,000 | The per question and per person views disappear. A CSV download is no longer sorted by submission time. |
| Over 50,000 | The response summary is no longer available. |
| Over 100,000 | Responses stop syncing to the linked Sheet. |
The 10,000 row is the one that matters for recruitment specifically, because the per person view is the screen that shows one candidate's application on its own. Losing it means the only way to read a single application is to find its row in a spreadsheet and read across sixty columns.
Long before any of that, the linked Sheet becomes the real workspace, and it has its own ceiling of 10 million cells or 18,278 columns. A wide application form with 100 columns reaches the cell limit at 100,000 rows. That is theoretical for most teams. What is not theoretical is that a Sheet with two hundred rows and sixty columns is already unpleasant to read, and two people sorting it at the same time will overwrite each other's notes.
The spreadsheet workflow, and exactly where it fails
Almost every team arrives at the same arrangement. The form feeds a Sheet. Someone adds three columns on the right: owner, status, notes. Everyone agrees to keep them updated.
It works, and then it fails in four predictable ways.
Sorting detaches the notes. Someone sorts by date to see the newest applications. If the sort range did not include the hand added columns, every note is now attached to the wrong candidate. This is silent and often discovered weeks later.
Two people edit at once. Sheets handles simultaneous editing well for typing in different cells and badly for two people deciding who owns the same candidate.
The reply is invisible. Notifications for new responses go to the form's editors. Replying means copying the address into a mail client and writing there, so the sent message lives in one person's sent folder. Nobody else can see what was said, or whether anything was said. This produces both failure modes recruiters dread: the candidate who receives two different answers, and the candidate who receives none.
Nobody knows the current state. A question as simple as how many applications are still waiting on a first read gets answered by opening the sheet and counting, every time, by every person who asks.
None of these are bugs. They are the consequence of storing process information in a document that was designed to store numbers. Tools built for intake work treat the owner, the status and the reply as part of the response itself, which removes all four failure modes at once rather than one at a time.
Replying to candidates at volume
This is where the manual effort concentrates, and it is worth being clear about what Google Forms does and does not do.
It notifies you. Under the Responses tab you can turn on email notifications for new responses, which go to the form's editors. It does not send anything to the candidate beyond an optional confirmation message and a response receipt.
Anything else is built by hand or by add on. Teams commonly use a mail merge add on that reads the Sheet and sends templated messages, which works and introduces its own maintenance: the template lives in one place, the data in another, and the record of what went out in a third. The Form notifications add on exists for customised follow up messages and is the usual starting point.
There is also a timing problem specific to recruitment. Applications arrive in a burst after the advertisement goes out, and the replies that matter most are the early acknowledgements and the eventual rejections. The acknowledgements are easy to automate and the rejections are the ones that get postponed, which is unfortunate, because a candidate who hears nothing for six weeks remembers the organisation rather than the role.
Two practical habits help regardless of tooling. Send the acknowledgement immediately and automatically, because a candidate who does not know their application arrived will email to ask, and answering those emails costs more than the acknowledgement would have. And write the rejection message once, properly, then reuse it, because the message that gets delayed for weeks is always the one someone intends to personalise.
Personal data, briefly but seriously
An application form collects more sensitive information than most forms a team runs. Names, addresses, employment history, sometimes identity documents.
Three things follow from that. Check who can open the linked Sheet, since a Sheet shared with a wide group is a very different thing from a Drive folder with controlled access, and sharing tends to loosen over time rather than tighten. Check where uploaded files land, since Drive uploads sit in the form owner's Drive and count against that person's storage, which becomes awkward when that person leaves. And decide in advance how long you keep unsuccessful applications, then actually delete them, because a spreadsheet nobody owns will otherwise hold candidate data indefinitely.
When it is still the right answer
None of the above means a Google Form is a bad choice for hiring. For one role, one reviewer and a closing date, it is close to ideal: free, quick, familiar to candidates, and easy to archive when the round ends. The advice to move on only applies when the shape of the work changes.
Three signals mark that change. More than one person needs to read and reply to applications. The form runs continuously rather than closing after a round. And candidates have to attach documents while applying from outside the organisation. Any one of those on its own is survivable. All three together is the point at which the spreadsheet is no longer holding the process, it is hiding it.
What to change first
Open your application form and look for a file upload question. If there is one, the form is asking every candidate to sign in to a Google Account before they can apply, and that is costing you applicants you never see. If your owner and status columns in the spreadsheet are what really run the hiring process, that is the second thing to move, into a tool where each application carries its own owner, status and reply history, which is what Halict is built to do.
Q1. Can candidates upload a CV to a Google Form without a Google account?
No. A file upload question requires respondents to sign in to a Google Account, because the files are stored in Drive and attributed to an account. The usual workarounds are to ask for a link to the document instead, or to collect attachments through a form tool that accepts uploads without any sign in.
Q2. Where do files uploaded to a Google Form go?
Into the Drive of the account that owns the form, in a folder created for that form, and they count against that account's storage. This matters when the person who built the form changes role or leaves, so it is worth deciding early whether the form should be owned by an individual or by a shared account.
Q3. How many job applications can one Google Form handle?
The form keeps collecting indefinitely, but the interface degrades at documented points. Past 10,000 responses the per person view disappears, which for recruitment means losing the screen that shows one candidate on their own. Past 50,000 the summary goes, and past 100,000 responses stop syncing to the linked Sheet.
Q4. How do you track which applicants have been replied to?
In Google Forms there is no built in status or owner, so teams add columns to the linked spreadsheet and maintain them by hand. The weak points are sorting, which can detach notes from their rows, and replies sent from a personal mail client, which leave no record anyone else can see. At low volume it holds together, and at a few hundred applications it usually does not.
Q5. Can Google Forms send rejection emails automatically?
Not on its own. It can send a confirmation message and a response receipt when someone applies, and it can notify the form's editors of new responses. Sending templated messages to candidates requires a mail merge add on or a separate tool, and the record of what was sent then lives outside the form.