6½ tips for landing a developer job


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.

Comments (13)

  1. Ramdas says:

    Nice article, to the point. Need to explore GitHub.

  2. Doney Abraham says:

    Great article. Plain, simple up to point.

  3. Raymond Dalton says:

    Ask the recruiter what % of your time will be spent using certain tools or performing certain activities, for instance: 50% visual studio, 35% SQL, 15% design, project management and other.  Most companies can and will supply this information.  Sometimes companies ask for Linux experience, but they have one server that you never touch, so talking up your Linux experience won't do you any good.  Just because something is on the desired skills list doesn't mean that it is important.  The more you know about what they use/do every day the better prepared you will be for answering questions in a way that will excite them about finding a good fit.  Oh, if 35% of your time will be spent working with SQL, and you don't know SQL then please don't apply for the job.  It is really annoying when 5 minutes into the interview it is obvious that the person should not have gotten through screening.

  4. AbitOWhit says:

    So how do you move mt fuji?  

    I say, that since it is an active volcano, you simply put a hot air balloon above it… Hardest part though would be steering it.. but that would be Support's job and not Engineering's… :)

  5. I got the Mount Fuji question once, several years ago. I replied with the question: *Why* would you move Mount Fuji? Any team of mine will only commence a task when there's a clearly defined business case with measurable objectives and a worthwhile end-benefit.

    As it happened I got offered the job (but had already accepted another, better, job offer that morning and was just going through the motion of the interview)!

  6. During my 30 years working as a scientist in an industrial research lab, I dealt with variations of the Mt. Fuji question quite a few times. Typically a request from a manager/visionary who did not have time to be concerned about the technical difference between (the analogs of) moving the mountain, moving the camera, and digitally manipulating the image to change the perspective. It was helpful to think that selection pressure strongly favored filling that manager's job with someone having that manager's personality. My most productive colleagues were able to transform the question into something consistent with the laws of physics without killing the funding.

  7. Thanks for this posting!  Great advice – I am just starting a Web Dev program at my local community college (changing careers) and even though I have a long way to go, I often read the job listings to get a feel for what companies are looking for right now.  Thank you!

  8. If someone would ask me how to move Mt. Fuji I would simply reply: “Take a picture, use some GIMP/Photoshop magic and land it in The Bahamas”.

  9. Ashley Sheridan says:

    If I got asked how to move Mt. Fuji at a job interview, I'd not consider taking the job. It's a pointless question with no correct answer and does little to indicate your skill at solving the kinds of problems you'll actually experience in the job (and I don't know of too many developer jobs where you'd be required to move mountains)

    If the questions were geared towards real scenarios I'd be able to tell that the interviewers actually cared about the interview process and how I'd really respond. If it's a situation that's actually occurred at that place of work then even better. Those ridiculous questions might seem fun and quirky, but they're a waste of time in an interview; time that could be better used to talk a little bit more about actual experience with solving problems, or anything that will actually be useful in the job.

  10. thebeebs says:

    Ashley – I completely disagree. Asking a person any question and hearing what they say exposes their thought process and personality. Questions like Mt Fuji of course have no real answer but they often get conversation flowing.

  11. *tc says:

    It appears that Ashley "did" answer the Mt Fuji question, to TheBeebs' point. BTW: I agree with Ashley on the non-sense. If asked that question, it would answer one for me; whether or not (NOT) I wanted to work for this person.

  12. Shailesh B. Davara says:

    I like Point 4 "The four pillars of object orientation". Its very basic and it should be clear all the time. there is no replacement of it either of language or platform you use.

  13. Harsha says:

    I going to surely follow them for my next interview. thanks for sharing.