1

I was given a small project to complete over the weekend for an interview. Not a very difficult project at all. Fortunately, I was able to spend all my time designing, developing, and testing the application rather than having to research something I wasn't familiar with.

After working out a couple of critical bugs, I am left wondering if I should add anything more to the assignment. Assume, at this point:

  • everything is commented
  • no bugs found
  • any known exceptions are handled
  • 8 hours remain in allotted time

So, is it better to go ahead and submit a bug-free, working assignment earlier than the deadline?

...or ...Take the fully allotted time to add a feature (obviously something simple like logging)?

...or ...Provide a list of TODOs that could improve flexibility, scalability, or general usability? These would be improvements that simply could not be done within a day or could introduce too many issues to resolve in the time allotted.

FWIW: the project consisted of creating a multi-threaded sort controller implementing 3 different sorting algorithms; results to be displayed on WinForms UI.

| improve this question | |
  • 1
    Did you write the unit tests? – Martin York Jul 17 '11 at 16:28
13

What would you do if this was an actual project to be done for the company you are interviewing with? I would think it would be best to have bug-free code which implements 100% of the spec, plus artifacts (design docs, test plans, etc.) or suggestions for improvement. I think you idea of providing a TODO list is excellent - would show the type of value you would bring to the position, in addition to your pure coding skills - while also demonstrating you're not a "cowboy" coder who is going to freely extend or ignore the specs for a project. (Just my two cents)

| improve this answer | |
  • The assignment guidelines did give some leeway on additional features. I provided options to display sorted and unsorted results since loading a ListBox with 100,000 values is not a fast process. If this were an actual project, I would probably take the fully allotted time. Obviously, bug-free and implementing 100% of spec is first priority. In an actual project, you wouldn't go crazy with new or unsolicited features. – IAbstract Jul 17 '11 at 13:19
  • 1
    @iAbstract - If you are going to add an additional feature, I'd add paging to limit the results to N items starting from the Mth page of N items. That said, I think it's still better to give a 100% solution designed so that it would be easy to add your additional ideas without actually doing them. – unpythonic Jul 17 '11 at 15:16
  • 1
    @IAbstract: "In an actual project, you wouldn't go crazy with new or unsolicited features" and so you shouldn't in an interview assignment, because that might convey that you are a developer that freely extends the spec to his liking. Your idea of identifying possible improvements, whether in a todo list or some other format, is the way to go. – Marjan Venema Jul 17 '11 at 16:20
  • @Mark: I thought of the paging idea ...no doubt. It has been included on my project Fact Sheet: Enhancement Recommendations. – IAbstract Jul 17 '11 at 16:34
6

Do not add extra features, this will add risks to your successful delivery - don't jump over your head. Rather consider the following

  • Unit test your solution
  • Add BDD tests (like SpecFlow and Rhino Mocks)
  • Implement mutation testing
  • Add some documentation: how to start automated tests, how to tun exe and see what is going on, how to install etc
  • Add TODO
  • Describe limitations and known or predicted issues

Also, make sure you have implemented the task in a smart way.

| improve this answer | |
5

I'd go for the to do list.

This shows that you're thinking beyond the initial specification and are aware of what customers might ask for in the future and not just focusing on the immediate requirements and problems.

I'd also identify the areas of the code where you've made assumptions which could cause issues in the future if some new requirement came up or areas (such as logging) that are useful but not covered by end user requirements, or at least not directly by end user requirements.

These should give you topics to discuss at the next interview.

| improve this answer | |
2

No way! You finished your job before scheduled time and you're not informing your manager? That's totally irresponsible! There could be another task on project's critical path that's waiting for you!

So... what I want to half-jokingly say here is: don't wait until last moment. Double and triple check if your job fulfills the requirements, but do not extend the scope on your own.

And remember

“Perfection is achieved not when there is nothing left to add, but when there is nothing left to take away” – Antoine de Saint-Exupery

| improve this answer | |
  • Bonus point for quoting Saint-Ex to highlight your message, and a very good message it is. – Patrick Hughes Jul 17 '11 at 16:35
1

I would add UnitTests for each class.

Try and get 100% code coverage for each method.

| improve this answer | |
1

Under similar circumstances, I've always included unit tests. Apparently that's rare enough that both times I've had such take-home coding tests I was told that their inclusion made me stand out way ahead of other candidates. I wouldn't recommend adding features beyond the scope unless they make a big difference in the user experience AND don't detract from the core logic.

The only comments I added were explanations of why I chose a particular implementation over other alternatives, which is essentially how I comment in production code. (I might explain the performance tradeoffs, or that I chose simplicity over purity/raw performance/etc).

| improve this answer | |

Not the answer you're looking for? Browse other questions tagged or ask your own question.