[CollinEMac]

Man this sounds rough. I had a somewhat similar experience a while back but instead of going back and forth trying to nail down requirements, I went down this spiral of wondering if the lack of clarity wwas part of some kind of meta-test.

"Do they want to see if I can build something with as little guidance as possible?"

"Do they want me to push for more requirements like I would on a real project?"

"If I build something cool but totally off from what they expected will that make me look better or worse?"

"Or are they just trying to weed out the people that can't code at all?"

In the end I didn't get a follow-up interview and they refused to give me any feedback on how I could have done better on the take-home assessment.

Back to the OP: One such example would be to do a live code review. This could be done asynchronously or synchronously. It could allow actually talking through topics and issues that relate to the challenges in a real software project. This would allow to surface much more of the knowledge in an experienced software engineer.

I like this idea a lot.

[nathan_douglas]

Yeah, I had a very similar experience recently. I refactored some things because the code was weirdly circuitous. Should I not have? I wrote a lot of explanatory notes. Was that a bad move? Ultimately I spent several hours on it and my response was basically "Didn't work." I realized that they had some automation set up that would spin up the thing, send some HTTP requests, then shut down. No human ever actually looked at my work, so the time I spent wondering whether I should or should not refactor was probably moot. Didn't feel great.

[edfletcher_t137]

> One such example would be to do a live code review. This could be done asynchronously or synchronously. It could allow actually talking through topics and issues that relate to the challenges in a real software project. This would allow to surface much more of the knowledge in an experienced software engineer.

From my understanding of the post, this was the initial screening phase as it was in response to OP's application. In other words, this is what every candidate who passes the application screen (the weakest one) is sent.

Let's say they have 100 candidates for this role. A proper code review here should take ~45 minutes to an hour. Even 15% of the candidates requesting a full code review - regardless of synchronicity - represents a 11.25-to-15 hour time commitment from the hiring team. For the initial screen. That is asinine. No proper organization would accept such a large time sink for so few candidates at this phase.

As I've said already multiple times in this thread, OP very clearly does not understand the asynchronous relationship at play here, and then based much of their interactions & interpretations on this misunderstanding.

[josecodea]

Exactly! You are actually considering all the possible ways in which your approach might be wrong and in which the time would be wasted. You are assessing risk before you take action. You are analyzing the subtleties in communication, you determined that the wording relied on a lot of subjective vocabulary and you know that this leads towards misunderstandings. This is, in my humble opinion, the professional way of making decisions as a software engineer.

From reading the other comments, it seems like there are a lot of mind-readers among us. ¯\_(ツ)_/¯

[mplanchard]

I think it’s telling that the comments here are full of people noting mistakes that you made in your interpretation and/or execution, and rather than trying to learn from the experience, you appear to just be doubling down on your insistence that you’re entirely in the right.

Yes, there were flaws in the assignment and communication with the company, but there were also flaws in your approach. You’d be better off to try to take away some lessons here rather than blaming everyone but yourself.

Frankly, if I were you I’d consider deleting both your comments here and the blog post. I don’t think they reflect well on you as a candidate for future roles.

[jemiluv8]

Well said. The author of the blogpost is taking this all too personal. While also seemingly ignoring their own shortcomings in their approach. I'd see it more as a learning opportunity because there was clearly a huge gap in the intended interpretation of the take home and their own interpretation.

[jemiluv8]

> Frankly, if I were you I’d consider deleting both your comments here and the blog post. I don’t think they reflect well on you as a candidate for future roles.

That would be a wise move at this point. I keep wondering what the point of the post was?