-1

A few months ago I was given a pre-interview assignment for a company. The task was simple, read some data from a file and put them in a database.

Many areas of the design had a varying degree of complexity: From the simple solution, to my preferred belt-and-suspenders style, to fully-blown over-engineered superstructures, with me going out of my way to use every language feature I know how to. I decided to go for midway between the latter two, to show that I know how to do stuff. Accompanying documentation provided some justification over some decisions, as well as clarifying sections of the code, to save whoever was going to read it some time.

At the interview I was questioned about everything in my code, apart from the standard basic round of questions. To clarify, I wasn't asked about design decisions, but rather "I see you used an Abstract class here. What does Abstract mean in [this programming language]?" I didn't get an offer, but I strongly suspect it was due to other factors, because the technical part went pretty well.

So, that level of complexity (light over-engineering) got me an interview this time. Is this a viable strategy long-term, or should I go for simpler designs which are potentially easier to read?

closed as off-topic by gnat, Jan Doggen, Jim G., user8365, IDrinkandIKnowThings Nov 19 '14 at 21:40

This question appears to be off-topic. The users who voted to close gave this specific reason:

  • "Questions seeking advice on company-specific regulations, agreements, or policies should be directed to your manager or HR department. Questions that address only a specific company or position are of limited use to future visitors. Questions seeking legal advice should be directed to legal professionals. For more information, click here." – gnat, Community, IDrinkandIKnowThings
If this question can be reworded to fit the rules in the help center, please edit the question.

  • When I say over-engineered, I really mean "more pedantic than I could've gotten away with". Everything in the project had a function that made something else, or future modifications, a bit safer (not necessarily easier wrt. total LoC). At the same time I'd hate to be passed up for another candidate because they used, ex. lambdas, whereas I didn't. – rath Nov 18 '14 at 19:35
  • 6
    The answer to this would depend on the company doing the interviewing and their culture. It is impoosible to predcit in advance. I would use your preffered style because you want to get hired by someone whose coding process is similar to what you feel confortable with. If you hate over engineering, would you really be happy on a day to day basis at a place that requires it? If you hate cowboy coding, you face the same problem in the opposite direction. – HLGEM Nov 18 '14 at 19:37
  • I think a key factor here may be your answers to questions like "I see you used an Abstract class here. What does Abstract mean in [this programming language]?" - they're trying to confirm you understand the concepts behind the code you wrote. – HorusKol Nov 18 '14 at 22:46
  • and @HLGEM is correct - interviews are as much about cultural fit as they are technical - I've had to pass on a few technically brilliant individuals because they wouldn't fit in culturally with the rest of the team. – HorusKol Nov 18 '14 at 22:48
  • 1
    The question is not off topic. Many potential employers ask candidates to provide code samples or implement a solution to a small problem as part of their evaluation and it is common for such requests to be rather open-ended having no further requirements attached to them. There is NOTHING "company specific" about it. – teego1967 Nov 20 '14 at 14:11
4

This is a grey area for code tests that is a little unfortunate. Sometimes you're just given the code assignment and left to your own devices so you can't ask questions. Sometimes you're in a group setting and other people are watching you do the work in a very interactive way. There are just too many variables to account for so I try to treat them all in a similar way and just switch up my delivery depending on who is actually present or paying attention.

I look at the requirements, and, unless specified otherwise, I attempt the implementation with the simplest method possible given the tools provided. Sometimes this is the best way sometimes it isn't. Like you said yourself, sometimes there's a "way too simple" version and sometimes there's an over-engineered version.

While I pick the "simplest" version, I describe the various versions. If it's a group setting, I'll do this while I'm coding. I had a chance to do this in one interview where two team leads were observing me solve the code problem. I chose the simplest method to get the job done, but while accomplishing that I peppered in with commentary.

I'm using a two-way databind here and going against a tightly coupled concrete instance for simplicity. However, in a larger environment this is more likely to be a DI driven interface coming from either a container or service locator.

If they hadn't been there, I would have said the same thing but put it into a code comment.

They're looking to test your competence and problem solving. If you demonstrate that you not only are able to solve the problem but are able to address it at multiple levels of complexity, then you're more likely to be a viable asset to them. So my advice would be to complete your "exam" with the lowest common denominator in mind, but be prepared to describe and enumerate the different situations where a more complicated solution would be appropriate.

1

Why don't you ask those who gave you the assignment instead of guessing, and potentially guessing wrong? Each prospective employer has their own expectations and it's not as if we on this site can read their minds and give you and give you the answer you want. They are the authority on what they want not us.

  • The task was given to me through a hiring agency, which has some re-transmission delay. It was already taking me longer than it should due to other commitments and I wanted to complete it sooner rather than later. Besides they probably would've said "don't complicate things too much" (it was an entry-level position), but there are things that are better complicated now than later, and I wanted my code to be something I'd be proud of. Wall of text, apologies :) – rath Nov 18 '14 at 19:39
1

There's something to be said for keeping "simple" things "simple". In the absence of other requirements, the best approach is ALWAYS clarity. If you consider the code exercise as a project in its own right then, by definition, it isn't going to be extended, so why over-engineer it?

If the purpose is to show that you can read some data from a file and put it in a database, just do that in a simple way that is easy to understand. No need to use a turgid approach with multiple layers of indirection and gang-of-four patterns if that is NOT asked for. IMHO, the biggest problem that developers have to deal with on a day-to-day basis is gratuitous complexity.

You can expect, however, that you will be asked about how to adapt the code for various situations/requirements, so its not like you don't have to think about it but explicitly putting those complications into your code for an example could be seen as "premature optimization" or even "phantom requirements".

  • +1 to keeping it simple. Engineers responsible for technical interviews might not have a lot of time to play with for reviewing candidates' code, so the easier it is to verify, the better. There's a risk that immediately going for a more complex approach might give off the vibe of spinning on overcomplicated solutions to simple problems. Code samples aren't necessarily looking to spot the rocket scientists - they're much more likely looking to screen out the people who can't code their way out of a wet paper bag (and there are unfortunately a lot of those). – Ken Franqueiro Nov 19 '14 at 4:35
-1

Just as an example, my last quick-n-dirty-hack had this lines in it, php:

//TODO: switch here to reading line-by-line if files get bigger
$contents = file_get_contents($filename);
$lines = explode("\n", $contents);
foreach ($lines as $line) {
  ..

It shows you can solve a problem, that you code clean with variable names and so on and that you undestand the limits of your code and when and how you should adjust it.

The comments could then be used in an interview to see if you have in-depth knowledge in an area you are mentioning.

  • 1
    This does not answer the question – Jan Doggen Nov 19 '14 at 7:38

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