Test task of my dream
About six months ago, I began to notice that the share of javascript'a in my personal projects has increased significantly. Acting as an ordinary student at my current workplace was not a joy. At the same time, the creation of one-page applications and the study of the knowledge of the front-end delivered much more fun.
But the 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 trendy “Javascript / Frontend Ninja”.
Found a suitable office, sent a CV, agreed on the date of the test task. At that time, I felt quite prepared, after all, 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 the “javascript interview questions” and right away. The thought began to spin in my head: “Why are all these tasks so detached from the real world?”
Prototypes? Closures? Hoisting? All this required urgent study, so I swallowed The Definitive Guide for a couple of days and felt, as they say, a level-up. But questions still remained.
How does the construction split (''). Reverse (). Join ('') show the developer level? Are arguments actually a pseudo-array and 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 an array. Sort using a binary tree? I think I made a mistake with the cabinet, is it really an interview for a fender position?
The impression was that the test tasks had nothing to do with what javascript developers have to face daily. Instead, interviewers indulge their self-esteem and encourage all sorts of hacks that, in a real working environment, are either not used at all, or googled in a minute.
Fortunately, my test task differed radically. I passed it from 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 the number of medals won. Data is provided as a JSON file. The application should have a pure MVC structure, with public / protected methods and all that.
Additionally, a screenshot of how it should look was attached. With all styles (colors, size of elements, etc.). I will not show the original, but here is an approximate copy.
Under normal conditions, I would need at least one or two days for such an application. First of all, I would outline the structure, estimate which models and views I would need, would make a prototype curve builder. 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 have never used handlebars, I haven't heard anything at all about dejavu. In the beginning, I decided to do the layout just to get into the rhythm, but the first 10 minutes flew by without notice, and I didn’t do anything sensible.
Then I scored on CSS and fully focused on the functionality. Still, few people will be impressed by a 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 simply looked through the code and wrote comments in the style of “if I had time, then I would do this here.” In general, I was pleased with my “performance”, although I had to spend about half an hour fixing bugs and examining the documentation of handlebars.
I sent the decision and went to drink valerian. My future colleague later explained that the purpose of this test task was to determine how I would work under conditions of severe lack of time. I would like to look at the monster who mastered this task completely.
My humble personal opinion - these should be the test tasks for the frontend developer post. All these questions about prototype inheritance, closures, and round manhole covers can be simply memorized. And along with the growing popularity of CoffeeScript and various libraries and frameworks, they completely lose all meaning. Questions about tricky algorithms entertain the employer's ego and filter out many worthy candidates.
Of course, there are some cases when using ready-made solutions is not an option and real gurus Vanilla JS are wanted. But such, probably, take one repository on GitHub.
In general, gentlemen, employers, enough to nightmare your potential colleagues. Give them assignments close to “combat” conditions.
But the 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 trendy “Javascript / Frontend Ninja”.
Found a suitable office, sent a CV, agreed on the date of the test task. At that time, I felt quite prepared, after all, 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 the “javascript interview questions” and right away. The thought began to spin in my head: “Why are all these tasks so detached from the real world?”
Prototypes? Closures? Hoisting? All this required urgent study, so I swallowed The Definitive Guide for a couple of days and felt, as they say, a level-up. But questions still remained.
How does the construction split (''). Reverse (). Join ('') show the developer level? Are arguments actually a pseudo-array and 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 an array. Sort using a binary tree? I think I made a mistake with the cabinet, is it really an interview for a fender position?
The impression was that the test tasks had nothing to do with what javascript developers have to face daily. Instead, interviewers indulge their self-esteem and encourage all sorts of hacks that, in a real working environment, are either not used at all, or googled in a minute.
Fortunately, my test task differed radically. I passed it from 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 the number of medals won. Data is provided as a JSON file. The application should have a pure MVC structure, with public / protected methods and all that.
Additionally, a screenshot of how it should look was attached. With all styles (colors, size of elements, etc.). I will not show the original, but here is an approximate copy.
Under normal conditions, I would need at least one or two days for such an application. First of all, I would outline the structure, estimate which models and views I would need, would make a prototype curve builder. 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 have never used handlebars, I haven't heard anything at all about dejavu. In the beginning, I decided to do the layout just to get into the rhythm, but the first 10 minutes flew by without notice, and I didn’t do anything sensible.
Then I scored on CSS and fully focused on the functionality. Still, few people will be impressed by a 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 simply looked through the code and wrote comments in the style of “if I had time, then I would do this here.” In general, I was pleased with my “performance”, although I had to spend about half an hour fixing bugs and examining the documentation of handlebars.
I sent the decision and went to drink valerian. My future colleague later explained that the purpose of this test task was to determine how I would work under conditions of severe lack of time. I would like to look at the monster who mastered this task completely.
My humble personal opinion - these should be the test tasks for the frontend developer post. All these questions about prototype inheritance, closures, and round manhole covers can be simply memorized. And along with the growing popularity of CoffeeScript and various libraries and frameworks, they completely lose all meaning. Questions about tricky algorithms entertain the employer's ego and filter out many worthy candidates.
Of course, there are some cases when using ready-made solutions is not an option and real gurus Vanilla JS are wanted. But such, probably, take one repository on GitHub.
In general, gentlemen, employers, enough to nightmare your potential colleagues. Give them assignments close to “combat” conditions.
Source: https://habr.com/ru/post/214281/
All Articles