I applied online, received an invite a few days after. The interview took place online, we used Google Hangout. The process was quick and efficient and talk itself quite informative. After the interview, I took an online programming skill test.

I applied for the Senior C# Developer position at Labster in August 2017. It was posted on Unity Connect, which meant that the candidates were expected to work in Unity3D game engine. The first step was a talk with an HR representative (who I will call X for the sake of not revealing their identity) where I was asked standard questions about my strengths, weaknesses, career goals etc. One strange moment was X’s statement that it's only important to be fluent in C# since “Unity is easy to learn”. I know well from experience that this is simply wrong. Being fluent in C# is indeed necessary but mastering Unity's API and engineering projects in an optimal way is difficult. To work on a serious VR project for mobile and to think that just being proficient in C# is enough because “Unity is a piece of cake that can be learned quickly” is unbelievably naive. The second step was an online coding test. It was moderately complicated so it took a bit of time to complete. When all visible and invisible tests (regarded as a plus) were passing I submitted my solution feeling confident about it. Two days later X responded saying that my solution hadn't met their expectations. Baffled by this I asked for an explanation of what exactly was not good with my solution and here’s the response I received: "We want code to be decomposed into simple and easy to understand parts (methods), so that the whole solution combined of these simple methods is also easily understandable and doesn't require effort from the reader. The provided solution requires the reader to go through each line to see what the code is doing". My solution to the assignment had 4 additional methods to the initial code. Two of them were one-liners, therefore trivial. The other two were 19 and 29 lines long. I'm not counting empty lines or the ones containing only brackets. These methods are obviously short enough to not need any decomposing even if we were to strictly follow ‘book rules’. Also, decomposing methods only makes sense if they contain parts that do distinct jobs and don't need to know about the rest of the method and my 29-liner didn't have such instances. A method 29 lines long that parses a collection of objects into a string following moderately complicated rules is NOT too long by any standards and if there's a better way of doing it than looping through the collection while appending parts of the final string (none of which should be split up because it's a logical whole) I would like to know about it. And finally, there are strong arguments against splitting the code into a lot of small methods (a book called Code Complete is a good read). But even if it was good to always do so, refactoring your code into methods super quick. It doesn't change the code, it only makes it look a bit differently. Expectations like that need to be explicitly stated because being lucky to guess what Labster wants the code to look like shouldn't be a factor in the hiring process. To eliminate me over a trivial refactor that I could have done in seconds is really beyond me. Now, when we add Unity into the picture as well as the fact that Labster (as far as I understood) is working on a VR project for MOBILE, writing a lot of small methods is counterproductive and absolutely not good practice. It’s not even a matter of debate at this point. Hardware limitations posed by mobile platforms require developers to be very smart about writing code which often means abandoning regular C# best practices to improve performance. I based my solution on the assumption that the developers at Labster would know this and would take it into account when looking at my solution. Maybe the person who looked at my solution is blindly following 'book' rules without any consideration of exceptions to those rules and especially of the fact that Unity's best practices often do not overlap with C# best practices. Decomposing the code into a lot of small methods doesn’t guarantee you’ll understand it more easily because you’re essentially trading one type of complexity for another. But I think that the real reason for eliminating me was the salary I asked for. I had found some Labster job ads for the position I applied for, and the salary range was between 1050 and 1125 US dollars per month. I could write a lot about Western companies looking to employ highly skilled developers from poorer countries as cheap labor but I will just say that I asked for more than said range while still LESS THAN A THIRD of the amount that a Danish senior software engineer would have to be paid. Dear Labster, if my salary expectations were indeed the reason you decided not to proceed with my recruitment, then it’s fine to just say so. Telling me that my solution didn't meet your expectations when it was actually better than those expectations is disrespectful towards my skill and the effort I put in completing your assignment and straight out insulting.