4

While as a potential job seeker it is probably advisable to do every interview you get, is it worth treating interviews where you get a coding project with the same priority as an interview where you get asked questions by some panel of interviewers?

The reasons are as follows:

  • Coding projects tend to take a long time to complete (some of them can take a few days to a week), as opposed to conventional interviews where you can get done in an hour or two. This does not hold in cases where you have to go for full day interviews.

  • In terms of salary, if the potential jobs pay a similar salary, is does not seem worthwhile to persue the coding project style interview.

I do acknowledge the merits of coding project interviews, such as you'll get a good sense of the candidates coding style and whether the candidate would be a good fit. It is more from the interviewee's perspective. Is it not better to

  • Fail fast with many short interviews than fail on a project style interview?
  • Do shorter interviews first before persuing longer interviews?

While it does seem open ended, the focus on the question is around effective utilization of one's time and effort when job hunting (because it tends to take leave days, sick days for some, travelling).

Improve this question
11
  • 2
    I assume you'd be getting paid for a coding project at your standard rates?
    – Andrew Walters
    Commented Jul 17, 2014 at 12:37
  • 9
    My experience showed me companies practicing good test exercises tend to eventually have significantly more skilled software developers than companies practicing personal interviews only. The reason is simple - lot's of so-so developers can pass a personal interview but will fail in a simple test exercise or wouldn't even bother doing one. Which could be one of the goals, I assume - filter out those not willing to bother, not enjoying some extra coding. I always enjoyed having these test exercises and always learned a lot during the process, never questioned "should I" if exercise was good.
    – Evgeny Goldin
    Commented Jul 17, 2014 at 13:10
  • 2
    I've only had 1 "coding project" interview. If you do it well then the interview can end up being just a formality, which happened to me. They already had an offer prepared before I even arrived at the interview. So if you are confident in your skills and are sure that they will reflect well then by all means the "coding project" interview is worth your effort. If you aren't too sure your work reflects well or aren't going to put in the effort to ensure it does then don't do it. You'll be judged by what you submit and if it isn't a fine example of your work then don't do it.
    – Dunk
    Commented Jul 17, 2014 at 21:56
  • 2
    @Dunk, I've actually been told after an 'interview project': "Great job! You're hired! Oh, wait, the boss wants us to do an interview, don't worry it's just a formality." After the in-person interview, though, I was told I wasn't a 'cultural fit'.
    – James Adam
    Commented Dec 17, 2014 at 17:47
  • 1
    @James:So the coding project did work for you. However, there is quite a lot to be said for 'cultural fit'. It isn't all about your technical skills. If your personality/style is going to cause friction on the team or your preferred methods don't match the company methods and there's an inkling that this could be an issue then it is better for all that you weren't hired. Low morale can kill a project just as much as low skill.
    – Dunk
    Commented Dec 19, 2014 at 15:49

11 Answers 11

Reset to default
12

As someone who's been on both ends of this process I fully endorse a coding based interview process.

Some people are exceptionally good at the more traditional panel interview but actually mediocre or even poor developers.

Others (I consider myself in this category) do not 'interview well' but, I like to think, good at what I do for a living.

Ultimately, I want to hire good developers, not good salespeople. If you're being asked to complete something that exceeds say 8 hours I'd be wary though. We usually, depending on the seniority of the role we're trying to fill, set a limit of 2hrs/4hrs/6hrs or 8hrs.

From our perspective this is typically proportionate to the amount of time that you'd expect someone to invest in researching the company, preparing presentations or any other preparation necessary for a traditional panel style interview.

Improve this answer
1
  • I second Clair on making sure to limit the time commitment an coding interviews, there's been a number of scumbag companies of late who have you do bits of work they need done with zero intention of hiring you. :/ Most coding interviews will be something pretty straight forward. (I have several train stops, make a program that can tell me X, Y and Z based on these stops) then they'll ask questions about why you coded it the way you did, pros, cons, things you could have done better, etc. (basically the sort of thing covered in a code review)
    – Eric J Fisher
    Commented Dec 17, 2014 at 17:14
7

If a coding project takes days to a week to complete, do you think you should be spending days of your valuable time working without any compensation? Does the company think you should be spending days of your valuable time without compensation?

I'd just ask for compensation. If they think you should spend days of work without any payment, then they failed the interview from my point of view.

Improve this answer
0
6

In terms of salary, if the potential jobs pay a similar salary, is does not seem worthwhile to pursue the coding project style interview.

I assume the "coding project style interview" doesn't consume months of your time. Thus, you aren't really talking about a huge trade-off here. I'm also assuming that you have at least some insight into the desirability of the position, and your fit in the company, before you are asked to spend time on the project.

We all get to decide if what is being asked of us during the interview process is "worth it" or not. That's a very personal decision. That's a decision that only you can make.

Some people wouldn't be willing to spend more than an hour or two interviewing. Others are willing to devote more time.

For me, I will only interview for jobs that I think will be very much worth having. Consequently, I'm willing to show a fair bit of extra effort in an attempt to convince the potential employer that I'm a good fit for the job.

I've sought jobs where I've had multiple days of interviews with several levels of management. I've sought jobs where I had to prepare and conduct a presentation in front of a panel. I've sought jobs where I had to interview at two different locations on the same day. I sought one job where I was asked to perform some real work (but on my own time) before being hired. I accepted those conditions because I felt that the potential jobs made the effort worthwhile.

Maybe you aren't pursuing really good jobs, so the interviews aren't worth much of your time. If that's the case, then ignore all the jobs where you have to expend any effort in the interviews and hope for the best. Otherwise, a good job is worth a bit of effort, so extend yourself and follow their requirements. Knock the coding project out of the park and get the really good job. In the overall scheme of things a few extra weeks of work are very minor.

Note: My answer assumes ethical behavior on both sides. Whenever there is illegal/unethical behavior, then this answer may not apply.

Improve this answer
1
  • We're actually having problems in my area where some really despicable companies are giving people "coding projects interviews" with a potential above average salary position as bait. They just take some of the smaller projects they need done (a few days to a week) get the person to do it, then say "sorry we went with someone else" without hiring anyone) essentially they are getting free labor. I know one or two places got in trouble for it, but it's to the point we have lawyers advertising specifically to handle these cases because it's getting out of hand :/
    – Eric J Fisher
    Commented Jul 17, 2014 at 14:19
3

You should apply based on how much you want the jobs themselves not the steps required. If you REALLY want a job, you should do what it takes. If a job isn't all that interesting to you, even a small interview may be too much time wasted and may only be of value as a "practice". Also, consider that what you are saying means that the more demanding the interview process, the more people like you decide not to apply for the job. Therefore, on paper, jobs with more demanding interviews might provide you a higher probability of getting the job since there is less competition.

Improve this answer
1
  • Yes doing 100 interviews in as little time as opossible might get you a job, doing the interviews for the jobs you genuinely are interested in no matter what that takes may result in fewer interviews, but is more likley to result in a job you want instead of just a job. I know which of those two options appeals to me the most.
    – HLGEM
    Commented Jul 17, 2014 at 13:53
1

What makes you think that coding projects and panel interviews are mutually exclusive? Especially since coding projects and panel interviews test different aspects of your ability.

My best guess is that the more high;y compensated the position and the more senior the position, the more thorough the vetting is going to be.

Who you want to work for has a direct impact on who you want to interview with, and who you want to interview has a direct impact on your time line. And the impact on your time line has a direct impact on how you budget your time.

Your preferences as to whether you prefer coding reviews or panel interviews are irrelevant to a prospective employer. Because the coding reviews and the panel interviews are about the prospective employer's wants, needs and preferences not yours. The reason you are involved at all is that you are trying to convince the prospective employer to hire you.

Improve this answer
1

First, I completely agree with you that coding a project is probably the best way to screen an applicant.

That being said as an interviewee, you must be conscious of how much respect the company is willing to give you during the interviewing process.

Too little respect, and they're probably not interested, or they probably already interviewed someone last week that they hope will accept their offer. Too much respect, and that can be a red flag too. Ideally, you should be looking for an equilibrium.

Personally, I don't like to be given a simple coding project to do over the weekend. Usually, that means that they'll expect me to work the entire weekend on it, even if the project is supposedly very short and super simple. The very fact that they give me an entire weekend to work on it means that such a project becomes open-ended by its very nature, and it doesn't prove that I actually coded the project (because for all they know, I could have just hired someone else to do the project for me).

So if the interviewer tells me that the project is super simple and it's supposed to take less than two hours (for the right candidate, hint, hint), I'll usually take them at their word for it and demand that I code the project right in front of them in no more than two hours.

And no, it doesn't mean that I am supremely confident that I'll finish in less than two hours, it just means that I'll give it my best shot for two hours, and that after those two hours are finished, I'll put my pen down, letting the chips fall where they will.

This demand has several effects on the interviewer. It communicates the value I have for my time to him. And it makes the coding project itself (as well as the interview process) much less formal and more fluid. Not only that, but since the exchange is much more conversational, then I can show him the demo and the code of other projects I've written (that I'm much more confident that I can talk about). And if the exam/interview goes well, the original agenda becomes supplanted by my own agenda and by my own enthusiasm about my past projects.

Improve this answer
0

Personally, I enjoy a challenge so I would do both, standard interviews would take priority and if I have time I would entertain the coding exercises. By doing the exercises hopefully it would spark an intelligent conversation between you and the interviewer and you could get a better feel for what THEY expect and how THEY do things. You could compare notes and possibly find out if they are doing things you do or do not like before getting on their payroll. Another thing to consider is hopefully others on the team have had to perform the same or similar exercise and have passed it which can give you a sense of comfort that you will be working with a skilled team of engineers. If you have the time I say go for it, if you don't just stick with the standard interviews. Just make sure you come with your own set of questions as well in either regard because the interview process is a two-way street. The more companies I work for the more things I realize I do and do not like and I make sure to filter companies out based on my past experiences and future expectations.

Improve this answer
0

As was mentioned in an earlier answer, these are not mutually exclusive.

My "ideal" interview (and now that I'm in the other chair, it's something I'm trying to implement) is to screen an applicant based on the following items:

  1. Experience. Go over the résumé with the applicant and if they say they've done stuff with technology X, ask a pointed question about technology X to make sure they didn't "pad" their resume.

  2. Panel interview. Here I'm asking mainly technical questions that are theory based to make sure the applicant knows what they are talking about. Also, it's a great way to assess the applicant's personality. I want to make sure they aren't a jerk or racist.

  3. Tour of the facilities and project overview. Show them what they will be working on. An interview is a two-way street and they should see the project first hand to help better gauge their interest in the position. Nothing is worse then having to restart the hiring process after someone leaves in a month after realizing that they are more passionate about something else and we didn't do a good job explaining what they'd be working on.

  4. Code. All applicants have to write code, but it should be short and sweet to help determine if they really know what they are doing. The question should take no longer than half an hour to complete and maybe you can allocate a whole hour. The panel will then (after the candidate has left) do a code review and see if the candidate is worth keeping on.

I think this way, it covers alot of bases and makes sure that the candidate is competent, would mesh well with the team, and also interested in the position and company.

Improve this answer
0

Ask yourself two questions:

  1. How well off am I for job offers?
  2. Is my code a selling point?

If you're an experienced developer with offers coming out of your ears and the phone ringing off the hook, then you probably don't need to bother investing a bunch of time on a coding exercise. You might make an exception if you really like the sound of the job, but you've got enough offers to choose from that you don't need to invest your time if you don't want to.

If you're more junior, and you need the opportunities - then is your code a selling point? Will the interviewers read it and see potential or will they run a mile? Do you structure things logically, comment things sensibly, employ best practice and generally write good, clean, well-designed code?

Finally, consider that they'll probably make you write code at some point in the interview process. I personally prefer being able to write things at home in my own time and with access to Google and a compiler, rather than sweating in front of a whiteboard with everyone looking at me. Other people will prefer to do it on the whiteboard where they can talk to actual human beings and aren't going to be judged on every misplaced comma. Think about which option would work better for you.

Improve this answer
0

These "preliminary tasks" are probably low level filters and completing them does not add much chances as all reasonable competitors also complete them. The real selection happens later, during the real interview, when you usually discover that employer expects much more than basic programming skills.

A a result, such job offers do not deserve much priority and should be seen like any others. May make more sense to submit "cheaper" applications first.

Improve this answer
-1

It is definitely worth it. Look at it from other side - the way how they handle the test project for you they probably handle their projects. That way you can get better understanding of the company in terms of:

  • Documentation
  • Requirements
  • Translating requirements to a developer
  • Expectations
Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .