| title | authors | intro | types | categories | published | updated | status | |||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
6½ tips for landing a developer job |
|
As I recently blogged, [right now is a great time ... |
|
|
2012/03/30 12:00:00 |
2012/03/30 13:00:00 |
archived |
As I recently blogged, right now is a great time to be a developer. Good people with good skills are seriously in demand by tech companies large and small. Of course, the best employers can still afford to be pretty choosy. Now, these days, I don’t recruit developers any more (so no CVs thanks). But I have been through many technical interviews on both sides of the desk, so I thought I’d share my tips on the process.
So how do you ensure that when your chance comes, you nail the technical interview first time? Here are my non-scientific, totally personal, 6½ tips for success:
1: Go in with your eyes open
When it comes to technical interviews and tests, don’t be afraid to ask the recruiter what will be involved. So many candidates think that they shouldn’t, that in some way it’s cheating. But the worst that’ll happen is that they won’t tell you. But if they do, you’ll already be ahead of the other candidates who didn’t.
2: Go public
If you don’t have a GitHub or public code account and you don’t blog, think about starting. It’s a great advert for what you can do and will give potential employers permission to believe you know your stuff. It can also give you something more to discuss at the interview. Also, if you know who’s interviewing you, check out what they’ve put out there, it may give you some valuable insights into what they might ask. Finally, just in case, take a look at your own social profile to see whether there’s anything that might need quietly erasing.
3: Don’t blag it
If you don’t know something they ask you, don’t be tempted to try to blag your way out of it. It. Never. Works. Of course, it might just be that you do know it really and you’ve just forgotten the syntax etc. In this case, write how you’d solve the problem in the real world. Write the code in pseudo code. And don’t worry, the actual work is often less complicated than the test.
4: The four pillars of object orientation
Write them down. Memorize them,. They are almost always on the test. (Don’t ask me why.) Just in case you need a refresher, they’re here. Also it might be a good time to read through a design patterns book too, particularly if you don’t come from a computer science background.
5: Knowledge is power
In addition to checking out the interviewer’s code, try to find out as much as you can about the wider team. Check out their LinkedIn profiles. See who works with who. Find out if you have any shared connections (it a small world, there is a great chance you will have mutual developer friends). Can you discover what bug tracking software they use, what IDE, what servers and, if it’s not Microsoft, what OS? All of this can help build up a picture of the company and what it’s going to be like working for them. It could also give clues about what questions they might ask. Then, even if you have no experience with the systems they use, at least you will have had a chance to read a bit about it before the interview.
6: Learn to be lateral
Tech companies want to hire problem solvers. People who can think laterally and creatively. So they like to hit candidates with a few off-the-wall questions. For me, it was: How many golf balls will fit into a double-decker bus? And how would you Move Mount Fuji. Now, the thing is, there are a bunch of books that cover these kinds of questions. Fortunately for me, my interviewer got my question from How Would You Move Mount Fuji? a book I’d read as part of my prep. He thought my answers were very insightful.
**6½: Finally... **
Show up on time, wear clean clothes, be interesting (but not odd) and don’t bring a pet.
Good luck.