mathatoms

This article seems to have an assumption that companies have this huge pool of qualified candidates applying for jobs and you, as an applicant, just need to show that little extra initiative to beat out the other applicants. As someone who has reviewed mountains of resumes for a large company, this assumption doesn't match my experience.

In my experience there is this huge pool of unqualified applicants applying for every job no matter what the actual job requirements are. The applicants that got a call for an interview 1) looked at the technologies listed in the job requirements and 2) put their experience with these technologies on their resume.

Also important, once you get called in for an interview make sure you can answer the most basic questions about what is on your resume. If you put Linux experience on your resume make sure you can explain how to list the contents of a directory from the command line. If you put MySQL experience on your resume make sure you can explain how to get a count of the total number of rows in a table.

Are there really companies out there where the difference between getting an offer and not getting an offer is spending a few hours making a bespoke "please hire me" website?

I think point 2 is really important. I've worked with a lot of new hires, especially college interns, and some of them are deathly afraid of coming in on the first day and messing something up. I always put together a getting started page on whatever wiki we happen to be using that details how to get the development environment up and running on the first day. Since the development environment changes as our code matures (new libraries to build against, new repos to check out, etc) following the wiki never seems to just work for someone unfamiliar with the dev environment and they encounter problems or just have questions. Whenever someone has a problem or a question the solution should be documented in the wiki, so we have the new hire update the getting started wiki as they go along. This gets them a little more comfortable making changes (since they see the whole building didn't burn to the ground after making a wiki update) and gets them in the process of documenting any problems or questions.

We have enough storage to hold on to the data. We keep the data around so we can retranscribe files as we update our language models.

We were planning on writing up a blog post to go over what our backend looks like. But essentially we have written a crawler to discover audio on the internet and a distributed processing framework to download, extract metadata, and transcribe the audio.

We've iterated through a few storage solutions and have settled on using GlusterFS+zfs running on Storinators. So far we have about 350TB of data indexed in our collection.

Thanks. Its English only for now. We could support other languages if there is a large enough demand.