A friend of mine at MakerSquare wanted me to write this, because it may help give some perspective to more recent graduates, as far as their job search is concerned.
After graduation in late October, I got a few phone screens, but I didn't have a firm job offer (from Cycorp) until late November. I was neither the first, nor the last, in my class, to get an offer, but I was happy with it. But there were some things that may annoy job seekers: why does it take so french-frying long to hear back from companies just to get to the phone screen?
Here's why I haven't called you, if you've happened to apply to the job:
- » We got about 30 applicants for the position.
Of those thirty applicants, all of them had basic knowledge of web development - or at least claimed to on their resumes. But about 10 of them weren't really the skills we were looking for.
Some of them talked up how good they were with jQuery when the job posting specifically mentioned that we were "skeptical" of jQuery. We didn't knock anyone for listing jQuery as a skill, in fact I'd say it's required, just to understand DOM manipulation. But it was surprising how many people had a resume chock-full of jQuery. Now, if they sent us a resume full of jQuery, or full of PHP experience, or experience with the Microsoft .NET stack and wrote in their cover letters that they primarily used jQuery/Angular/PHP/.NET/whatever, then that would have been fine. What was suprising was the number of resumes sent without cover letters at all that were bad fits. These didn't take up much time, but they still had to be sorted through.
So that left us with about a third we put into a stack called "Promising." So what's up with that?
- » I can't tell how well you can code from your resume.
If you're in marketing, it's relatively easy to gauge your skill level. You provide 3-5 writing samples, have your resume up to date and bam, your potential employer knows what you're capable of.
For code, it's less simple. We need to do a deep-dive, and this often means looking at a portfolio, or even better, GitHub. I can't stress this enough: Showing me what you've done is way, way better than just telling me what you can do.
But it also means I have to actually look at the code. How many lines of code, and which lines of code did this applicant commit to this project. Is their code well organized and readable or is it indecipherable spaghetti? Do they get better over time? Do they take on different technologies, different frameworks, and different programming languages or do they just stay there, immobile?
I don't fine-tooth-comb everything, but I look for red-flags and green flags. Green Flags: Things like unit tests. Team projects (either OSS contributions or small teams). Red Flags: a 7000-line file called "MyApp.js". (Although a 7000 line file called MyApp.js followed by a well organized team project with unit tests shows me you can learn over time!)
- » The Catch 22: Engineers have to multitask when hiring.
Here's the long and the short of it: We're hiring another person because there's too much work for 2 JS Engineers. But the work still has to get done in the meantime. Right now, for example, I'm working on a major refactor of my project, and yesterday I did a 13 hour marathon so that we could send it off for testing today. Yes, Cycorp has about 50 employees, but only 2 JS engineers.
Skyler also has his own workload, of course, but more than that, he's been sick. Since Skyler has worked at the company longer and has more of an idea of what skills we need long-term, in many ways we've got to proceed through him -- and we just can't do that when he's sick. So our scheduled meetings to discuss applicants get postponed. Sorry. Not much we can do.
This is the crux of it: the more desperately we need your skills, the more pressed for time we are, and the less of an ability we have to hire.
If hiring takes 20 hours from start-to-finish, for example, and there's only two engineers on staff, that means each engineer has to find 10 hours or work an additional 10 hours in order to get their duties done AND hire someone. If there's 4 engineers on staff, that gets cut down to 5 hours; if there's 10 engineers, it's cut down to two hours.
Now, I have seen the opposite happen, where you apply on Monday, get a phone screen by Wednesday, they schedule an interview/code challenge for you on Thursday for Friday of next week... but those are usually development firms where there are about 7-8 engineers on hand. Even if it's just one senior engineer going through the whole process with the candidate, the fact that the senior engineer can spread out his/her workload a little more means that they have more time to hire.
- » Sometimes it just takes forever for no reason.
I'm going to give you an anecdote. In the last week of MakerSquare, we put out our first resumes. I remember joking with friends there about the crappiness of General Motors' application process but basically reasoned: "I'll jump through the hoops because there's probably a lot of good developers who don't, meaning less competition."
That was late October.
I got a call back from the GM recruiter, asking to set up a phone-interview, in mid-January. It took almost four months just to get to my name in the pile and give me a call.
I will say this though: While waiting for responses from jobs can be super-frustrating, it is a much, much shorter wait for engineers, simply because of the high demand. So take heart.