This is the first part (out of two or three, I don't know yet) of stories from my recent adventures in landing the job I want. I won't name specific companies or names, but even without such specific information I consider the stories worth telling.
Technology Stack
A couple of months ago I started looking around what the job market has to offer. Having worked as a freelance IT consultant for the past couple of years I was looking for a permanent contract in an interesting company. Besides reactivating previous contacts (e.g., from former offers) I started looking around in (what I would consider) "potential places".
I knew that Java was quite strong in Germany, but I did not believe that the demand was that high. Excluding Java by heart (I'm not picky, but why should I pick an outdated technology when I have access to much more interesting ones, e.g., Node.js, .NET, and modern C++) meant that a huge part of the job market was inaccessible for me. Furthermore, I also had some specific requirements on the technology stack. Unfortunately, the stack I wanted to see (modern, lightweight, agile) was mostly used by companies that also build on Java or Ruby (the former was excluded as previously mentioned, the latter never appealed to me even though Rails is a very nice framework). I always thought the Java-based companies are old-fashioned and conservative. Turns out this applies mostly to the .NET-world.
The CV
Of course, it was pretty obvious that turning my specific set of skills and experiences into an easy-to-digest document (CV) was not a straight-forward task. I made several iterations and I still convinced that the current iteration won't be my last attempt. So far I've failed, but even though that also excluded some opportunities the more interesting ones have not been turned away by the mess that seems to be my CV. I can therefore recommend to polish the CV more than I did, even though the information is still much more valuable than its presentation.
I was specifically told by one lady (working for the HR department of a company) that a CV in English is not liked very much. My response was simple: "If a company does not see the enhanced value of such a document written in English than the company is not interesting to me". Overall, most companies that I showed interest in either did not care or appreciated the English version. It is not a coincidence that the job I took specifically valued English written documents.
Two stories that should be told in this first part involve the specific job interview process. Besides a classic version of Q&A sessions I experienced a lot of coding challenges. I found that rather interesting as I've read (and assumed) that, e.g., GitHub (or public code) is valued much higher. That is definitely not the case. So let's hear two stories from such challenges.
Script Kiddies Wanted
The first story is about a company that runs a large website. The website looks fine and attracts a lot of users. Unfortunately, a closer look at the site reveals that not even basic laws for acceptable website performance are followed. Not by surprise the company was searching for an expert in front-end performance optimization. I was quite astonished to get a coding challenge to use the performance APIs from the browser to read out interesting metrics and send them to a webservice. Nothing easier than that.
Additionally, the whole system should also work on older browsers (I guess IE9 was the oldest one that was on their list). Too bad I have no system with such a browser. If the company really wants to use their user's data for their evaluation than they are wrong on so many scenarios. No browser can tell you the used CPU and task distribution on the target system. The gathered numbers may be totally misleading. It is much better to have a variety of target machines in a lab and test with these. The process can also be very easily automated.
In the end I wrote more code than necessary. This is my typical plan for such challenges. Usually that works pretty well. In this case I introduced a small module system and modularized all parts of the system. I also wrote a simple pie chart control for indicating the gathered data. However, this is where that company was not happy with my efforts (in contrast to all other companies I've witnessed). They said a module system brings too much load and the whole thing takes too long to load (I laughed, because even though not demanded I introduced a front-end build system [Gulp] with some basic optimizations such as minification etc. - things that are not used on their website). Also they probably have not figured out why such a module system is actually beneficial for the overall loading time. The website is drawn much sooner and many scripts may load in parallel instead of sequential. For large scale development the time to first-draw may be drastically reduced. The moral of this story is: A company that knows it cannot handle a particular problem also should not judge the people it wants to hire for solving this problem. Otherwise, people will be hired who most likely cannot solve the problem either.
The Riddle
The second story is about programming riddles. Sometimes people ask riddles to see how well the potential employee handles logic and general problem solving. I agree with the approach, but it should be limited. Most importantly the interviewer has to be very sensitive. If an applicant knows the riddle, he or she can abuse the question to get an advantage. Otherwise, it is more likely to come up with an inelegant solution. The latter case has to be covered well by the interviewer. In my case I was entering the process for a company which was really into riddles. The asked riddles over riddles. And surprisingly, I did come up with solutions to all of them. Even though sometimes they were not satisfied, as my solutions have been non-standard and not-worked out beforehand (how should they?).
First example: People with hats a entering a room. What algorithm should they follow to separate into two groups if one group is wearing a red hat and the other group is wearing a blue hat? My answer was to have a fixed point in the middle of the room. A person is always going to that point and separates the former line in such a way that the colors stay in a line. The answer can be also used for a generalized question with an arbitrary amount of colors (i.e., the topology of persons is now forming a star instead of a line). Of course my answer was not as precise and worked-out as the previous sentence. But the idea was there. No, the specific guy wanted to hear "line" and "middle". Center and majority was not sufficient.
The same company also asked how to find poison in one of N bottles where each bottle contains the same amount of pills. The poisonous pills weigh slightly more than the ordinary ones (say 2g per pill instead of 1g). We have a scale as detector, but we can only use the detector once. I immediately knew that a proper basis needs to be used. I was not sure from any potential collisions (well, its obvious now, but at least as a first reaction I wasn't) which is why I picked 3 pills increasing, i.e., first bottle pick 3 pills, second bottle pick 6 pills, etc. - then I worked out the formula (having to carry that factor of 3 all the time). In the end I was asked why I carry the factor of 3 when 1 is much more simple? I said I wasn't sure about any collisions, but we could substitute 3 by f and have a more generalized solution with the same (linear) basis.
A follow up question involved M out of N bottles. This time I immediately knew that a linear basis is not sufficient and I proposed taking an exponential basis. I choose the simplest one I can think of: 2^x, i.e., first bottle 1, second bottle 2, third bottle 4, etc. - but how to get the poisonous pills after using the scale? I worked with the solution vector and proposed a system of linear equations. That would have worked. In the end, however, the solution was again much simpler: The same scheme works again if we just transform to the binary basis. Now the binary digits (0 or 1) yield the result directly. Alright, lesson learned, even though my (generalized) way has worked as well.
What is the bottom line here? The formerly described company had quite a lot of programming questions, practical tasks, and small assignments, but still they value such snippets (with the wrong take-aways) much higher. That is quite astonishing. It seems like they are insecure how to hire and get-to-know applicants. The key question is: Does one want to work for a company that is not sure how to pick the right candidates? Why don't they just ask such riddles and follow a predefined scheme? Why don't they just propose assignments and use riddles as auxiliary information? Obviously, they have no clear direction. Definitely not a good call.
Conclusions
Most of the time when a company rejects somebody the arrow is not one-sided. Its a bijective relation. From the two stories I mentioned the first seems like a failure. But knowing that I've replied to their ad out-of-curiosity and that I didn't match well to their attitude completes the picture. The second company was actually quite interesting and a proposal with a concrete job offer has been made. Nevertheless, I figured out that the relationship is already dead from beginning, because my opinion (and potentially theirs) is dominated by prejudice. Again I see a two-sided arrow here and its the best for both parties to agree not to start an engagement.