The Workplace Stack Exchange is a question and answer site for members of the workforce navigating the professional setting. It only takes a minute to sign up.
Sign up to join this community
Recently I applied for Software Development position at a company that requested a sample project for the first step of the interview.
Since this project is a small sample, it seems overkill to use the many elaborate tools and methods available at my disposal (which are usually used for medium to large projects).
The question is, should I go out my way to use these methods and tools to show that I can use them?
Why are you directing this question to us, and not to them? We are not the ones who commissioned this project, and we are certainly not the ones who are evaluating whether you completed this project in a satisfactory manner, If I were the one who commissioned this project, whether you have any clarification questions and whether you are addressing these questions to the right party - that would be part of my evaluation of your work. Because how well you work with others has an impact on whether you are handing in the right deliverable.
Right now, you are flunking the test. You don't even know what they are looking for you to showcase in that deliverable, and you run the risk of committing overkill if you use methodology that's more appropriate to higher scale projects.
I take it that you are turning to us because you can't read their minds, and you'll be surprised when we tell you that we can't read their minds either.
The first step in getting any project started on the right foot is addressing your questions to the right party. This means them. It is incumbent on YOU to determine exactly how they want you to do the project, and to hand in the project as per their specifications - no more, no less. You can't outsource your responsibility to someone else.
My reading of their request is that they want you to show that you can actually get anything at all done - they want to make sure that you are not all hat and no cattle before they decide whether it's worth it to continue talking to you. That you can actually write code that accomplishes something and that they can actually make sense of what you wrote. In that context, simple, direct and to the point makes sense. But I am neither a mind reader nor am I the final authority on what they want you to do for this project - they are.
I'll tell you a short story:
As a grad student in computer science, I helped a young lady complete her finals project. Her professor returned her work THREE times over a period of three weeks - the first time because the work was done in a straightforward fashion and he objected because he wanted showcased the methodologies that he had taught in class regardless of the fact that they were not needed, the second time because he was additionally contriving the project NOT to use standard library functions that would have simplified the work and he wanted to see her sweat and show how she navigated around his arbitrary requirement.
I was already physically exhausted and I owed a sleep debt when I decided to help her - and I had my own finals to prepare for. I ended up spending 300% of the time I had originally allocated to her project and we redid this project three times, because her bastard professor was not clear from the get-go what he wanted and he expected us to read that warped mind of his and know what his objectives were in assigning the project without his telling us anything explicitly, at least at first. I was incensed by the time she handed in that project for the third time. My mistake, based on my work experience, was in treating the project as a software engineering project and not as the contrived academic exercise that it was. And my mistake was inevitable because the professor never spec'ed the project as a contrived exercise. She was the first one to hand in that project, by the way.
Lesson learned (yet again): I don't work for people who expect me to read their mind, if I can help it. And I especially don't want to work for people who cook up contrived projects and expect me to read their mind.
I think you should showcase the best sample you can. But be a bit wary of using third party tools. Many interviewers want to see YOU do some coding, not a tool.
The only way to gauge this is by analysing the project. Is it a straightforward one with a clear solution that can be accomplished efficiently without getting fancy. Or is it more open ended with multiple possible solutions which require a few fireworks?
Doing 'sample' projects will always be a fine balance to walk between "too much" and "too little". And seeing as you aren't specifying which tools and techniques or the type of software made, it's difficult to give a concrete answer
But based on the recruitment process, you should have some insight into which tools/technologies and techniques the company uses and what they're looking for in you as a candidate. You also should know something about what they actually do and then you can use these to a degree and then try not to go overboard with additional technologies/techniques.
So no, you should not be complete thorough, but you should be thorough enough that you showcase a level of commitment and ability that you're comfortable with. But most importantly - you should do so much that you can explain in detail why you did what you did, if they ask you why you did not do "more" or why you didn't do "less".
I was once rejected for a job because my sample project was too complicated.
The project was simple. I had to create a program that would open a text file and return the most frequently occuring words in the file.
I made a mistake though. I didn't ask how in depth it should be. So I overcomplicated it to try and showcase my knowledge. The program worked great, but the code was doing more than it needed, to the point where it was even pluralizing the return statement depending on whether a word occured multiple times or just once. And because of that they passed me over.
I still think that was silly reason not to invite me to interview, but I learnt a lesson to always clarify what interviewer actually wants.
