27

I recently had a phone interview with a company. After that phone interview, I was told to complete a short programming assignment (a small program; shouldn't take more than three hours). I'm only directly instructed to complete the assignment and turn in the code. I was given complete freedom to use any language I wished and was not told exactly how to turn in the code.

Immediately I planned on throwing it on Github, writing a test suite for it, using Travis-CI (free continuous integration for public Github repositories) to run the test suites, and using CMake to build the Linux makefiles for Travis-CI. That way, not only can I demonstrate that I understand how to use Git, CMake, Travis-CI, and how to write tests, but I can also simply link to the Travis-CI page so they can see the output of the tests. I figured that'd make it a tiny bit more convenient for the interviewer.

Since I know those technologies well, it would add essentially no time to the assignment.

However, I'm a bit worried that doing all this for a relatively simple task would look bad. Although it wouldn't add much more time at all for me, I don't want them thinking I spend too much time on things that should be simple.

DormoTheNord
  • 942
  • 7
  • 14
  • 5
    I would be careful putting answers to interview problems on github, as some companies like to keep their problems confidential. – Scroog1 Jun 19 '13 at 11:20
  • 7
    The questions are publicly available on their blog (they sent me a link to the blog post), so I don't think they're concerned with that. – DormoTheNord Jun 19 '13 at 11:24
  • 3
    @DormoTheNord I'd say you are not over-engineering: having a good development process is something entirely different from over-engineering, and is (IMO) a good sign. – K.Steff Jun 19 '13 at 12:29
  • 3
    I'd spend some of that extra time documenting any gray areas in the problem specification, assumptions, limitations, ... . Show that you don't just dive in coding, but contemplate the problem and its context. – HABO Jun 19 '13 at 12:53
  • @HABO I figured that would be another benefit of throwing the code on Github since I could document that in the README file. That way it would be cleanly displayed with the source and it wouldn't clutter up the email. – DormoTheNord Jun 19 '13 at 13:26
  • 1
    That's not overengineering. Usually I have a "seed" project that I use for my own work/experiments. It contains Vagrant (VM Manager) setup for OS with nginx and Jenkins and code coverage installed on it. I don't even know how to program without unittests and test coverage any more… – David Sergey Jun 19 '13 at 14:10
  • 4
    @DormoTheNord The questions may be public, but your answers will be, too. It'll be available to other interviewees, if they can find it. _That_, they probably will not like. – Izkata Jun 19 '13 at 18:02
  • 1
    I'd be happy to see a candidate that is fluent in all the required tools! Just be careful that you really solve the problem. If you spend your time on using the tools and don't provide a correct solution, you'll make an impression of a person who doesn't know how to solve the problem and tries to hide it this way. – Petr Jun 19 '13 at 18:54
  • Ask them what they want exactly they want. IMHO you should focus on the solution to the problem and not the tools, it's straightforward to learn to use these tools. – nikhil Jun 24 '13 at 21:15

7 Answers7

29

As an interviewer I would be happy to see the knowledge of the process of developing software demonstrated by this approach; as opposed to just the writing of the code.

In particular, having a test suite for even very simple problems would be a good sign (even FizzBuzz level). I've seen candidates submit solutions that didn't even solve the problem and a simple set of tests would have shown them this. Also, having the commit history allows me to get an idea of the thought process that the candidate has used to get to the solution.

On the other hand, I have known people to be rejected by some companies at an early stage of the process for over-engineering. However, in most cases, this has been due to over-engineering of the solution not necessarily the processes used.

Scroog1
  • 1,115
  • 8
  • 9
  • 2
    Would you go so far to say that if a company rejected me for doing what I plan to do, it would be a sign that the company doesn't respect software development methodologies and that I'd rather not work for that company? – DormoTheNord Jun 19 '13 at 11:40
  • 7
    I wouldn't necessarily go that far, as there is a certain amount of luck involved (unfortunately). You might get the one interviewer who didn't like that approach; or they might be in a bad mood that day and not want to look through the extra data provided by this approach. That said, there's usually no harm in clarifying the level of detail they want. Also, asking one or two clarifying questions can be a good sign to the interviewer too (though not continuously bombarding them with uninformed questions, obviously). – Scroog1 Jun 19 '13 at 11:47
  • +1 - as long as you're not detracting from the solution, I would want to see unit tests and whatever else you do without prompting. – Telastyn Jun 19 '13 at 14:11
  • 1
    The too much to look through risk could be mitigated by sending both a base github link, and a link directly to just the source code for the test for the lazy/busy. – Dan Is Fiddling By Firelight Jun 19 '13 at 18:51
16

Having as an interviewee someone who understood things like version control, CI, unit testing and the like would be a step up on what I usually see.

Although, for me, the most important thing is that the problem is solved, and solved well, knowing that the candidate understood ways to improve the quality of their deliverable would definitely get my attention.

What I generally see is people who not only didn't understand the problem, but who also didn't understand how to go about solving the problem - and they'd get ignored no matter how many extra tools they used in the process.

Steve Hill
  • 660
  • 4
  • 15
6

Keep in mind there's a time limit on it. The interviewer knows this, so this means (if I were the interviewer) he will see you not only solved the problem within the alotted time, but did it so quickly you had time left over for gold plating, which is a good sign of your problem solving abilities as well as your appreciation of rigor and diligence.

Over-engineering is a bad word when you're creating AbstractFactoryManagerAdaptors that get plugged in to hand out BuzzManager and FizzManager just to solve FizzBuzz.

What you are doing is over-diligence, which isn't even a thing (though under-diligence definitely is).

That said, if you end up over time or with some half-hacked solution because you used your time on the extras which you claim "add no time at all", this will look as though you have very poor understanding of how large appearingly small tasks can be. This can be a dangerous attribute in an engineer and all-too-common among juniors. Prioritize appropriately and do the extra-credit stuff only after completing the required solution.

Jimmy Hoffa
  • 16,039
  • 3
  • 69
  • 80
  • There is no hard time limit, but just a note saying the assignment shouldn't take a decent programmer more than three hours. Would they really check my git log to make sure that I only spent three hours on it from commit #1 to the final commit? – DormoTheNord Jun 19 '13 at 14:30
  • 2
    @DormoTheNord if there's no time limit then time not spent on the requested solution may be viewed as poor prioritization. Unfortunately engineers are all independent thinkers and thus have their own opinions on these things from one to the next, in cases like these it can be luck of the draw whether the person reviewing what you did is the sort to see it that way, or the sort to see it as a big boon. I've known great engineers of both bents. It comes down in these cases to what you value, display that and someone who values the same as you will appreciate it, that's who you want to work with. – Jimmy Hoffa Jun 19 '13 at 14:33
  • This is what I hate about job interviews... the luck involved in pleasing the interviewer's personal preferences. [Maybe it should be standardized](http://xkcd.com/927/) :) – DormoTheNord Jun 19 '13 at 14:41
  • Don't worry, the luck will even itself out over your career. You just need to be lucky about when you get the good luck and when you get the bad :) – Scroog1 Jun 19 '13 at 14:50
  • 1
    I'd be careful in describing it as 'gold plating' because that term is usually assumed to be a bad thing: http://en.wikipedia.org/wiki/Gold_plating_%28analogy%29 – whatsisname Jun 19 '13 at 15:31
  • @DormoTheNord I would tell the interviewer how long you spent on the exercise (and make sure it's less than 3 hours). Fears about gold-plating should not arise if you do the exercise in the time they are expecting. – MarkJ Jun 19 '13 at 16:20
6

Another view to consider is that your approach is neither good nor bad. I can imagine interviewers who would consider it too much and I can imagine interviewers who would love even more engineering.

Don't worry so much. Instead, solve the problem in the way you consider best and you'll likely receive job offers from people who agree with you. That's a great first step toward a productive work environment. Remember, interviews go two ways. The interviewer's response to your solution will tell you a lot about them as well. Do you really want to work with people who believe your development instincts and philosophy are wrong?

Corbin March
  • 8,104
  • 3
  • 37
  • 39
3

In reality, nobody cares if the candidate can whip up a git repo or create makefiles in a hurry, because that is just recall of what he or she learned by rote. These are secondary skills to the actual problem solving and design aspect of the interview question.

So yes, your intuition is spot on that it potentially looks bad, because it may look as if the candidate believes that someone who can regurgitate a few memorized commands and patterns to create a project skeleton has impressive software skills.

The test suite aspect of the solution is good though. Delivering an answer with a regression test suite will probably earn your points. All the more so if your test suite exercises the salient cases in the code. The test suite doesn't have to have a lot of formal trappings and rely on tools; just the fact that you somehow have one in there is good enough for an interview. It's more or less obvious that if you can put together some ad hoc unit tests in an interview quiz, you can do that with tools on a real project.

Kaz
  • 3,572
  • 1
  • 19
  • 30
1

I recently had a phone interview with a company. After that phone interview, I was told to complete a short programming assignment (a small program; shouldn't take more than three hours).

I'd proceed with caution. Evaluate the relevancy of the challenge to the job, and be sure future reimbursement from the employer will make 3 hours of your time worthwhile.

I question the value in these types of tests, and would rather judge someone on their past accomplishments. A predefined short task can not tell the employer anything about what you can do. Only what you can not do, and that can quickly be determined with a few questions over the phone.

Testing does have it's place. Ask yourself the following questions about the test, and respond accordingly.

  1. Is the test fair given your current career level?
  2. Does the test have a clearly defined correct answer?
  3. Does the interviewer have an interest in your potential as a person or are they showing more interest in the test results (i.e. hiring agencies are terrible for this).
  4. Does the test represent the kind of work you would enjoy doing or is it an ambiguous skills verification (i.e. test if you know Java syntax).

I'm only directly instructed to complete the assignment and turn in the code.

You've just answered your own question.

Immediately I planned on throwing it on Github, writing a test suite for it, using Travis-CI (free continuous integration for public Github repositories) to run the test suites, and using CMake to build the Linux makefiles for Travis-CI.

No, that's not what they asked you to do.

That way, not only can I demonstrate that I understand how to use Git, CMake, Travis-CI, and how to write tests, but I can also simply link to the Travis-CI page so they can see the output of the tests. I figured that'd make it a tiny bit more convenient for the interviewer.

I'd be careful demonstrating skills too early or too late in the interview process. If you feel you didn't do well in the interview, and are now trying to compensate then it's not going to work. On the other hand, doing too much when not asked too demonstrates over eagerness. This could result in the employer countering with a lower wage offer then you were expecting.

However, I'm a bit worried that doing all this for a relatively simple task would look bad.

Yes it looks bad. Solving their challenge with one line of code will be far more impressive than a full flushed out project.

From my experience this is not how you win the job interview, but it's one way to lose the job. The code test is a quality control issue. Every company that uses code tests when hiring people is doing so, because previously they weren't using code tests. They had a bad experience of someone slipping thru the cracks of the interview process that should not have.

They will take your source code and pass it around the office. People will comment on it, and what you do not want them to say is "He made this mistake? but was spending time using Git, CMake and Travis-CI. What an idiot for missing this mistake."

That's it. You've lost.

They want to know you can code, because they can't teach you that. Git, CMake and Travis-CI can easily be taught.

Reactgular
  • 13,040
  • 4
  • 48
  • 81
  • 2
    @JimmyHoffa are you disagreeing with my entire answer or just my comments about testing? Maybe I failed to express my perspective correctly, or maybe not? For me, I value more the human component then a written test. A candidate that fails FizzBuzz doesn't prove anything for me. I have to talk to that person to understand why. but I do want to hire skilled workers (always). I just don't think go home write this test and come back. Is an effective way to do that. I'd rather ask the FizzBuzz question and watch them work it out. Do you understand? – Reactgular Jun 19 '13 at 15:48
  • 1
    @JimmyHoffa I think this comes down to the employers expectations for a hire. With that said, I'm swinging more to your side the more I read about FizzBuzz testing. A programmer who can't pass at any career level has issues. I'm just not sure if this kind of testing is the same as the OP. See this related question: http://stackoverflow.com/questions/117812/alternate-fizzbuzz-questions?answertab=votes#tab-top – Reactgular Jun 19 '13 at 16:02
  • Simply put, I'm a fan of strenuous interview processes, and candidates who attempt to go above and beyond (without compromising the core requests; otherwise they're prioritizing their time poorly). Your entire answer seems to speak out against both of these things. – Jimmy Hoffa Jun 19 '13 at 16:08
  • 1
    http://thecodelesscode.com/case/23?topic=elegance – Jimmy Hoffa Jun 19 '13 at 16:10
  • @JimmyHoffa I think my attitude comes from freelancing in the creative field where clients often ask a vendor to complete creative work or tests as part of their pre-work bidding process. I don't do that kind of work, because if I spent hours on every prospect I'd get no billable work done. When I told the OP to proceed with caution it was in the hopes of keeping him from wasting time. The OP wanted to invest time in doing a lot of extra work. It's a temptation but is the payoff worth it? Maybe, but the OP didn't clarify this. It could be short term contract work. – Reactgular Jun 19 '13 at 17:06
  • Fair point, in contract work I 100% agree with you. When courting an employer you wish to join and invest 40 hours a week for the foreseeable future with, the calculus changes. I didn't think of the short-term possibility of this however. – Jimmy Hoffa Jun 19 '13 at 17:24
  • @MathewFoscarini I should have made myself more clear. It sounds like you think the assignment is a strange trick question. It's not. The assignment is to write a relatively simple application that will supposedly be judged according to how well the code is written. – DormoTheNord Jun 19 '13 at 19:33
0

I think that your approach is neither good nor bad per se. I would ask the interviewer if it's ok to use Github and the other tools. As @Izkata pointed out in the comments, you are making your solution public.

As an interviewer, I known there's usually no harm in the candidate trying to clarify a few things. Also, asking one or two questions can be a good sign, as you don't rush to do things that you didn't understand.

Remember, though, that the most important thing is that the problem is solved, and solved well. In that regard, everybody agrees that a test suite helps. But, for that, maybe you just need to send a couple of test classes together with your project/solution.

Hbas
  • 544
  • 2
  • 9