3

I am looking for a job abroad (senior Java developer). There are companies that hire from abroad, and have a practice of assigning homeworks.

The problem is that the assignment is typically extremely vague. There are just 3 to 5 sentences about the requirements regarding level of abstraction, coding style, usage of newest language features and APIs, precompilers, expected quality level and such. And these are as vague as:

Whilst​ ​ we​ ​ encourage​ ​ you​ ​ to use​ ​ the​ ​ new​ ​ Java​ ​ 8 ​ ​ Stream​ ​ APIs​ ​ and​ ​ lambdas​ ​ try​ ​ to​ ​ avoid​ ​ code​ ​ that​ ​ is​ ​ more​ ​ functional​ ​ than object​ ​ oriented.​

Or

​ Make​ ​ things​ ​ as​ ​ simple​ ​ as​ ​ possible​ ​ and​ ​ as​ ​ complicated​ ​ as​ ​ needed

Or

​ The​ ​ goal is​ ​ not​ ​ to​ ​ cover​ ​ every​ ​ potential​ ​ level​ ​ of​ ​ abstraction​ ​ you​ ​ may​ ​ need​ ​ in​ ​ the​ ​ next​ ​ 5 ​ ​ years​ ​ but​ ​ the levels​ ​ you​ ​ think​ ​ make​ ​ sense​ ​ today​ ​ given​ ​ the​ ​ current​ ​ scope​ ​ of​ ​ the​ ​ application.

When I asked for the scope, they told me (towards the end of a good and friendly Skype interview) that "It should be under 8 hours, 4 hours if you're experienced".

No mentions of whether, how and to what extent the code should be tested; no coding style, no formatting. Some companies don't even tell target language/platform version preference. When you ask, the person from (I assume) HR tells you that would be "telling you the solution".

When I'm done with the projects, the response is, for some companies, "You're a rock star, we want you", and for others, "we expected more" and end of communication. And I followed roughly the same standards. Once when I asked for some more explanation, I only get an email with bullets:

  • the project is not well structured
  • code is not clean
  • Spring usage
  • API design

When I asked again what they mean, since other companies take my code style as good one, I get:

In my opinion it always makes sense to write proper code. You were asked to provide a decent project to show you coding skills which we then can review. This is about style, structure, data structures, api design. This was all taken into account when reviewing your project assuming you did your best.

Again, just general terms, no explanation. I gave up. (Let's put aside the fact that they wanted quality level matching "current​ ​ scope​ ​ of​ ​ the​ ​ application", which is - a 4 hour project to be trashed right after the hiring process - and now, they want "my best".)

I assume this site is visited by some recruiters, too.

How can I make these people to give me more specific assignments, where they would actually write what they want?

When I try to ask for them, they resist, and asking repeatedly feels like I am complicating things even at the start. But not asking puts me to a wheel of fortune that I will use the style that the reviewer likes. Such like:

  • What version of Java should it be coded for?
  • Should I use functional style?
  • Should I use immutable style?
  • Should I optimize rather for performance or for readability?
  • Should I prefer classes for all domain models or are Java collections enough where practical?
  • Should I use Optional<...> or is it okay to stick with null's?
  • Should I write getters/setters explicitely or is it ok to use Lombok?
  • Should I have an interface for each service if I write services? ditionally:
  • Should I write unit tests and integration tests? (Not mentioned in the PDF.)

Edit: I forgot to mention here that I worked for Red Hat for 9 years and most of my real-world code is on public GitHub repositories of JBoss, mentioned in my CV. I wonder why don't they just go there.

9

You probably can't make these people give a clearer assignment, but you should definitely contact them and ask for a short call to clarify the assignment. Hopefully, the assignment contains the contact details for whomever wrote the assignment or will be grading it, so you can talk with them.

If it does not, contact the company and ask to speak with the person who will be grading, so you can clarify what it is they are looking for.

At that point, either you've already earned a few points for being willing to talk with the end user and you'll get better instructions or you will be stonewalled and told to just do the assignment as written and figure it out for yourself.

Now it's very important to realize that probably your working conditions, should you be hired, will reflect the interview process quite a bit. This is a software company, they should know that you can't build any decent software without close contact with your end-users and without talking about expectations, needs, and problems. If they don't know, and expect interviewees to muddle about, that probably means you'll be muddling about during your regular job as well. Consider for yourself whether you'd be okay working from vague, written assignments where you can't talk with the client in your day-to-day job as well. Then decide if you want to do the assignment as written.

Personally, if I couldn't reach an engineer to talk about the assignment, I'd drop the company from consideration. Interview processes go both ways, and as far as I'm concerned the company doesn't understand building software if the engineers aren't allowed to talk with the clients.

  • As you say, @Erik, I would drop the companies, but the thing is, the subject they develop is my hobby, and the tech stack is exactly what I like, plus it's a growing product getting new features, backed by a very stable big company, which also has it's benefits. So instead I am trying to minimize the chance to be filtered out based on things I can't really control. I think it's some kind of communication gap between HR and devs on their side. If I was able to get to the tech person and discuss the assignment, I would know in 5 minutes. But they do it this way intentionally to save dev's time. – Ondra Žižka Nov 9 '18 at 16:55
  • @OndraŽižka clearly they don't want prospects to communicate with devs; you'll have to decide whether the time investment is worth it for a company that works this way. If they're "saving the devs time" you'll just have to plunge in and hope for the best if you want the job. – Erik Nov 9 '18 at 17:27
  • Oh, and don't expect a sensible response either. I had an interview where their stated purpose was to provide feedback on a code project (which it did, ten paragraphs). One of their "review points" for me was that my code was "messy" (it consisted of two enums and a class, all following a standard style). They never explained what they meant by this even after I sent an email back asking about it (and a reply which amounted to "sorry you had such a bad experience"). One of their other feedback points was that I didn't know databases (which I said up front before the interview even happened). – Draco18s Nov 11 '18 at 22:51
4

Given the added information that it is for a senior developer role, I think they are trying to learn the sort of decisions the OP would make as a technical leader, not a technical follower.

Real world projects start with high level objectives from marketing and/or management. It is up to the leading programmers to fill in the rules about formatting etc.

They should be prepared to answer questions about requirements that, in the real world, would be reasonable to ask a non-technical manager. Issues like "Should I use Optional<...> or is it okay to stick with null's?" would be meaningless to any non-programmer.

  • 1
    +1 - This. That was my immediate thought: the company is purposely keeping the requirements vague, because they want to see what kind of solution the applicant makes when they're minimally managed. – Kevin Nov 9 '18 at 14:11
  • 1
    They've already provided high-level criteria: don't make it more complicated than it has to be, for example. Make a decision and write the code, commenting liberally to explain the rationale. 'Returns null if nothing found. Consider switching to Optional<> for a cleaner API'. 'This collection represents the list of documents. To support more functionality or to meet coding standards, it might eventually need to be a full class'. – Peter Nov 9 '18 at 14:40
  • I get that, and that would be okay, but then they would have to give space to justify the decisions. Instead, they just "don't like it" and have no explanation why. In other words, they let it up to me to fill in the rules, but then they don't like the rules. That's my whole point. – Ondra Žižka Nov 9 '18 at 16:39
  • "... would be meaningless to any non-programmer." You're right. That, however, would be okay if the solution was reviewed / tested by a non-programmer. This way, I am (probably) evaluated based on something that is a matter of taste, therefore it has nothing to do with my abilities. Just a match of taste with the reviewer. – Ondra Žižka Nov 9 '18 at 16:45
  • 1
    +1. If you need answers to all those 20 questions to get started - you’re not a senior. – mxyzplk says reinstate Monica Nov 10 '18 at 4:43
2

In the first instance you should definitely follow up and try to ask a real person for more information. It's not clear if they're testing your initiative/ability to work with minimal information or your technical capability (or both), at the very least speaking to someone should help clarify that.

Even if the answer is that they can't give any more information about the test, they may still be able to set your mind at ease with regards to how you'll be working if you get the role.

If they refuse to give any more information or you are unable to contact anyone in time, then you have two choices, either back out of the process if you feel it's not worth your time, or complete the test to the best of your ability but ensure you document all of the decisions you made along the way, and your reasoning behind those decisions.

By documenting your work, even if you choose a platform or approach they wouldn't necessarily have chosen, you can indicate your reasons for the choice and that you are at least aware of the alternatives and aren't just Googling the solution.

  • "to the best of your ability" - that's the thing. I can either go the purist way, old Java code following all dogmas, or take a bit relaxed approach with all that Java 11 and pre-compilers offer... both is okay for me. – Ondra Žižka Nov 9 '18 at 11:59
  • 1
    @OndraŽižka indeed, and I think either approach is fine in that case, so long as you mention the alternative approach to show you are aware of it. In that situation, I'd go with the approach I personally preferred to work in, since that's what I would hope the job would involve. – delinear Nov 9 '18 at 13:20
  • right. That makes sense. – Ondra Žižka Nov 9 '18 at 16:50
1

IMHO, vague assignment should be met with same type of the execution.

On several occasions, i have been given very vague and broad specs for assignment and in two cases created the abstract structure.

In both cases i have received feedback right away.

One of the projects i got after discussion with Senior Dev, the other one turned out to be a freebie hunter that got extremely aggravated by not working product

1

This is common practice in rigid enterprise structures, often found in larger, older or non-merit companies. It boils down to: it’s them, not you.

HR or recruitment often doesn’t have the skill or knowledge to assess anything outside of visible/practical/physical types of work, making this kind of thing flow through templates and keyword screenings until you pass on to generic engineering checks that have no context and don’t reflect real world or realistic scenarios, including your described lack of information and lack of interaction, which in normal software engineering is required to practically get anything done. The reason this is still happening is because of the traditional siloing and one-way sharing within companies. Just because we (the people actually writing software and working with colleagues) know what we should do instead to check if someone is a good fit doesn’t mean we get to influence the process a lot and are often not part of the process at all.

This often also indicates a highly problematic work structure/environment with rigid hierarchies and divisions, something I myself try to stay clear of.

In my current situation, our team basically has control of it all and practically use the available recruitment manpower (and budget) in a way that gets us the people we want. Takes away an hour a week from our tech jobs, but is totally worth it.

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