Comment Re: Finding a Job (Score 1) 479
I have some advice for you - but first, I want you to know where this advice is coming from so you can decide what to make of it (if you don't care, skip the rest of this paragraph). My situation is almost the opposite of yours - I have no formal qualifications in programming, yet have been seemingly quite adept at getting jobs when I want them. Since the start of my career (which was through a lucky break) I've had two periods of searching for another job, both of which have been successful in that I've received offers for companies I would have been happy to work for. This isn't a *lot* of experience, but in total I've been for, say, around a dozen interviews and received job offers for more than half of them, and my application/interview ratio is not far off. I am in the UK and generally apply for embedded positions in the north of England, from embedded Linux applications down to bare metal firmware/OS work, if that makes any difference.
The first thing I'd say is that, from what I can see, employers are mostly interested in what you can get done. Nobody cares about my lack of qualifications - or your abundance of them - but some may perceive you as being used to an ivory tower where things are never quite complete and you're always "in the middle of something", so you need to convince them that you can design, write and test* real software that solves real problems. If their problem is in your research domain then you're already most of the way there, otherwise you should do your best to include experience of real software you've written - it doesn't matter what software, just show you can deliver *something*. Put your practical experience first. This includes both your hobby projects (label them as such and they're worth ten times as much as if you'd written them for an employer) and software you wrote in your job before your PhD. Anything that involves interaction with customers/keeping them happy is also a big plus.
The bottom line is that these companies will pay money to people who can solve their problems, and their problems always involve needing to get software out the door. Show them you can do that, and you're in.
The second thing is to be personable and friendly. I've met some people who seem to think that employers expect programmers to be super-nerds - they lean towards emulating Sheldon Cooper. Companies don't want a bunch of Sheldons working for them (can you imagine that? I wouldn't work there...), they want a bunch of regular folks who can get along with each other, communicate well and write kick-ass software along the way. In fact, during my first job hunt I was quite confused as to why so many recruitment agents were so eager to talk to me on the phone (don't they know how to use e-mail?) until one of them pointed out that speaking to someone, even for a minute to say you're about to send them an e-mail, lets them know if a person is pleasant to talk to and can communicate. They've told me there are people they wouldn't even put forward because they seemed too nerdy, despite their credentials. So don't try and be a super-nerd; being affable is equally as important as knowing your shit.
And last, I don't know what answers you give to questions like "name all the STL containers" - that's a dumb fucking question and the best-case scenario is that the company is shit-testing you to see if you'll call them on it and say "of course not, bitches" - but in general you should be absolutely, brutally honest about what you don't know. An answer that starts off with "I don't think I could name them all, but I guess some that come to mind are..." is several orders of magnitude** better than one that ends with "...um, I think that's all of them?".
* That's the single most important word in this whole rant. Seriously.
** Not an exaggeration.
The first thing I'd say is that, from what I can see, employers are mostly interested in what you can get done. Nobody cares about my lack of qualifications - or your abundance of them - but some may perceive you as being used to an ivory tower where things are never quite complete and you're always "in the middle of something", so you need to convince them that you can design, write and test* real software that solves real problems. If their problem is in your research domain then you're already most of the way there, otherwise you should do your best to include experience of real software you've written - it doesn't matter what software, just show you can deliver *something*. Put your practical experience first. This includes both your hobby projects (label them as such and they're worth ten times as much as if you'd written them for an employer) and software you wrote in your job before your PhD. Anything that involves interaction with customers/keeping them happy is also a big plus.
The bottom line is that these companies will pay money to people who can solve their problems, and their problems always involve needing to get software out the door. Show them you can do that, and you're in.
The second thing is to be personable and friendly. I've met some people who seem to think that employers expect programmers to be super-nerds - they lean towards emulating Sheldon Cooper. Companies don't want a bunch of Sheldons working for them (can you imagine that? I wouldn't work there...), they want a bunch of regular folks who can get along with each other, communicate well and write kick-ass software along the way. In fact, during my first job hunt I was quite confused as to why so many recruitment agents were so eager to talk to me on the phone (don't they know how to use e-mail?) until one of them pointed out that speaking to someone, even for a minute to say you're about to send them an e-mail, lets them know if a person is pleasant to talk to and can communicate. They've told me there are people they wouldn't even put forward because they seemed too nerdy, despite their credentials. So don't try and be a super-nerd; being affable is equally as important as knowing your shit.
And last, I don't know what answers you give to questions like "name all the STL containers" - that's a dumb fucking question and the best-case scenario is that the company is shit-testing you to see if you'll call them on it and say "of course not, bitches" - but in general you should be absolutely, brutally honest about what you don't know. An answer that starts off with "I don't think I could name them all, but I guess some that come to mind are..." is several orders of magnitude** better than one that ends with "...um, I think that's all of them?".
* That's the single most important word in this whole rant. Seriously.
** Not an exaggeration.
