DEV Community: Anton Musatov

My Job Search Experience in 2023

Anton Musatov — Sun, 08 Oct 2023 18:48:37 +0000

I started working at my current company just three months ago, and I'd like to share some insights and statistics from my job search in 2023.

About Me

I am a seasoned Software Engineer with 13 years of experience and a Master's degree in Computer Science. For the past 11 years, I worked on a large, complex, high-load domestic B2B e-marketplace. I began my career there as a Junior Developer and gradually rose to the Principal Software Engineer of a developer department consisting of 19 individuals, including one frontend team and three backend teams.

Job Criteria

Driven by a strong desire for continuous growth and development in my career, I believed that the most promising path for me was to enter the international market. Consequently, my primary criterion was to find an international company.

I understood that the processes in an international company may be different from my experience, which is why I mostly applied for Senior Engineer positions. This role would allow me to use my diverse set of technical and interpersonal skills immediately and also grow organically and efficiently within the company.

Over the last four years, I've worked fully remotely and successfully set up my work processes to ensure optimal efficiency. I value this freedom, so a remote position was my third essential criterion.

Having worked in the B2B sector with large corporations, I've encountered extended adoption periods for new processes, resulting in slower feedback loops than I'd prefer. Hence, I sought dynamic product companies that create real impacts for their customers. Ideally, I wanted a company whose product resonated with my interests.

These were my fundamental criteria for the job search.

Duration

I initiated my job search in January 2023 and accepted an offer in July 2023. The entire process took 6 months, primarily conducted during weekends alongside my regular job.

Job Search Statistics

During this period, I:

applied for ~200 job vacancies.
received rejections from ~48% of the companies.
did not receive responses from ~46% of the companies.
participated in interviews with 13 companies.
received 4 job offers.

Finally, I found a company and position that aligned perfectly with all my criteria, and I am still very happy about it.

While my case is unique, I hope you find these statistics valuable in your own job search endeavors.

Effective Team Practices

Anton Musatov — Sat, 30 Sep 2023 17:14:40 +0000

In the current article, I want to briefly describe team practices that I have used in my work.

Design Review Meetings

Who: Designer, one front-end product senior developer, one back-end product senior developer.
When: When we have just a draft of the task and design.
Why: To identify potential problems as soon as possible that we could encounter during implementation.

Refinement Meetings

Who: Product managers, all product front-end developers, all product back-end developers, product QA.
When: When the design and description are ready for development; can be one meeting for several tasks.
Why: To synchronize all tech team members about future tasks, receive feedback and basic evaluation, and share knowledge about the product.

Requesting Tasks Through Common Channel

Who: Developer.
When: When a developer needs a new task.
Why: To maintain transparency regarding who is working on what task and to prevent task accumulation in developers' backlogs.

Task Planning Meetings

Who: Front-end developer, back-end developer.
When: After task assignment.
Why: To synchronize particular developers about specific tasks and create a technical plan for the task.

Task Plan Approval

Who: Front-end developer, back-end developer.
When: Asynchronous, after task planning meetings.
Why: For big, complex tasks, to align expectations before starting.

Short Daily Required Sync Meetings

Who: All product front-end developers, all product back-end developers.
When: Daily.
Why: To synchronize the status of tasks; important to be short, focusing only on status and problems, with a maximum duration of 30 minutes.

Short Leads Required Sync Meetings

Who: Team leads from front-end, team leads from back-end.
When: Daily.
Why: If there are a lot of people in commands, we can synchronize separately and then sync only at the leads' level.

Tech Retro

Who: Front-end developer/back-end developer.
When: On-demand.
Why: To share knowledge about complex technical tasks/solutions.

Demo Retro

Who: Front-end developer/back-end developer (optional).
When: After each middle/big size feature.
Why: To share knowledge.

Socialization Meeting

Who: Front-end developer/back-end developer (optional).
When: Weekly, maximum 1 hour.
Why: Just for socialization, to discuss work or personal matters.

Research Day

Who: Front-end developer/back-end developer (optional).
When: Monthly.
Why: To maintain expertise and provide suitable solutions for complex tasks.

One-on-One Meetings

Who: Developer, team lead.
When: Monthly.
Why: To provide feedback and address problems and achievements.

I have provided a brief description, and not all practices may apply in every company and project structure. However, I believe they can be useful to know about.

Different Ways to Use Laravel Actions

Anton Musatov — Sat, 23 Sep 2023 12:12:49 +0000

You can find more information about Laravel actions here and here. In this article, I aim to demonstrate two different approaches to using these actions, along with their respective pros and cons.

Let's consider a scenario where we have an Order model and a related OrderLine model, and we need to add an API endpoint to create an order.

The first classic approach may look like this:

OrderPolicy class with a create method where we perform security checks.

final class OrderPolicy
{
    use HandlesAuthorization;

    public function store(User $user, OrderStoreRequest $request): bool
    {
        //...
    }
}

OrderStoreRequest class, responsible for invoking the policy and containing validation rules for input data.

final class OrderStoreRequest extends FormRequest
{
    public function authorize(): bool
    {
        return $this->user()->can('store', [
            Order::class,
            $this,
        ]);
    }

    public function rules(): array
    {
        return [
            //...
        ];
    }
}

CreateOrderAction class, where we save the Order and OrderLine models in a single transaction.

final class CreateOrderAction
{
    public function __invoke(CreateOrderData $createOrderData): int
    {
        return DB::transaction(function () use ($createOrderData) {
            //...
        });
    }
}

OrderController with a store method that combines all the previous classes.

final class OrderController extends Controller
{
    public function store(OrderStoreRequest $request, CreateOrderAction $createOrder): Response
    {
        $orderId = $createOrder(CreateOrderData::fromRequest($request));

        return $this->response()->created(content: $orderId);
    }
}

This approach follows the traditional Laravel methodology and offers its own set of advantages:

You can refer to the Laravel documentation for detailed information.
Most Laravel developers are familiar with this approach.
Framework tools facilitate concise and readable code.
Actions can be reused in other parts of the application.

However, if you find the need to reuse not only data mutation and saving within a transaction but also security and validation checks, you might encounter some challenges.

Now, let's explore an alternative approach that may look like this:

CreateOrderSecurityAction class, containing all necessary security checks.

final class CreateOrderSecurityAction
{
    public function __invoke(int $userId, CreateOrderData $createOrderData): bool
    {
        //...
    }
}

CreateOrderValidationAction class, responsible for data validation.

final class CreateOrderValidationAction
{
    public function __invoke(CreateOrderData $createOrderData): array
    {
        $errors = [];

        //...

        return $errors;
    }
}

CreateOrderAction class, which combines the previous two classes and saves the Order and OrderLine models in a single transaction.

final readonly class CreateOrderAction
{
    public function __construct(
        private CreateOrderSecurityAction $createOrderSecurity,
        private CreateOrderValidationAction $createOrderValidation,
    ) {
    }

    /**
     * @throws OrderSecurityException
     * @throws OrderValidationException
     */
    public function __invoke(int $userId, CreateOrderData $createOrderData): int
    {
        if (! ($this->createOrderSecurity)($userId, $createOrderData)) {
            throw new OrderSecurityException();
        }

        $validationErrors = ($this->createOrderValidation)($createOrderData);
        if (! empty($validationErrors)) {
            throw new OrderValidationException($validationErrors);
        }

        return DB::transaction(function () use ($createOrderData) {
            //...
        });
    }
}

OrderController, where we simply call the CreateOrderAction.

final class OrderController extends ApiController
{
    public function store(Request $request, CreateOrderAction $createOrder): ?Response
    {
        try {
            $orderId = $createOrder(auth()->id(), $CreateOrderData::fromRequest($request));
        } catch (OrderSecurityException) {
            $this->response()->errorForbidden();
            return null;
        } catch (OrderValidationException $exception) {
            return response()->json(['errors' => $exception->getErrors()], 400);
        }

        return $this->response()->created(content: $orderId);
    }
}

The primary advantage of this approach is the ability to reuse actions in conjunction with all business requirements (security, validation, enforcing entity invariants). However, in this case, it may not be as straightforward to leverage the full power of the Laravel framework to streamline your code writing process.

Both approaches are valid choices, depending on the project's specific needs. If you don't require the reuse of entire business actions across multiple parts of your project, the classic Laravel approach is a straightforward choice. However, for larger and more complex projects, where you need to call the same entire business action, the second approach may be more suitable.

Regardless of your choice, having knowledge of both methods is valuable to make informed decisions.