BRIEF: in my experience it is quite common for recruiters and HR departments to prefer certain formats like Microsoft Word to PDF and *TeX. ODF and HTML intermediate.
One big reason is automated extraction of data from your résumé into a standardized database to facilitate searching and comparison between candidates.
I.e. it is not just the recruiter adding their own headings.
Many recruiters and employer HR departments automatically extract information from your résumé and place it in a database, to facilitate searches and comparison between candidates.
I.e. they may ignore your résumé formatting, at least in the initial stages. We may hope that they will also present your nicely formatted résumé, but that is often not the case.
These tools work well for formats such as Microsoft Word.
These tools sometimes work well and sometimes do not work well for PDF, since content in your PDF can range from easy to extract text to bitmap images of the text that must be OCRed. The latter is particularly common for people who think that it is neat to embed university or corporate logos in their job and educational history. (Recommendation: if you are going to embed such logos, you should also embed the ordinary text name of the organization, in case the OCR fails.)
Since PDF files often have explicit layout, problems can arise extracting things like paragraphs that span page boundaries. Using multiple columns or side bars can be even more problematic. Even table layout, with things like “education“ and “job history” or “organization/date/job title” in a left-hand column, with description of the job or degree in the right hand column, can mess things up when extracting PDF. There are many different ways of preparing table layout in PDF.
HTML and XHTML is easier to parse and extract text from, especially since XHTML is more content-based. But even here more explicit layout control can make things more difficult. Simple HTML tables are easier to parse than table-like layout created by hand using nested DIVs and SPANs, where it is not always obvious which parts correspond.
A human editing the HTML can ensure that it is simple. But document production and conversion tools such as Microsoft Word “save as HTML” or LaTeX HTML or your favorite wiki to HTML may not produce HTML that is easy to parse.
ODF - similar issues. More and more support, given various European preferences, but still less common than Word and in my experience HTML.
LaTeX - could be easy to parse, since it is largely ASCII text. But I don’t think many such automated tools handle LaTeX directly. See below. Especially if your résumé uses not really that advanced features like conditional text, to allow short and long versions of the résumé, targeting different audiences like post doc or industry. but if you’re doing those things you should almost definitely not be sending the LaTeX source code. (Which is a pity, because if I were hiring you such evidence of creative laziness might be a point in your favor, as long as you were not lying in the different versions.)
More and more the hassle of extracting text from different formats like Microsoft Word and ODF and HTML and PDF has been leading towards companies extracting text for their databases by OCRing the printed bitmap image. This has the same problems with respect to detecting paragraphs that span page boundaries and the association of information in two different columns where the cells have different alignment. But it gets solved once and only once.
In any case, you should think about how easy it will be to extract text from your résumé. E.g. you might send the PDF through an OCR tool, and guess at how easy it would be to delete layout crap if your tool doesn’t do it for you.
Some job websites allow you to upload your idiosyncratically formatted resumes, and give you the opportunity to see what they have extracted. Or at least they did a few years ago, I haven’t tried this in quite some time.
When companies accept more than one format, e.g. Microsoft Word or PDF, they are often using a non-OCR tool for one and an OCR tool for others.
BTW, for those who say that STEM usually accept LaTeX, my experience is that this may be true of startups not very distant from their academic roots. But if the start up survives, eventually they get a real HR department, or more likely outsource it, and they then get these automated tools. often they get the cheaper version of these automated tools and swing all the way from LaTeX tolerant to intolerant.
Something similar happens for less academic start ups that might begin accepting only Microsoft Word and PDF.
Really early stage start ups may not have enough bureaucracy to make any such requirements or databases and will contact you to get a better format if they really want you. But VCs often provide enough "help" to skip that stage unless you are directly contacted by the founders
I would love to hear about “automated résumé extraction tools”, open source or cheap and easy cloud services, that might raise the bar here.
But at least at the moment, as far as I know, it is still reasonably common for non-PDF and even Microsoft Word only resumes to be requested. Less common than a decade ago, but still reasonably common.
BTW: PDF does NOT guarantee that your document will be rendered the same by all recipients. see for example https://www.prepressure.com/pdf/pdf-troubleshooter. The biggest issue is not having fonts embedded in your document (sometimes prevented by licensing issues), with page sizes and margins not far behind.
US versus ISO page sizes, anyone? Hint: often safest to render to the smallest page size; blank space at the end less objectionable than pages blank except for a few lines at the top. Also, while you may not have printer and/or paper to test both US and ISO page sizes, you can probably preview your résumé in other page sizes. be sure to do this from a PDF viewer, not from an actual word processing program. Unfortunately, There may be differences between different “send PDF to printer” tools for the same PDF - some may scale to fit by default, others may just wrap and produce orphans.