Code review

How to implement a perfect technical assignment for an interview

technical assignment

Recently I went to the couple interviews for role of Senior Java developer and all of them had a pre-request of implementing of a technical assignment. The funny part is that different companies have almost the same technical assignment – implement CRUD REST API (using spring-boot) and front-end using any technology. I collected lots of feedback on my solutions. In this post I would like to share how to implement perfect technical assignment, where to pay attention and how to score some additional points comparing to other candidates.


Code review

Transaction propagation or 100% deadlock with JPA/Hibernate.

Transaction propagation deadlock

In continuation of the topic about deadlocks I want to tell you about another case of getting deadlock with JPA/Hibernate. This deadlock I’ve already met two times and it is related to transaction propagation.

How often do you manipulate transaction propagation except using default one – REQUIRED (luckily same name for Hibernate and JPA)?

If you ask me, not much. So when I see propagation=REQUIRES_NEW in code I always suspect that something might smell.

Code review

Watch what you say or interaction anti-patterns

Interaction makes all our life. We are humans, social creatures after all. The same is true for  a software that we implement. Even in the simplest scenario it’s impossible to avoid communication between parts, services, layers, or users. It’s hard to avoid interaction, similarly hard is to avoid bad interaction patterns.

Some of them seem so obvious, that we even don’t spend too much attention to them. Other category is patterns that seem as nice ideas at the beginning, before we know what exactly want to achieve.

It’s not about them. The anti-pattern we will examine in this article was sh*t from very beginning and here is why.

Let’s see how it was.


It's in your process

Don’t touch my code

Starting career from zero to hero we all focus on technical skills. How many languages, frameworks, technologies we know, how efficient our sorting algorithm is, how optimal our query is, how fast we can refactor your code, and lots of other “hows.” Later, when minimal valuable level of professional knowledge is archived, people start focusing on so called soft skills. According to Wiki they include combination of communication, social, emotional skills, including but not limited with common sense, positive attitudes, and ability to deal with people. Then we become more mature and our professional interests diverse from “what” and “when” to “who” and “why.”

Based on questions that are interesting to us our professional career goes into directions of managers (if you like to control an uncontrollable environment of idealistic developers) and architects (if you like to control an uncontrollable environment of development ideas), technological guru (if you understand that only thing, you can control, is you and your code), entrepreneurs (if you want to control everything at once), agile coaches (if you really love colorful stickers) and surfers (when you finally understand that it’s much easier to control nature).

But before that magical idea bulb of understanding finally appears, we work as developers. There are many skills we need to have to be professionals. But there is a one skill that is, on my opinion, completely underestimated. Mostly nobody puts it explicitly to job description, nobody teaches it, but everyone faces lack of it at some point. This skill is to let your code go… to trash.


Code review

Dockerizing of Angular 5 applications

What normal people do when they are bored? Some of them start renovation of an apartment or try yoga; others make an affair and change jobs, there are even individuals who start political incidents or send their favorite car to space making them playing song from youth. But normally bored people just try something new, even if it’s a new position lying on a sofa in front of TV. Comparing to this dockerizing Angular 5 application doesn’t seem such a weird idea to try.

I’m a back-end developer and don’t have much to do with front-end. Mostly because I’m more curious about back-end technologies, although I feel myself quite interested in user-experience, but front-end was never a point of interest for me. All this CSS, hover and a href. Simply not my style. I’m pretty sure that there are enough front-end to do all beautiful pages, which I can fill with sophisticated back-end logic. But as part of technical assignment I had to implement front-end application that does CRUD REST calls to back-end.


As this was my first experience of creating Angular 5 application from scratch (before that I only fixed some minor bugs, which were highly criticized by more experience front-end developers, or added simple screens to existing applications, and didn’t send them for review to avoid jokes and critics) I want to share with you my experience.

As I can’t surprise anyone with my knowledge of Angular, I decided to make something more interesting: dockerizing Angular 5 application. (because I’m developer, back-end developer)


It's in your process

Why 55 is a perfect length

Procrastination and lack of motivation happen all over and anytime. If you google, you can find lots of pages describing difference between procrastination, laziness and motivation gap. In most cases they describe a problem from individual, personal prospective, some of them however take the topic more specific as lack of motivation in a company in general or on specific project. Especially LinkedIn is full of such articles, mostly sponsored ones. But how to understand that your project stuck with progress, motivation is low in general although some individuals are still fighting with circumstances?

You still deliver necessary functionality, and you still get your story points and necessary velocity, but something is wrong. Especially hard to understand if it’s a temporary state or first sign of hard-to-solve problems. Here is when we understood that our project was facing procrastination in full strength.

…when you understand that you have nothing to do

We use wide know procedure of cross-team code review. Also, we have a dedicated people who is responsible for specific parts of a system, and as you may understand, get all code-reviews on dedicated topic. There is an example we had recently.


Code review

From silver bullet to deadlock… and back

Some problems are expected and easy to solve. In most cases we never call them problems, but the tasks within stories. Solving them we call a development, simply saying a job.

Other problems are not expected, but they are still easy to solve, when we finally know about their existence. We call them bugs, generally we receive them from testers or support engineers. It may take the whole day to solve them. 20 minutes to spend on bug and the rest of the day for table football.

Most problems are expected but hard to solve, and this is the most unfortunate category. Because these problems spend the rest of their miserable lives in a backlog, never reviewed, never analyzed, never mentioned during stand-ups and at the end killed with cleaning up of scrum boards.

The most challenging ones (according to corporate etiquette we prefer to call them challenges, rather then WTF) are unexpected and hard-solvable problems. They even don’t go to a backlog. In most cases just because nobody knows what to put in the title of issue, except “a new shiny bug”, it takes time to investigate. Some developers call them phantom bugs, put a stamp “Unreproducible” on them, other developers just ignore the existence of these bug at all. All developers, to be precise.

But the hardest problems are that, you have no idea about. And this is a real challenge, but not that one from a book of company rules. Solving these problems makes you grow, become more mature and finally stop being a junior developer. I personally hate them most of all. Basically because nobody pays for solving them. But also because it makes me feel almost as miserable as bugs in a backlog. They are never fully solvable, in most cases they avoided, and it’s called best practices in books and video-courses.

Most developers I’ve worked with put persistence problems in a backlog, secretly hoping that someone would delete them (problems, not developers, but who knows) or data storage system would be changed. An unfortunately persistent layer is persistently stable, changing DBMS is rarely an option. Although sometimes I feel almost personal pain because of these left-forever issues, life is life and development costs money.

It’s not a problem, it’s a challenge

This time wind of change blew somewhere between persistence and back-end: the problem occurred too often to send it to backlog and too scary to start actually working on: deadlock. In my previous experience I met deadlocks not more then ten times, in all cases it occurred in heavily used systems with thousands of simultaneous calls, in all cases the root cause was hard to find, in all cases deadlock was solved on database level, applying magical combination of indices, in all cases DBA was blamed in all humans sins. This time things were drastically different: our system is on under-development stage, and we barely have any data on production, the tests run on almost empty environments, testing only simple “super” happy flow scenario, we use default setting of MS-SQL Database running in Docker, we use Hibernate as ORM, services are relatively small and business logic is not sophisticated at all. What can go wrong?



Starting with…

Everything has a beginning.

Morning starts with coffee; day starts from a stand-up; problems start with “let me change one line”, questions start with “why”, answers start with “have no f*cking idea, but I guess”, refinement starts with a delay, meeting starts with “round drink” bell, annual appraisal with “you know it was a tough year”.

The code starts with the first line; problems start earlier with vague concepts, wrong assumptions, badly refined tasks, poor requirements, architect’s day-off, broken coffee machine, wrong version of node.js. Code generates bugs together with added value to solve functional problems. It may take hours to solve a problem, and even more to find it. Problems and bugs irritate us, make us angry and grumpy. I’ve never met a person happy with bugs, neither among developers, nor within management team. But everything has a purpose even if it’s not clear from the beginning.

Despite obvious purpose to postpone release or spend some extra overtime, the main purpose of problems is to move us further, to let us try more, break more, fix more. But if we want to achieve this Code-without-bugs nirvana, we need to reflect on problems, spend time analyzing not only solutions, but a root causes, wrong prerequisites, mistakes. It’s important to find a solution, but it’s not less important to trace a path to this solution. Because you may need to do it again. Or at least to use it as an ode to the one’s genius between juniors. In this blog we will try not only show the solution but the way to solve it, an environment where problems occurred, specific conditions that made a ground to grow mistakes.

Not all problems are in you code. But those that are in you code apparently are much easier to solve, even if it takes hours to parse logs, takes days to reproduce, takes nights to think about. You need to search, read, apply, throw solution away, search again, read, try, ask somebody, try again, drink coffee, curse loudly, preferably on foreign language, try again and again, and again.

Everything has a beginning, and it starts in your code.