Test task of my dreams
About six months ago, I began to notice that the proportion of javascript'a in my personal projects has grown significantly. It was not a joy to play the role of an ordinary php player at my current workplace. At the same time, creating one-page applications and learning the wisdom of the frontend was much more fun.
But work should be fun, right? As a result, there was a strong desire to change the field of activity and retrain from the standard “PHP Developer” to the fashionable “Javascript / Frontend Ninja”.
I found a suitable office, sent a CV, agreed on the date of the test task. At that time, I felt quite prepared, yet I had a good knowledge of Backbone, a couple of one-page applications, experiments with Canvas, Google Maps, Node.js, Websockets and others. In general, there was something to show.
But the test task was approaching and it was necessary to prepare. The first thing I did was google “javascript interview questions” and then got it right. The thought spun in my head: “Why are all these tasks so divorced from the real world?”
Prototypes? Short circuits? Hoisting? All this required urgent study, so for a couple of days I “swallowed” The Definitive Guide and felt, as they say, level-up. But questions still remained.
How can the split (''). Reverse (). Join ('') construct show the developer level? arguments is actually a pseudo-array and do you need to use Array.prototype.slice.call to convert it to a normal array? Well done. What is the difference between call () and apply ()? God knows, there was something with the array. Binary tree sorting? It seems I was mistaken with the cabinet, is this really an interview on the front-end position?
One got the impression that the test tasks specifically have nothing to do with what javascript developers have to deal with daily. Instead, the interviewers amuse themselves with pride and encourage all kinds of hacks that are either not used at all in a real work environment or googled in a minute.
Fortunately, my test assignment was fundamentally different. I walked him out of the house, everything was given exactly 2 hours. I needed to make a small one-page application on jQuery / handlebars / dejavu. List of athletes grouped by country and number of medals won. Data is provided as a JSON file. The application should have a clean MVC structure, with public / protected methods and all that.
Additionally included a screenshot of how it should look. With all styles (colors, size of elements, etc.). I will not show the original, but here is a sample copy.
Under normal circumstances, I would need at least a day or two for such an application. First of all, I would sketch out the structure, estimate what models and views I would need, and a prototype would blind a curve. Then a little refactoring, and in the end you can do the layout. The problem is that this time I had 2 hours for everything .
At first, I specifically panicked. Damn, how to do it all? I never used handlebars, I never heard anything about dejavu. In the beginning, I decided to do the typesetting just to get into the rhythm, but the first 10 minutes flew by imperceptibly, and I didn’t do anything sensible like that.
Then I scored on CSS and completely focused on the functionality. Still, few people will be impressed by the beautiful non-working HTML document.
After 2 hours, a terrible, but almost working application without page switching looked at me from the monitor. For the last 10 minutes, I just looked through the code and wrote comments in the style of "if I had the time, then I would have done this here." In general, I was satisfied with my "performance", although I had to spend about half an hour fixing bugs and examining handlebars documentation.
I sent a solution and went to drink valerian. My future colleague later explained that the purpose of this test task was to determine how I would work in conditions of severe lack of time. I would like to look at that monster who mastered this task completely.
My humble personal opinion - these are exactly what test tasks for a front-end developer position should be. All these questions about prototype inheritance, closures and round sewer manholes can simply be memorized. And along with the growing popularity of CoffeeScript and various libraries and frameworks, they completely lose all meaning. Questions about tricky algorithms amuse the ego of the employer and weed out many worthy candidates.
Of course, there are some cases where the use of ready-made solutions is not an option and the real gurus of Vanilla JS are wanted. But such, probably, take one repository on GitHub one by one.
In general, gentlemen, employers, it’s enough to scare your potential colleagues. Give them tasks close to "combat" conditions.
But work should be fun, right? As a result, there was a strong desire to change the field of activity and retrain from the standard “PHP Developer” to the fashionable “Javascript / Frontend Ninja”.
I found a suitable office, sent a CV, agreed on the date of the test task. At that time, I felt quite prepared, yet I had a good knowledge of Backbone, a couple of one-page applications, experiments with Canvas, Google Maps, Node.js, Websockets and others. In general, there was something to show.
But the test task was approaching and it was necessary to prepare. The first thing I did was google “javascript interview questions” and then got it right. The thought spun in my head: “Why are all these tasks so divorced from the real world?”
Prototypes? Short circuits? Hoisting? All this required urgent study, so for a couple of days I “swallowed” The Definitive Guide and felt, as they say, level-up. But questions still remained.
How can the split (''). Reverse (). Join ('') construct show the developer level? arguments is actually a pseudo-array and do you need to use Array.prototype.slice.call to convert it to a normal array? Well done. What is the difference between call () and apply ()? God knows, there was something with the array. Binary tree sorting? It seems I was mistaken with the cabinet, is this really an interview on the front-end position?
One got the impression that the test tasks specifically have nothing to do with what javascript developers have to deal with daily. Instead, the interviewers amuse themselves with pride and encourage all kinds of hacks that are either not used at all in a real work environment or googled in a minute.
Fortunately, my test assignment was fundamentally different. I walked him out of the house, everything was given exactly 2 hours. I needed to make a small one-page application on jQuery / handlebars / dejavu. List of athletes grouped by country and number of medals won. Data is provided as a JSON file. The application should have a clean MVC structure, with public / protected methods and all that.
Additionally included a screenshot of how it should look. With all styles (colors, size of elements, etc.). I will not show the original, but here is a sample copy.
Under normal circumstances, I would need at least a day or two for such an application. First of all, I would sketch out the structure, estimate what models and views I would need, and a prototype would blind a curve. Then a little refactoring, and in the end you can do the layout. The problem is that this time I had 2 hours for everything .
At first, I specifically panicked. Damn, how to do it all? I never used handlebars, I never heard anything about dejavu. In the beginning, I decided to do the typesetting just to get into the rhythm, but the first 10 minutes flew by imperceptibly, and I didn’t do anything sensible like that.
Then I scored on CSS and completely focused on the functionality. Still, few people will be impressed by the beautiful non-working HTML document.
After 2 hours, a terrible, but almost working application without page switching looked at me from the monitor. For the last 10 minutes, I just looked through the code and wrote comments in the style of "if I had the time, then I would have done this here." In general, I was satisfied with my "performance", although I had to spend about half an hour fixing bugs and examining handlebars documentation.
I sent a solution and went to drink valerian. My future colleague later explained that the purpose of this test task was to determine how I would work in conditions of severe lack of time. I would like to look at that monster who mastered this task completely.
My humble personal opinion - these are exactly what test tasks for a front-end developer position should be. All these questions about prototype inheritance, closures and round sewer manholes can simply be memorized. And along with the growing popularity of CoffeeScript and various libraries and frameworks, they completely lose all meaning. Questions about tricky algorithms amuse the ego of the employer and weed out many worthy candidates.
Of course, there are some cases where the use of ready-made solutions is not an option and the real gurus of Vanilla JS are wanted. But such, probably, take one repository on GitHub one by one.
In general, gentlemen, employers, it’s enough to scare your potential colleagues. Give them tasks close to "combat" conditions.