Recommendations for the implementation of test tasks

Somehow in our company ASP.NET developers were required. Well, in order to save time on long-term interviews, we first asked applicants to perform a simple test task.

Assignment from discharge: output the contents of the table, add the ability to filter data, but at the same time lay the possibility of further development and scalability into the architecture. Note: The present TK is certainly more detailed.

Imagine my amazement when, one by one, candidates with a solid resume sent such pearls that it became terrible for their systems. Accordingly, we did not invite such candidates, and surely these were good developers.
')
In this post I would like to describe the main characteristics and errors of the test task, to which I draw attention. I hope this list will help someone find a job faster.


First of all, I want to say that for me the test tasks are always lazy to do. It is also necessary in the intervals between interviews or in the evenings after work to allocate time to write the program, which most likely has no practical application. Spending my time on TZ, when I, the applicant, had not yet finally decided, do I need this company or not?

Here I want to advise you to overcome laziness and complete the task with the maximum quality, I think, for the sake of a new job, a new salary, a new perspective, it is worthwhile to find the strength for it.

So, I have an archive with the program, and here are the main points to which I pay attention:

• Description of the program and if you need instructions on how to deploy the application. Here you can write briefly about the adopted architectural solutions, mention the need to change the configuration file or the need to run SQL scripts.
  
• The application should be simple and easy to open in the development environment (Visual Studio) and do not require additional installation. modules. If third-party application assemblies are used, do not forget to attach them to the archive.
  
• The user interface is a task and test, but the UI should be nice to the eye. I, of course, do not demand the design from A. Lebedev, pictures and other things, but the controllers scattered around the white canvas do not add pluses. Immediately, I estimate the usability of the proposed solution. Some use the standard design (for example, the design of a standard ASP.NET MVC application), it is certainly pleasant, but in this case it does not give an opportunity to understand how advanced your front-end development skill is.
• Next, I perform an analysis of the layout, here I mainly look at the presence of a style file, on the design of html markup, on the name of the elements. Nothing complicated, but many do not. I do not share the tabular and marvelous layout, but it’s very good when you can look at both. Here I also pay attention to the presence of MasterPage.
• Passing manual tests. I try to drop the application in various ways, and I succeed in most cases. To my regret, the most common mistake is SQL Injection, this is immediately a huge minus, one might say, fail. Please check your programs, let's test them with friends and acquaintances, otherwise it seems that the program has never been launched.
• Next, look at the coding standard. Of course, the standards are different, in this case I look at the uniformity in the design of the code. The code with TextBox1, Label1 and other names is also uniform, but I refer it to the “bad” standard. Do not be lazy to give correct names to the controls, observe the register and the rules in the names of methods, parameters, variables, comment on the code, etc.
• Further I look how work with a DB is organized. It is very good if the technologies specified in the requirements for vacancies are used. I also prefer jobs that use ORM. Most database developers work through the GridView + Object / LinqDataSource, it seems easier and faster. It seems to me that such an approach does not always make the developer’s level understand, and discourages it in the future. Here is a delicate moment, if you start doing the grid yourself, then you can get into the caste of “cyclists”. Therefore it is worth warning about the chosen solution in the readme to the program.
• Further I look, whether the application is divided into layers. To my regret, the classic is the level of the data source, the level of business logic (services) and the presentation is very rarely used. Many are limited to putting all the code in a codebehind of a single page. Do not do this! Yes, it's easier and faster, but by doing so you put yourself on a junior-developer level! When you see such a code, then there is no desire to look at it further and get acquainted with the candidate.
• Next, look at the error handling method. What logging methods are used? Where does the user go when an error occurs? Does the user see the entire stack of errors or its concise description? Generally, the developer thought about the error?
• Then you can still look at the use of JavaScript and Ajax, specifically for us, the requirements are optional, but useful.
• At the end, I study the proposed caching scheme (database queries and pages).
• A pleasant rarity is the presence of Unit-tests. This is immediately a plus in the karma of the applicant.
• Along the way, looking for spelling errors. For me, this is an indicator of developer accuracy.

Sometimes applicants go to extremes and offer super-complex options, with their bikes and unconventional approaches, without mentioning this in a cover letter to the TK. It is interesting to study such TZ, but more often than not the applicant receives an add. minus or at least watchful attitude.

In general, something like this happens.
Thanks to everyone who read to the end, I hope the information provided will be useful to you.