clutch-2022

OpenGraph - lexis.solutions

Bilyal Mestanov

Interview

Office

Milush-photo

Meta description Lexis Solutions

Stefan Mitov

Digital tools

Agenda Admin Cover

fire emoji

Emil Kirilov

Deyan Denchev

Milush mentoring Ivan

SERP example - largest volcano

Clutch Top Developers

SERP example - how to roast a potato

Mira

Beach Photo

CTO & Co-Founder

Milush Karadimov

Software Developer

Full Stack Developer

CEO & Co-Founder

Web Developer

Mira Ereeva

Growth Manager

## Introduction

Here at Lexis Solutions, we deal with complex projects every day that involve scheduling and micro-service coordination. Until now, we had tried different solutions for job processing, but somehow we always felt that something could be done better. That’s why we decided to develop our technology and make it open source so everyone could benefit. This article explores how and why we created a new open source job queue dashboard - [Agenda Admin](https://github.com/lexis-solutions/agenda-admin).

## What is a job queue?

A job queue contains a list of jobs waiting to be processed by a subsystem. It's the first place that a submitted job goes before becoming active. The job is held in the queue until some factors are met.

There are many job queue implementations for Node.js, including Bull, Bee, and [Agenda](https://github.com/agenda/agenda). 

*Let's take a closer look at Agenda.*

Agenda is an open-source, lightweight job scheduling library for Node.js, with many features like job priority, concurrency, and repeating, which uses MongoDB for the persistence layer. 

One of the main issues is that we have to write code whenever we want to create a new job or view the old one. While it's not hard, it is slightly inconvenient. That's why we need a dashboard with all the basic functionalities, like a list of all jobs or creating/deleting jobs.

## Existing Solutions

So far, there has been only one solution to this problem - Agendash, an open-source dashboard for Agenda. It allows us to schedule new jobs, requeue or delete old ones and search old ones, among other things; however, a few improvements could be made. 

While the UI/UX could also be improved, the main issue was that many pull requests took too long to merge. Because of that, some basic functionalities, like deleting or requeueing jobs, were buggy or not working.

__Note:__ *As of writing this article, the most crucial bugs are already fixed on Agendash. Kudos to their team 💯*

![Agenda Study1](//images.ctfassets.net/5gydaotbo8jm/4PIzJMeuVmiOaXOoTEjxKx/6b510eb73073c71854bf1ab57d755c5f/1.jpg)

## Our Solution

Our goal with Agenda Admin was to create a dashboard with a clean and easy-to-use UI and all the essential functionalities we needed to make working with jobs easier:

- jobs status, refresh interval is 15 seconds by default
- search jobs by name, including autocomplete
- filter jobs by metadata and status
- view job details
- delete and requeue jobs
- schedule a new job.

The user can see a list of all jobs, with the basic information for each one - their status, name, the last time the job was run, and when it will be executed again. Filtering the list was also a critical feature, with options to filter the jobs by their name, status, or some of their other properties. 

![Agenda Study2](//images.ctfassets.net/5gydaotbo8jm/5AqzYNooJGbuSKsp2yrtWI/8e5f28e12c4a9f1ac7f9c522fbd57daa/2.jpg)
![Agenda Study3](//images.ctfassets.net/5gydaotbo8jm/5o77wmUAzhVU8BiX2JG2bQ/da1ff346433fccd71cc1fb7bac1c7b79/3.png)

## The Architecture

For this project, we went for the mono-repo architecture, with the two main subprojects being the api, written in Node.js, and the client application, written in React. This approach has many advantages, including a shared build process for both the api and the client and enforcing code style standards across the project.

We used yarn workspaces and the mono-repo architecture to improve our dependency management. This allowed us to avoid unnecessary bloat by managing the dependencies across the whole project instead of having separate node_modules folders for each package.

![Agenda Study4](//images.ctfassets.net/5gydaotbo8jm/PxP8ki2WfQRwEkN4cW3qa/4ba798dae7766ba285abf65fe35d4fc7/3.gif)

## The Development Process

We used Linear to track our tasks and bugs to make the development process more efficient. Linear's integration with GitHub was also convenient, allowing us to link every pull request to the corresponding ticket. 

Of course, it was also essential for the whole team to be up to date on the progress, so we would meet regularly to discuss what had been done and how we should proceed with the upcoming tasks.

While not the most fun part of the project, we had to ensure that every app function was covered with tests to avoid any bugs. And to make catching bugs even easier, we automated the testing process with GitHub Actions. By automatically running the tests on every pull request, we could be confident that every regression would be caught before it reached production. 

However, unit tests can only take us so far. While we could catch bugs in the logic, we still had to ensure there were no issues with the user experience. This is where we had help from the rest of the people at Lexis Solutions, as they would constantly test the app and report any inconveniences, so we could fix them and provide the users with the best experience possible.

We were also able to automate the application's deployment, including tracing the version number and publishing the package. This was achieved by using semantic-release and, again, GitHub Actions. Also, by following strict commit message conventions and prefacing every commit message with a specific flag depending on the changes, semantic release could quickly figure out the following version number. By creating an automated workflow for publishing the package, every time a branch was merged into the main, a new package would be published on NPM.

## Conclusion

Now Agenda Admin is available as an [NPM package](https://www.npmjs.com/package/agenda-admin), and as an open-source project on GitHub, at [lexis-solutions/agenda-admin](https://github.com/lexis-solutions/agenda-admin). Everybody is welcome to suggest new features or contribute; don’t forget to star it.


The process behind how Lexis Solutions created a new open source job queue dashboard - Agenda Admin.

Contributing to Open Source: How We Crafted Agenda Admin

A few weeks ago, [Lexis's CEO gave terrific tips and tricks to master your interview for any developer position](https://www.lexis.solutions/blog/tips-to-master-interviews-for-any-developer-position). In addition, we will now focus on the most crucial part before the interview: the CV. 

## Are you preparing your CV for the very first time?

Firstly, make the center of attention any internship, courses, etc., closest to your selected job offers. But if you don't have any, never be ashamed of other experiences.

Let's say you worked in the customer service field for a few years before you decided to switch your career path, or you are still a student, so you performed a job to sustain and meet your ends - put that in your resume as well. It shows you gained experience and specific skills, are aware of the work ethic and weren't switching from place to place. 

But any other courses show dedication too. Even if they don't relate 100% to the job you are applying for, the person checking your CV will consider that you have put the effort to gather [knowledge](https://www.lexis.solutions/blog/why-does-knowledge-matter) or have a specific interest and decided to develop it. Don't forget to mention participation in university competitions, hackathons, academies, etc. 

## English C1 vs. C++?

Good [knowledge](https://www.lexis.solutions/blog/why-does-knowledge-matter) of English is a must when working in IT. If you don't know it even on a basic level, the chance of you getting hired is closer to zero. We strongly suggest you put in the effort and attain a decent mastery of the English language to further your career. 

And it's not only English! Most Bulgarian developers work on international projects, so any language apart from English will be welcomed.

## Powering your skills

We live in a time when soft skills are the game changer. So never second guess yourself and list all of the ones you possess. 

You need more practice if you are not confident enough in your communication skills. Don't worry about the interview process; instead, apply for companies that are not your first choice. This way, you will gain experience without sacrificing your go-to employers. Your friends could be of help too. They might imitate an interviewer and [ask you some questions Deyan shared with us](https://www.lexis.solutions/blog/tips-to-master-interviews-for-any-developer-position). 

But, of course, don't miss all the technical skills - especially if you have any of the listed ones on the job offer.

## Does a higher degree get your foot in the door, or is the experience the one that sells you? 

Education matters, but your skills and experience will benefit you more in the real working world. A higher degree will put you ahead of other candidates only when your practical skills are comparable. 

## Social media?

Your Linkedin and Github profiles are the only acceptable links you might add to your resume, so make sure they represent you well. If any concern appears that you don't have a lot to add to your profiles - the Internet once again might be your saver. Look for a free course and enroll right away. After finishing it, highlight it on the platforms. Check if there are any IT-related events or lectures in your city, and go networking - you never know where your luck might surprise you. 

## Picture or no picture? That's the question.

Should you add a photo to your resume? It depends. As we mentioned in a previous blog post, if you are applying for a job in the US, UK, or Canada, don't submit one. [Read here why.](https://www.lexis.solutions/blog/tips-to-master-interviews-for-any-developer-position)

If it is not explicitly mentioned that you should put one, it is a personal choice whether to add it or not. Some recruiters might argue and advise you not to do it - especially if not required. 

A passport photo is always the best option. Don't forget - the picture should be appropriate, never one from your prom, birthday party, or wearing something provocative. Usually, how you look is the least important to the hiring team, but adding an unsuitable image will probably play a bad joke on you.

## Note that your CV should be easy to read.

The hiring team will probably not spend much time scanning it, especially if there are many applicants. So here are some tips:

- use a black, easy-to-read font in one size  
- use short sentences and break up blocks of text
- use bullet points to list information
- keep the tone formal
- avoid abbreviations, slang, or jargon
- аvoid additional photos or images
- have strong headings
- keep your CV to a maximum of two pages.

__*Pro Tip 1:*__

Sometimes you might need to adapt your CV to the specific job offer. So always have the ready-to-go version (best if it is PDF saved), but always try to make it work for you so later you can work for them! Make your research on the company - see what they value and the leading technologies they use - and highlight that on your resume, especially what they want and what you have aligned.

__*Pro Tip 2:*__

Make sure your email sounds professional. It should only consist of your name and surname. Nothing else. No numbers (especially the year you were born) or any nicknames. And check a few times if you haven't missed a digit when adding your phone contact.  

__*Pro Tip 3:*__

Leonardo Da Vinci once said, "Simplicity is the ultimate sophistication." So take that in mind when creating your CV. Don't choose a colorful template or one that would be suitable for jobs on the more creative side, and try avoiding the European variant. 

Never pay for "special" options; there are many free platforms where you can create a simple but beautiful resume. For example, you can always use [Enhancv ](https://enhancv.com/)- a Bulgarian CV builder. 

## Motivated people always find a way

A motivational letter might be the joker for you who just started applying for jobs. Of course, you could read a few to get the right idea. But, please, never copy from a ready-written-one; the recruiters will notice immediately. 

The letter should be coming from your heart but always professional looking. Find common ground between you and the business, and focus on that. Try avoiding cliches; give examples from your studies and experiences of why you are suitable for the given job. Or explain how you picture yourself growing in the company and how determined you are to do so. 

## Know when enough is enough

Whether making your CV for the first time or updating it, you should never forget that the point isn't to drown the recruiter in your life history. It is all about balance. Before submitting - ask yourself, did I pitch myself well enough? 


A focus on how to create a CV quickly, simply, and efficiently. 

Make your CV the Ultimate Winner

## What is SEO?

SEO stands for Search Engine Optimization and is a term that indicates whether your site appears at the beginning of search results in Google, Bing, Yahoo, etc. Getting to the top of the lists gives you an overwhelming proportion of the click-throughs while showing on page two means you have lost 99% of potential clients. [[statistic 31.]](https://www.impactplus.com/blog/seo-statistics)

## SEO market

As with many of the impactful technologies nowadays, SEO opened a new business niche and created a market for itself. The product is people's attention.

Every person on Google is a potential customer. They have an idea of what they want, they type it in and end up on your site. This dream scenario is the goal of SEO and the reason people pay experts. The results you get will either let your business flourish or end it.

In this article, we explore practical steps developers can take to either boost the SEO of an existing site or lay the proper foundations for a brand-new business. Either way, you can surely benefit from SEO knowledge as it is marketable and in demand.

## What can developers do?

It turns out that you - the developer, have a huge impact on SEO. There are many options before you, so allow me to narrow them down and list a dozen with the biggest impact.

### Must DOs

> **Make your site crawable**

Search engines visit your site via a crawling bot. You can think of it as an unregistered user that will only be able to see what a guest user can see. Any information meant for paying users will not be accessible nor taken into account when the bot scores your site. Be thoughtful and provide relative content free of charge so Google and Bing can actually have something to show of you.

> **HTTPS**

Please, get an SSL certificate. Not doing so is the quickest way to sabotage your website's discoverability as all modern browsers will prompt users not to trust your site unless the connection is secure. The reputation cost you pay will outweigh any and all optimizations you have done so far. This is a must.

### HTML

Crawling bots don't operate the way we do. They cannot look at pictures and decide whether they are helpful. They neither watch nor listen to videos. Bots rather read the source code of the site and do their scoring based on its structure and semantics. HTML is in their blood and hopefully in yours too.

> **Page title**

The page title is of primary importance [[statistic 18.]](https://www.impactplus.com/blog/seo-statistics). It is set via the `<title>` tag and provides the name of your pages and the titles of search results in Google.

You must make sure that all resources in your platform have an identifier that can be used as a page title.

**Pro tips:**
- keep titles 50-60 characters long
- keep it simple, unique and try to use keywords

> **Description**

Descriptions are texts that appear below the titles of search results. They provide additional information and can boost your position and click rates as keywords are bolded and indicate that your site is relevant.

![Meta description Lexis Solutions](//images.ctfassets.net/5gydaotbo8jm/4HW1R7VBnHsCtcbqBO2pDG/20480cd37c99df19dc53064558ba58d4/meta_description.jpg)

You can hardcode descriptions for index pages, however, you should lay the groundwork and have a separate column when it comes to show pages. Talk it through with your client and leave an input field that admins populate upon document creation.

From a developer standpoint providing the meta description is easy. Add `<meta name="description" content="...">` to the `<head>` element.

**Pro tips:** 
- aim for a sentence or two (~150 characters) 
- make it descriptive and in sync with your content 
- use keywords and avoid duplication of meta descriptions 
- differentiate by adding an emoji - the color will set you apart and attract clicks; take a look:

![fire emoji](//images.ctfassets.net/5gydaotbo8jm/5YBhlpi8GF62MvrEHWAzVH/b0901fb2ba24c62a94ecf06229d8aa7f/image.png)

> **Headings**

Heading tags have a built-in hierarchy. The top-level heading is `<h1>`, followed by `<h2>`, `<h3>`, and so on to the lowest - `<h6>`. The proper usage of headings outlines the structure of your text and helps readers scan it quickly. Whenever a heading catches the attention of a visitor, they will surely spend time on your site and improve its rating as Google takes into account the duration of page visits.

**Pro tip:**

Set up your project for success by designing your DB schemas in a manner that allows and guides admins into providing titles, subtitles, lists of questions and answers, etc. that can be transformed into a hierarchy of headings. Such information will prove useful for other SEO practices too.

> **nav tags**

Bots treat the HTML at the top of the source code as the most important and lower the significance of tags found later. This means that any headers at the top of the site could greatly influence the scoring of your pages even though they are duplicate content. That is unless you surround them with `<nav>` tags. When you do that you indicate to crawlers that this content is for navigational purposes and serves to improve the usability of the site.

> **Structured data**

Structured data is a JSON that you put inside of a `<script type="application/ld+json">` tag. It speaks directly to bots and explains to them what the page they are currently crawling is all about. Structured data also serves as a suggestion of how search engines should display the data.

Try searching for "how to roast a potato" on Google.

![SERP example - how to roast a potato](//images.ctfassets.net/5gydaotbo8jm/6XQqaS0m9YIq5xQT7KiFdR/5e263bd42b5a78d827853d17567007e3/how-to-roast-a-potato.jpg)

Now try "largest volcano".

![SERP example - largest volcano](//images.ctfassets.net/5gydaotbo8jm/6HfiTZ4TAvn5jONQHg7jVm/62bb705f7a7fe9b20692c2e61340d39c/largest-volcano.jpg)

Sometimes Google crawls credible sources that have well-written structured data, understands what the data represents, and uses it to show default answers for specific searches. As long as the site follows the official markup listed at Schema.org search engines are able to differentiate facts, recipes, people, places, organizations, etc.

> **Open Graph**

OpenGraph was first introduced by Facebook and provided a way to share links and get a nice preview. In time, tech companies adopted the `og:` meta properties and OpenGraph became the norm. Here is what you get for a few lines of code:

![OpenGraph - lexis.solutions](//images.ctfassets.net/5gydaotbo8jm/23tUxXpKSARpNwP7sK1PI7/76e9f0542a6451d4a43f7a4dffa01f75/OpenGraph_-_lexis.solutions)

You can check all available meta data properties, how, and when to use them [here](https://ogp.me). The fundamental ones that you should know are *title*, *description*, *type,* and *image*. They are added to the `head` element like this:

1. `<meta property="og:title" content="Lexis Solutions - Your Ideas, Our Solutions."/>`
2. `<meta property="og:description" content="Lexis Solutions is a software agency..."/>`
3. `<meta property="og:type" content="website"/>`
4. `<meta property="og:image" content="..."/>`

__Pro tips:__
- make *og:title* and *og:description* the same as the page title and the meta description 
- music and video have dedicated meta data properties 
- Twitter have their own standard

> **Canonical URL**

Sometimes you have duplicate content on multiple pages. The crawling bots of Google will realize that and show only page in the search results. If you want to pick which one that should be you can specify a canonical URL. It's as simple as adding a new `meta` tag and it will allow for multiple pages to collect a joint reputation. The code is added to `head` element like this: `<link rel="canonical" href="https://lexis.solutions/" />`

**Example:**

Let's talk about calendars. The thing with calendars is that the new ones should dethrone the old ones, SEO-wise, immediately. This is easily achieved by taking advantage of canonical URLs, and we have tested it! Generate the URL for the newest calendar and have all calendars point to it "canonically". This way you seamlessly transfer the reputation and appear at the top of Google.

> **robots meta tag**

You can tell crawlers whether to index your pages, follow links, show images in the search results or ignore your page completely. Actually, they understand a broader range of commands that you can read [here](https://moz.com/learn/seo/robots-meta-directives).

In my estimate, the ones you need to know are *noindex*, *nofollow*, and n*one*.

*noindex* instructs bots that the current page should not be shown in search results. *nofollow* indicates that you do not trust and do not wish to be associated with links on the current page. 
*none* combines both *noindex* and *nofollow*.

Your preferred directive is added to the `head` element like this `<meta name="robots" content="...">`

> **img alt**

Bots don't analyze images and fully rely on the `alt` attribute to make sense of pictures. All `img` tags in your project should include alternative information like this: `<img src="photo.jpg" alt="description">`

**Pro tip:**

Provide a relative description as the alt attribute. It does count and will increase your SEO rating. 
Bear in mind that setting false or misleading descriptions may get you penalties.

## Conclusion

By now you should have a basic understanding of the importance of HTML structure and semantics. This knowledge alone should get on the right path. 

Your next steps should be aimed at optimizing load speeds, providing sitemaps, resource schema and utilizing some of the tools available out there. Go read and learn more on the topic through the follow-up article on SEO!

SEO is straightforward for developers - follow a few basic principles, optimize your code, aid crawlers and use tools to help you at every step. 

SEO for Developers - Part One

Hiring junior-level talents has always been a challenge. It is no coincidence that many software academies have appeared to try and ease the hiring process of beginner-level developers. However, it is always the company's responsibility to bring their new colleagues into their culture, processes, and conventions.

In that regard, we are happy to have developed an excellent mentoring system that has proven effective and gained positive feedback from the trainees.

I will share the main points of focus for the duration of our mentoring program.

## Time frame

The time needed depends on the experience level of the trainee. Generally, **3 to 6 months** is the standard period for a young colleague to reach a competent skill and confidence level to participate in larger tasks as part of a team.

## Points of focus

We have divided our mentoring program into four main parts that develop problem-solving skills and simulate real work experience. In the end, it is expected that we cover the following aspects: 

-   Going through the software development cycles

-   Working comfortably with git

-   Following code conventions and simple code practices

-   Dealing with unexpected requirement challenges

*With that in mind, here are the four main focus points:*

### 1\. Solve algorithmic problems and go through a pre-selected course

Depending on the level of experience of the colleague, this part could take from a couple of weeks to more than a month. The main idea is to practice problem-solving skills in a particular language and get familiar with git and the command-line interface. 

### 2\. Solve a non-trivial algorithmic problem

This phase is pivotal in our mentoring program. We pick a more significant task involving working with a more complicated data structure, for example, a graph. During this task, the trainee must also implement a custom variation of standard algorithms like depth-first or breadth-first search. 

By the end of this phase, we have a working console application and are ready to move into a more real-world setting. It usually takes up to a month to reach this point.

### 3\. "Apify" our console application

This is where we introduce a more structured approach to software development. We attempt to simulate an actual project setup and present common challenges in that scenario.

The goal is for the trainee to expand their [API](https://www.lexis.solutions/blog/how-to-test-REST-ful-APIs-with-postman) development [knowledge ](https://www.lexis.solutions/blog/why-does-knowledge-matter)with a concrete tech stack. To help with that, we provide courses as an additional resource, but we prefer hands-on experience, so we give out an initial API project structure that needs to be followed down the line. 

The first task we set is integrating our previous console application into the RESTful API project. This provides a good challenge for less experienced developers because they need to shift their way of thinking in the context of [HTTP](https://www.lexis.solutions/blog/beginner-frienly-http-requests) communication. They start to handle aspects such as: 

-   parameter validation

-   state management

-   [HTTP](https://www.lexis.solutions/blog/beginner-frienly-http-requests) methods

-   CORS

After that, we expand our project with additional features that introduce working with databases, authentication, and authorization.

An important notice here is that the new [developer](https://www.lexis.solutions/blog/who-runs-the-world-programmers) gets introduced to an ORM framework at a later stage, so they can realize and better understand the benefit it provides.

Another critical approach we use is to simulate requirement changes. So once the developer is done with the main API features, we plan a new set of features that require some refactoring. This is a good practice for the real world, where clients often have second thoughts, demonstrating the value of keeping a clean code convention.

We often dedicate a long time to this phase of our mentoring program as it creates a reasonable basis for work habits and introduces feature planning and code review processes.

### 4\. Work on an internal project or build a front-end solution

At this point, our young colleague is ready to take on more responsibilities in a team. Depending on their interests, the trainee could take on a role on an internal company project as a back-end developer or work on his front-end skills. 

Our front-end phase is quite similar to the API development phase described above. It directly consumes the REST endpoints and focuses on the React tech stack. The main points of focus include: 

-   CRUD cycles

-   React state management (redux and hooks)

-   Front-end validation and response management

-   Authentication handling

## Conclusion

So far, we have multiple colleagues who underwent our mentoring program and successfully joined some of our teams. Judging by our experience, it is essential to offer a challenge and bring it close enough to the real-world application to keep the trainee’s interest and involvement. We know the necessity of practicing problem-solving skills, but we also learned to integrate them into a bigger-scale learning project, and with the feedback and success we have gotten so far, it seems we have found the right strategy.

The following article describes how we developed a system for integrating intern and junior-level colleagues into our existing work processes

Tips for mentoring Junior-Level Developers

## Lexis Solutions decided to hit the Greek road at the beginning of September. 

Just a month after [Lexis turned 5](https://www.lexis.solutions/blog/5-years-lexis-solutions-rooftop-party), its team gathered together on Thassos island. In 3 days, the teammates not only got closer but immersed themselves in the Greek culture by enjoying the beautiful beaches, the traditional food, and dancing to its music.

![Lexis' Team-taverna](//images.ctfassets.net/5gydaotbo8jm/1OZC9GoJ8gc4W78EITnmz4/a5f3095cb5ab70a9d7687e678ef09e00/20220903_215950.jpg)

We knew Lexis's team and some of their loved ones; five cars and a 6.5-hour journey demanded careful preparation. So, we got up early and left Sofia before the morning traffic jammed the streets. Neither the rain nor the waiting at the border could sink our spirits. But what about the ferry? 

## Is the ferry scary?

Firstly, it took some configuration, who should travel in whose car, but finally, Lexis' team started approaching its first aim - the ferry. Surprisingly some of us hadn't been on a ferry before but soon realized it was not that scary. And after all, you can observe all the beauty around it.

![Ferry-view](//images.ctfassets.net/5gydaotbo8jm/1XHe2knWcvqaiVhSjtssoS/dc14dc536125904ffb27ca0fcbc0a73f/20220904_151506.jpg)

After a few fun hours, Lexis Solutions safely arrived at Mon Avis Boutique hotel, which Bulgarians ran to our surprise. We did book 75% of the hotel, so you can say we had a private pool.

![Dilyan na hotela](//images.ctfassets.net/5gydaotbo8jm/3FSz2fYANcTtOPNpIWmNFr/e037c86a8120ff76c693c0a9d8c368de/IMG_1245.jpg)
![baseina, v koito taka i ne vlqzohme](//images.ctfassets.net/5gydaotbo8jm/4dhKHnPQTzuQooUUxQjxns/1f174ed37318688980b2af68d6e872c7/20220902_192447__1_.jpg)
![Bilyal chok gyzar](//images.ctfassets.net/5gydaotbo8jm/1wrt8e7FA9gPkKkx8YNt0D/8f0da3c04171396c57637ad1eaad0deb/IMG_1244.jpg)

## From developers to real volleyball stars 

It took us one visit to a Thassos beach to realize that real volleyball stars are hiding inside our developers' hearts. For the whole vacation, the typical yellow ball never left our hands. So the game became crucial in our team building. 

![voleybolnite zvezdi na lexis](//images.ctfassets.net/5gydaotbo8jm/1b39St46KQAWlNcth4Q8Nc/bbc03dd84cfe1a4af074ab29c738622b/20220904_134139.jpg)
![voleybolni zvezdi v moreto HD](//images.ctfassets.net/5gydaotbo8jm/10rkn37N4uQueaXZfMUk2y/5b48acf896531387782967715ecd132b/image.png)

## 1, 2, 3... Jump!

The famous Thassos place, Giola tested Lexis' team's bravery. Even though some just observed, others didn't hesitate to jump from quite the distance into the sea!

![vsqka jaba da si znae giola](//images.ctfassets.net/5gydaotbo8jm/12QPBs8uX4JmrtMd9qRQw8/feb27d8d94413a789be076b68b1a4f4f/20220903_105633.jpg)
![skachameeee](//images.ctfassets.net/5gydaotbo8jm/1ySjk183vXjdGt0bwzq6L9/9b76b8151de25cdd74bc64ea7543ac6a/20220903_122254.jpg)

## Shrimps here, calamari there

But what is Greece without its typical delicious cuisine? We visited two fantastic local tavernas, where we tried a bit of everything. 

![krasivi](//images.ctfassets.net/5gydaotbo8jm/2cYbkTheJs3FktspWOlgkb/6386ca2bab813b66a050b5b18497379d/20220902_204051.jpg)
![pak krasivi](//images.ctfassets.net/5gydaotbo8jm/2l6zk8ihivt80WUvnVgO9n/fc264aaaa970c274571ff32c26534840/20220902_203830.jpg)

## Yes or no? 

Except for all the eating, we spent our evenings getting to know each other by playing different games. Even though one game (which we will keep for ourselves) confused pretty much everyone and made some laugh, others mad, in the end, it got us closer than ever.

![Viktor i Ivan ot Stara Zagora](//images.ctfassets.net/5gydaotbo8jm/5jDm7YYc0WNxRpBRcRl3yq/77b156c9d45500921d1958a84b349cfe/20220904_001247.jpg)

They say when you are with the right people, the time passes faster. Definitely, the 3 days Lexis Solutions spent at Thasos island felt like more like 3 hours. 

![lexis bez Nikola i Dilyan, koito ni izostaviha](//images.ctfassets.net/5gydaotbo8jm/7yJ7tcaXpqYdGWClzoAbjD/f4d03152de02868bc1add1aff35121e9/Copy_of_DJI_0119.JPG)
![nomer 1,2,3,4](//images.ctfassets.net/5gydaotbo8jm/5CGKfFcqdy8yg1D8fjsyK9/8710e450da9522f68abf5d312fe243d2/20220904_113204.jpg)


Lexis Solutions is exploring Thassos island. 

Lexis Solutions: The Thassos Adventure

Lexis Solutions isn't just a team of expert developers with decades of combined experience. We're also a team that deeply cares about our clients and how our work impacts their operations. This is why we invest so much time and effort into ensuring they get exactly what they want. Now, this approach is paying dividends for us because our clients have just helped us get named one of the best development companies in Bulgaria for 2022 by Clutch.

![clutch-2022](//images.ctfassets.net/5gydaotbo8jm/1bqxnzG0Odn2LJ70Fsdmi0/616e22ec34393e533cad512222b09f66/image1.png)

Clutch is an online review and rating platform providing the B2B industry with important research on fact-finding. They do this through their unique verification process that tests information for authenticity before publishing them as reviews on their site.

Their [2022 research showcases](http://clutch.co/bg/developers) that we're at the top of the country's development industry because we've gained the approval of our clients and partners. Clutch's driving criteria are the number and quality of reviews written and published on a company's profile.

> "*We are delighted to receive such positive feedback from Clutch. This recognition only strengthens our belief in providing top-quality services to our customers. It does mean a lot to see that our way of doing business is appreciated and celebrated. Lexis Solutions is thankful for the clients we met and left a positive review for us. This award is as much our as it is theirs.*"
> 
> Deyan Denchev, Co-Founder of Lexis Solutions.

Lexis Solutions is growing, and we are rapidly expanding our skillset. Each client provides us with unique challenges and interactions we can learn from! The team is eager to face the challenges ahead, and if your project is exciting, we would like to hear from you!

Please contact our team for more information on how we can connect as soon as possible.

Clutch's 2022 team article about Lexis Solutions.


Lexis Solutions is a Clutch Top Development Company in Bulgaria for 2022

I started my software engineer career in a big corporation as a backend developer. Then I moved on to the startup ecosystem building many projects from scratch, joining existing dev teams as a contractor, and building dev teams on my own. In the six years that I’ve been involved in software development, being part of different environments taught me great lessons where I succeeded in gaining broad experience and various skills throughout my career.

Throughout the years, I've taken many technical interviews and introductory conversations for different positions both as an interviewee and interviewer.

Let's talk about how you can introduce yourself to the finest and achieve the best results.

__CV:__

It is crucial to do it well once!

## General info:

- Choose a simple design that emphasizes the important topics
- Use a professional-looking email
- It's recommended that you add a LinkedIn profile and a GitHub profile (but only if you have something good to show)
- Don't neglect soft skills. They are as important as hard skills. List them in an easily visible place.

*Pro Tip:*

It would help if you did not put a picture on a resume in the US, UK, or Canada. Do not submit a resume with a picture, as these countries are bias-conscious. Employers are worried about discrimination lawsuits and often discard resumes with pictures out of policy. A resume with a picture isn't a wrong thought, however. It lets employers connect the sheet of paper with a living, breathing human being. It ensures they won't forget you or confuse you with another applicant. 

Unless you know for sure that the company won't do that, don't add a resume photo.

__Education:__

Education is not always a key point for clients to focus on while analyzing a CV. However, having specialized education or relevant training for the project will be an advantage.

__Technical skills__:

Don't list the technologies you have barely worked with or are irrelevant for the position. Place the technologies mentioned in the job description first. This way, you ensure that the interviews won't miss the information that it's crucial for them. It's a good idea to separate the technologies by categories (Front-end, Backend, DBs, Services, etc.). 

__Work experience:__

Sort the work experience by descending order - list the most recent work experience/projects first. If there is a sizable missing period, be prepared to share the reason. Putting 3-4 sentences/bullet points for each work experience is essential. Try to think about how you can stand out. Mention the things that show your most significant achievements, your contribution to the specific project/topic, and sound attractive to newcomers.

It will be a plus to add a link to your projects. This way, the interviewer gets an excellent opportunity to see your work's results. 

__Interview preparation:__

An interview is a dialog intended for the parties to get to know each other. 
There is a misconception among many people that the interview is like an interrogation. 

No. While a client wants to ensure the developer has the necessary technical skills and fits the client's team, the developer learns more about the client's product, team, and current state of affairs.

I recommend preparing for the interview minimum of 2-3 weeks. It would help if you started revising essential topics connected to the job position during this time.

*Ex.* Let's say you apply for a Senior Front-end position. It'll be a significant red flag if you don't know what a DOM is, what an attribute is in HTML, or if you can't name the difference between synchronous and asynchronous code.

It would be beneficial if you continued revising specific questions depending on the job position. There are tons of articles that list interview questions for different programming languages and positions.

Simultaneously please start researching the right company choice.

I highly recommend scheduling at least 3-4 interviews (the more, the better) even if you have a favorite company. During the interviews, it may turn out that this company is not the perfect choice for you. Often job descriptions are vague and don't include essential information like your responsibilities.

__Right before the interview:__

- Turn off the sound and vibration mode on the phone during a call;
- Turn off the sound of notifications on the computer;
- Check if you have a link to join the call (min. 10 minutes before the call);
- Check if your headphones and camera are working properly;
- Find a light and monochromatic background so that there are as few; household details on the background as possible. 

__Communication:__

The client usually understands perfectly well in case you are not a native speaker, so there is no need to stress out about imperfect English or minor grammar mistakes. However, it's essential to make sure you pronounce professional terminology correctly.

If what the customer is saying or asking is not clear, please do not be shy and ask them to repeat it.

At the interview's beginning, the other side usually introduces the company and the opening position briefly. After that, you are welcome to introduce yourself. 

*You should mention:*

- Your name and main specialization highlight your areas of the most; profound expertise (1-2 sentences);
- How many years of development experience in total;
- Preferred technology stack.

*Then you can add more details:*

- What industries/domains have you worked in (marketplaces, healthcare, e-commerce, fintech, etc.);
- What projects are you most proud of and why?

Discussing what you've prepared rather than just answering the interviewer's questions is better. At the same time, try to organize your thoughts and avoid being chaotic. 

You should emphasize if you have relevant experience with the client's project/domain/technologies. This way, you will stand out among other candidates.

*Pro Tip:*

- Try to give complete answers rather than answering with Yes and No;
- You should pay attention to how the interviewers react to what you are saying;
- You should round up your monologue if they don't look curious or bored. 

## Some questions that interviewers have asked me:

- The biggest professional challenge I've faced?
- Share my achievements.
- Share compelling examples where my coaching to other developers has led to outstanding team achievements.
- Have I worked remotely before? Have I worked in fully distributed teams? How do I feel about it?
- What are the best communication practices for remote work?
- Why I've chosen specific technology over another?
- Have I been a part/taken care of product deployment?
- What challenges have I faced during deployment?
- Have I taken the leadership role in any project?
- How I would solve specific technical challenges (depending on the role)?
- Why am I considering walking away from my current/previous job?
- How do I deal with disagreements with a colleague?
- What infrastructure am I using (Mac, Windows, Linux, etc.)
- In what situations I'll it be ok to work with legacy code rather than refactor it.
- The most exciting project I have worked on. Be ready to explain what was so special about it. If it's hard to think of something, you may recall a complex feature you had to accomplish and explain why it was challenging to build and how you overcame it.
- What are my favorite software books/articles/videos/podcast episodes/open-source projects?
- Have I ever contributed to open source projects?
- What channels do I use to stay up-to-date with the newest technologies?
- Do I do any testing?
- Do I write unit tests?
- When will I be ready to start working on?

*Pro Tip:*

If you cannot understand the answer or need a tiny hint to remind you of the solution, don't be afraid to ask for details. If you still can't answer it, it's ok to say: "I can't think of it right now," for example. 

## Prepare your questions for the client. 

It would help if you prepared questions for the client. This way, you show that you're highly interested in the position. You're not willing to work in whatever the company is; instead, the company should meet your standards.

__You can ask about:__

- Their product and business model
- Their plans for the future
- Their processes (schedule, communication channels, task/bug tracking, release management systems)
- Team structure; who is going to be your immediate manager or the main person of contact
- Their expectations and deadlines
- Specific questions about the range of your responsibilities
- Does the company/team comply with specific code standards.

It's crucial to take time and prepare to present yourself as the best. I've noticed that it's hard to answer specific trivial questions in case I haven't taken technical interviews for some time. This is because, in your day-to-day work, you're either working with a specific set of tools or just using the tools/paradigms without thinking about how exactly they work. 

### Choose the company, don't let the company choose you!


 Major Dos and Don'ts to bear in mind for your following interview.

Tips to Master Interviews for Any Developer Position

Agree to disagree - digital tools make our lives easier, but the bigger question is at what cost? For sure, digital access made it possible to communicate and do our jobs efficiently, especially during the pandemic. We have all those apps and platforms - to create, collaborate or distract ourselves for a bit. And this is the biggest downfall of the digital revolution we are currently experiencing - sometimes, even during work, we delight ourselves for more than a bit. 

But let's see some of the positives and negatives of digital tools:

Firstly, digital tools offer benefits like quick access to information, diverse learning, contextual learning, control over one's understanding, support, and encouragement; generally speaking, it is pretty compelling.

## Communication is the key

Communication is the foundation of everything. Strictly digital tools play a significant role in the way we communicate nowadays. With hundreds of different apps, you can contact anybody from all around the globe in seconds. 

And precisely, the digital tools were a great asset when millions of people had to start working remotely because of COVID-19.

Zoom, Skype, Facetime, and Google Hangouts have come in as saviors during the pandemic. They have made organizations across specific sectors continue with their operations and allowed global corporations to host webinars, and conferences, strike important deals, and whatnot.

## Network remotely

Because of the increase in digital tools, networking capabilities and opportunities have enlarged. For example, Twitter and LinkedIn are comprehensive standards for creating connections.

Corporations will connect with anyone within the same business or approach potential purchasers curious about their merchandise or services. It doesn't need any cold line of work or emailing; connect and say your word.

## Productive enough?

Indeed we have an overwhelming number of digital tools available, and it is pretty challenging to determine which ones might increase our work productivity.

As already mentioned, the tools could be helpful, allowing us to communicate more easily with colleagues. Still, we could also use them to track our projects, delegate tasks, proofread our emails, etc. Therefore there is a reduced chance of human error. 

An average person uses four to five applications daily. However, the time spent on helpful activities is curtailed by 50% since individuals tend to waste their time on social media applications.  

The tools can be a significant distraction, pulling us away from the task at hand and making it difficult to focus, especially with the rise of Tik Tok and such platforms. 

##  Privacy in the digital world

We live in a world with sensors and surveillance cameras all around us and recording devices and gadgets constantly monitoring what we do, which is a high risk of your personal information being taken. For example, platforms such as Google Maps watch and record our movements. Every month you get information about how many kilometers you passed last month, the places you visited, etc.

Everyone with a smartphone has the power to take photos and video footage, then post it online on social media. Therefore everyone can see exactly where you are. And it might be dangerous, especially if some of your followers are *extremely friendly*. So, the best solution here would be to upgrade your digital literacy. 

## Conclusion:

For sure, digital tools can cause a distraction if not handled wisely. It can rather tempt us to procrastinate than increase our productivity. However, their benefits somehow outweigh the side effects.

Do you want to boost your productivity and reach entirely new levels? Well, digital tools help you stay focused and overcome that procrastination like a true champion.  

But remember, after all, they are just tools. You can use them beneficially, use them wrong, and even hurt yourself. 

The truth is that one must become acquainted with and master them; otherwise, they risk being outcompeted in this world of digital tools.

__Resources:__

1. Altshuler, Tehilla Shwartz. Privacy in a digital world. - In: TechCrunch+. Available from: https://techcrunch.com/2019/09/26/privacy-queen-of-human-rights-in-a-digital-world/?[https://techcrunch.com/2019/09/26/privacy-queen-of-human-rights-in-a-digital-world/](https://techcrunch.com/2019/09/26/privacy-queen-of-human-rights-in-a-digital-world/) [19.08.22] 
2. Bhumiraj Raut, Sanjivani. Do Digital Tools make us More Productive or Less Productive at Work? - In: Irjet.net. Available from: https://www.irjet.net/archives/V8/i4/IRJET-V8I4494.pdf [19.08.2022]
3. Sarma, Rajan. Do digital tools make us more or less productive at work?  - In: CIO Tech Outlook. Available from: [https://www.ciotechoutlook.com/news/do-digital-tools-make-us-more-or-less-productive-at-work-nid-6160-cid-64.html](https://www.ciotechoutlook.com/news/do-digital-tools-make-us-more-or-less-productive-at-work-nid-6160-cid-64.html) [19.08.2022]


A dive into the positives and negatives of digital tools.

Digital tools - Pros and Cons

I wrote my first line of code that went to production six years ago. It was the summer after my Computer Science bachelor's began, and I was eager to put all of the [knowledge](https://www.lexis.solutions/blog/why-does-knowledge-matter) I got up to that moment to good use. I developed an app, published it to the Play Store, and quickly reached users who still use it today.

![Screenshot](//images.ctfassets.net/5gydaotbo8jm/4EpPtEMNRbVEt0thNwH9NU/c00d2d9e246f99ffdadbcc164199805a/image_2_.png)

Over the years, with many projects and the privilege of working with gifted engineers, some realizations occurred to me that helped me become a better professional. To celebrate the occasion, I compiled a non-exhaustive list of a-ha moments I had, to depict the path and learnings of a (WIP) software engineer.

## Standardize code

It came to me as a revelation when I realized the best way to write code is to try to do it as a machine would. Define a set of rules and stick to them. Use style guides and tools that enforce them as much as possible. ESLint & Prettier have been an absolute must in the projects I have started. While those are great for syntactic "dumb" conventions, higher-level conventions can be extracted to the README - followed and exercised with every PR by the team members. Use the same "tropes," "patterns," or ways of doing things in similar contexts. And while one might think this is only good for teams, a single-person project can quickly deteriorate and become a mess. As there is nobody to stop you from writing however you like, developers are not consistent in their style and prone to mixing and matching styles and ideas. The advantages of *trying* to write code like a machine are manifold.

First, this drastically reduces the number of tiny decisions you have to make, e.g.

-   Do I name this const object `Colors` or `COLORS`?

-   Do I define my `useCallback`s first or my `useMemo`s?

-   Do I name this endpoint `allUsers` or `users`?

-   Do I write `if (foo) return;` or `if (foo) { return; }`

-   Do I use a named function or an arrow function?

These tiny decisions eat away from your energy to focus on what's genuinely human about programming - the creative part.

Second, this makes refactoring easier. Find and replace works best if the codebase has a consistent style.

Third, this reduces the friction of switching projects in an organization if the projects use the same (or similar) conventions.

Fourth, there are fewer merge conflicts - saving you time otherwise spent on solving those. In the last years, my teams have used tools to order the imports in files deterministically and order the props of a React component. Not a single merge conflict regarding those has risen since then.

## Know your tools

Whatever development tools you use, take some time and learn the ins and outs. At the top of the list is your IDE or editor and the terminal, where you spend most of your coding time. There are many tips and tricks videos on Youtube, and 10 minutes of your time now can save you years of doing simple tasks sub-optimally. Not only will this make you more productive, but there are many occasions when you share your screen and work with a peer or manager. People certainly notice if you are fast with your tools, making a great impression.

## Chase simplicity despite complexity

I notice, especially at the beginning of their careers, developers solve problems bottom-up, solving parts of the big problem and then trying to piece everything together. Doing so often results in bloated and complex code, which is prone to becoming spaghetti and is hard to maintain. In my first project, I certainly remember how proud I was when I wrote a Java file with 1.2K lines! What I discovered as a better method of going from spec to implementation is top-down, not worrying too much about detail, and trying to get the bigger picture right. In this feature which are the main components? How do they interact? Are there dependencies? Of course, things will not be apparent right away. What works for me is a cyclic process:

1.  come up with a big picture

2.  go into detail about a component

3.  inevitably things come up that require changes to the big picture

4.  update your existing big picture; in most cases, this will bring complexity

5.  can it be simplified and still do the same thing?

6.  repeat 2-5 until ready for implementation

Requirements push the code towards complexity. As developers, we must do our best to counteract that force by trying to solve those complex problems with the (possibly) most straightforward solutions. After all, the best code is less code.

## Don't overdo abstraction

Talking about less code, taking that idea to the extreme can also be counterproductive. By all means, I am guilty of building abstractions over classes that are vaguely connected only to extract a 3-line class method. I have also written some shared packages that became more of a headache to maintain, only to follow the famously evangelized DRY principle in countless programming books. The bottom line is that sometimes abstraction is not worth it. Before building an abstraction, weigh the pros and cons of maintaining another software artifact versus having multiple instances of it in existing artifacts. Ask the question, how similar are what you are trying to abstract away in essence, in pure words, as an entity, not code? This lesson was a revelation from no other than Dan Abramov (not the creator of React) from a 2019 talk, "[The Wet Codebase](https://www.deconstructconf.com/2019/dan-abramov-the-wet-codebase)," which I highly recommend.

## Read the documentation (no, for real)

An inspiration for countless memes, the documentation is often ignored when you hop on the hottest new dev tool/technology. Not only does it provide a structured way to comprehend the technology, but it also outlines edge cases that you might not even be aware you are getting into. A while back, my team employed Prisma for an ORM to large-scale project. It was using GraphQL in conjunction, and we had missed reading [this](https://www.prisma.io/docs/guides/performance-and-optimization/query-optimization-performance#debugging-performance-issues) little guide on query optimization and the n+1 problem, which is precisely the problem we shipped to production unknowingly. After some performance issues, a team member finally spotted the post, which fixed our problem.

The bottom line is that the documentation provides not only what a tool can do but also its limitations, what to watch out for, what's the roadmap, how well maintained it is, and who the people behind it are. Avoid treating it as a flashy advertisement but as a receipt that describes how to use it, its side effects, and what can go wrong.

## Use and build tools to consolidate the development process complexity

As a project evolves, it gets more complex to deal with during development. Maybe you have microservices and need to start all the services one by one, or perhaps you extract translation keys before starting your front-end. To minimize the learning curve, any task or process newly onboarded developers have to learn is better consolidated in shell scripts. These scripts rarely change; keeping them in the git repository will make your workflow faster and shorten the time for new hires to start being productive. If you see an opportunity to create tooling that doesn't exist, go for it. It could be a simple shell alias as `alias ys=yarn start`, a VSCode plugin, a dev dependency, an integration, you name it; even saving a few keystrokes counts. Chances are, your team or even external communities of developers could also benefit from it.

## Notice when you are stuck

There is nothing heroic about trying to solve a problem on your own at any cost. Give your best attempt, maybe twice, but learn to recognize the moment when you should seek to speak to someone. And notice I don't say seek help. I have seen some of the most significant breakthroughs happen while simply explaining where someone is at with a problem. It doesn't have to be your engineering lead or CTO; it could be your peer or even someone with less experience than you. A simple "hey, does anyone have some time to check out this problem with me" on Slack can go a long way. Is nobody online? Come back to the task after a walk, run, or a good night's sleep. Almost any senior developer I know does this. Pushing hours and days alone with no progress on a task is selfish, as it detracts from your team's goals and burns money for no justifiable reason for the stakeholders.

## Present your work as early as possible

I have spent all my professional career in startups or startup-like environments - fast-paced and flat organizations where the top priority is to deliver value in very short cycles. One of the more recent rituals we stumbled upon is what we call "local demos." It is essentially a screen share session between two or more developers where the feature's author presents the work on their local development environment before opening a PR request. This ritual has proven to be a great way of catching code and requirement issues even before they are in the form of a PR request. Viewing the code and the result alongside the author gives the future PR reviewer a better idea of what to look at when the PR is ready to be merged. We even do these sessions with clients and QAs, allowing them to peek at the progress. Instead of a bug going through a PR, QA testing, or potentially a staging environment, it's detected right there and then. So far, many bugs have been eliminated in the earliest stage possible, enabling us to produce a better product in shorter cycles.

## Don't write code for the sake of writing code; it's always about the client

The internet somewhat idolizes this hardcore hacker dev persona - always writing the cleanest code, solving problems with possibly the most efficient algorithms, sunglasses in a dark room, Vim? As romantic as it sounds, the expectation of being this brilliant engineer working on exciting and challenging problems all the time is unrealistic. In a commercial setup, what matters is building a product that people want and use, given deadline and budget limitations. It is a cherishable trait to put yourself in the stakeholders' shoes and have their concerns in mind when doing the actual engineering instead of solely focusing on solving problems in the most elegant way possible. More often than not, a working solution now is better than the best solution tomorrow. Of course, this is no excuse to put in the minimal amount of work and produce the "minimum non-sucking product." The best engineers create robust, sustainable, and scalable solutions given all the constraints.

## Production is nothing like development

It took three months for me to publish my first app. I had put so much energy and thought into every detail; it looked great and worked perfectly on my emulator and phone. I was so excited to share it with the world. Then I onboarded the first users. A few days in, complaints were raining - "It's too slow!", "It's crashing," "It sucks!" My phone was ringing every day with users and their bug reports. This period gets to you when you have never published anything to production, and it is easy to feel inadequate as a developer. The truth is, nothing prepares a developer early in their career for the utter chaos of an actual mass of people using your product. It's an entirely different set of problems than the programming itself. Deployment, availability, backups, scaling, and performance are problems that reveal themselves only when you hit production usage. In big companies, those roles are separate, so not all programmers are concerned with deployment & reliability. But I would argue that working on software from inception to end user has given me good insights I still use daily. Plus, it's always fun to watch your baby fly (or flop!).

The good thing is that these lessons never end; they change, they become obsolete, or plain wrong. The field of software engineering is a gift that keeps on giving. Every day, millions of people are hard at work imagining the world's future using code, and I sure am looking forward to what we will build in the next six years and the lessons that come along with it.

A compilation of thoughts and insights from my experience as a software developer over the past six years.

From the front lines