clutch-2022

OpenGraph - lexis.solutions

Bilyal Mestanov

Interview

Office

Milush-photo

Meta description Lexis Solutions

Digital tools

Radoslav

fire emoji

Bug illustration

Emil Kirilov

Deyan Denchev - new2

Milush mentoring Ivan

SERP example - largest volcano

Clutch Top Developers

SERP example - how to roast a potato

Mira

Beach Photo

Lexis Solutions-Team

CTO & Co-Founder

Milush Karadimov

Software Developer

Radoslav Kosev

QA Engineer

Deyan Denchev

CEO & Co-Founder

Web Developer

Mira Ereeva

Growth Manager

## 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)


Join the Lexis Solutions team on a trip to Thassos, Greece, for a look at the people and shared experiences behind our software projects.

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 named Lexis Solutions a top development company in Bulgaria for 2022. Read about the recognition and the software team behind it.

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!


Prepare for software developer interviews with practical dos and don’ts from Lexis Solutions, covering preparation and how to present your skills.

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]


Explore the benefits and drawbacks of digital tools, with a perspective from Lexis Solutions on how they influence everyday work.

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

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 mess 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.

10 Lessons I Learned in 6 Years of Software Engineering

Good old (and new) friends. A lot of blue outfits. Some cupcake challenges. And one fantastic rooftop. That's how we would describe the 4th of August when Lexis Solutions marked its 5th birthday. 

Lexis Solutions started with four enthusiastic developers - its founders - Bilyal, Deyan, Emil, and Milush, who met at a university competition and embarked on a new adventure - Lexis Solutions. Five years later, 14 people are involved in the life of Lexis' family. It recently expanded with our manager of growth - Mira, and intern - Oleksandr.

All of the mentioned and the rest of the Lexis team - Antoniya, Dilyan, Radoslav, Stefan, Nikola, Martin, and Victor gathered together with some good old friends from the Bulgarian IT world at the Barter Community Hub to celebrate the company's 5th birthday.  Unfortunately, Ivan missed the party, but was definitely missed.

![Lexis Solutions-Team 2](//images.ctfassets.net/5gydaotbo8jm/7yJGZ6nMf843pFngmgp2rs/74eaa56020fa71b7e820e7d6c5c28ad3/Lexis_Solutions-185.JPG)

Our CEO Deyan gave a speech and presented the company and its development. 

![Deyan giving a speech](//images.ctfassets.net/5gydaotbo8jm/5i6fAFCyBqWQW5XGsGjZFi/d43d2460d3db8354a78e1476df941aa3/Lexis_Solutions-209.JPG)

To honor our celebration, the guests followed a special dress code - to wear the Lexis Solutions' color - blue. 

![Milush and a blue guest](//images.ctfassets.net/5gydaotbo8jm/6qgjCncHtKgIfBYoKLjBIY/8821a4c9a3b117da9e8d5732009625bf/Lexis_Solutions-275.JPG)
![Guests1](//images.ctfassets.net/5gydaotbo8jm/4ksbawPJUFZFTLINiCskVz/147a43bb0ee0594d17504aa2f15de4aa/Lexis_Solutions-289-min.JPG)

There was a lot of delicious food, an open bar, excellent music from DJ Michael Veili, and some specially made Lexis Solutions cupcakes.

![Food](//images.ctfassets.net/5gydaotbo8jm/1lYyN4V6m6R7MeTYzHBQon/9739b1e7b9731de1f4c5c53afcb95f78/Lexis_Solutions-47.JPG)
![TOP DJ](//images.ctfassets.net/5gydaotbo8jm/1JcWCbpUrqzhLOHykWVIvB/fef8b3c029e9a475105293054524b883/Lexis_Solutions-94.JPG)
![Cupcakes](//images.ctfassets.net/5gydaotbo8jm/1k0Qqa42TtGNFamnPTPYjR/59c7d802e73c74daf945b1e529df688c/Lexis_Solutions-242-min.JPG)
![Cupcakes3](//images.ctfassets.net/5gydaotbo8jm/6lgMgKoFmBYpnsqzjxZkXo/18696aeb43be2d94c29a275c51eede3f/Lexis_Solutions-255.JPG)

The team's effort is crucial… especially when blowing up balloons.

![Ballons](//images.ctfassets.net/5gydaotbo8jm/4uioa4X7b0YXtVx2fMvFsq/af8af086ebd3b7951cd7892522efc992/Lexis_Solutions-1.JPG)
![Ballons2](//images.ctfassets.net/5gydaotbo8jm/1UFsKJG9cLiUsswsJBAvLP/d135f650f9a48e91575193d7e20f5d0f/Lexis_Solutions-5.JPG)

[Stoyan](https://www.facebook.com/St.Nedev), our skilled photographer, was always around the corner and captured all the important moments. He also made sure everyone had an Instagram-worth picture.

![Instagram1](//images.ctfassets.net/5gydaotbo8jm/73xRXcZzQxSQ9Quw0Uld26/c14c1c31ad4286aa2e2c6fed74eb0e9a/Lexis_Solutions-97.JPG)
![Instagram2](//images.ctfassets.net/5gydaotbo8jm/3M965LvBNE9drDHH1e4qbf/4c521094e164fb4dde2903fa5cd28c61/Lexis_Solutions-139.JPG)
![Instagram3](//images.ctfassets.net/5gydaotbo8jm/5M7XVE1cnv9JjsL6AfhbpZ/0305b2250ca25ad7b2657a2cdeebc86e/Lexis_Solutions-107.JPG)
![Instagram4](//images.ctfassets.net/5gydaotbo8jm/5qFlR9TzN7cuK3VXhyTFOo/973ca5244cddf48eb8885e67b3fca746/Lexis_Solutions-121.JPG)

Of course, Lexis Solutions' rooftop party wouldn't have been the same without its guests. We thank them for their smiles, good appetite, and sense of humor. 

![Guest](//images.ctfassets.net/5gydaotbo8jm/3V9kBh1t06TnbvxaexEQAA/ada2a87a56f813d58db99fa4fbe65919/Lexis_Solutions-55.JPG)
![Guest2](//images.ctfassets.net/5gydaotbo8jm/22HAcdBPupXQyc0OhFLeR1/ea2e7240a1a1e90a1e2a839bed3ff469/Lexis_Solutions-82.JPG)
![Guest3](//images.ctfassets.net/5gydaotbo8jm/6IxOHnU5SLWiq0ZOi5VHRr/03c624b9eba29873d86bab63d2549d31/Lexis_Solutions-124__1_.JPG)
![Guest5](//images.ctfassets.net/5gydaotbo8jm/4igi8z1eTlLZfmNdIacLDu/d0dfc345a2342ada53d77926177a43c0/Lexis_Solutions-122.JPG)
![Guest6](//images.ctfassets.net/5gydaotbo8jm/MKCoa8pb91qc3VCeYhOuM/9bd5bffa2e8558c5c5730461a89a4882/Lexis_Solutions-164.JPG)


Lexis Solutions celebrates five years with a rooftop party. Meet the team behind our software projects and share a milestone in the company’s story.

5 Years Lexis Solutions: A Rooftop Party

Over the years, software programming has changed, and as a result, testing, which is an essential aspect of software development, has changed as well.

It all began during the programming and debugging phases when detecting faults while debugging was regarded as testing. Testing was given its own identity in 1957 and was viewed as a distinct activity from the debugging process. Until the late 1970s, testing was regarded as a means of ensuring that software met the defined criteria. It was then expanded to discover the flaws and provide the software’s proper operation. In the 1980s, testing was also used to determine quality. It grew in prominence as a result and was handled as a well-defined and managed process inside the software development life cycle

For a better understanding of the software testing evolution, let us take a look at some of the crucial and defining periods separately. 

**1\. Early stages of programming and testing**

During this time, development and testing were viewed as separate tasks. When the software was finished, it was handed over to the testing team for review. Testers were not highly involved during the requirement analysis phase and had minimal interactions with business stakeholders. They were significantly dependent on knowledge passed down to them through documentation created during design and development or expertise gathered from code developers. The testing team’s testing methodologies were constrained due to a lack of understanding of the customers’ objectives and expectations. The testers would create a test plan based on their knowledge of the documentation and test the program on-the-fly. There were some limits, and the testing was not exhaustive.

**2\. Evolving to manual tеsting**

Various approaches, such as agile testing, exploratory testing, and others, emerged in the late 1990s. Manual testing was carried out using comprehensive test cases and test plans.

Exploratory testing allows people to test and break software uniquely by investigating it within the scope of testing charters.

The rapid and extensive expansion of the software development process necessitated increasingly comprehensive testing methods. Agile testing’s incremental and iterative methodology assisted in accomplishing this goal. The iterative testing method made it possible to automate repetitive tests.

**3\. The era of automatic testing**

With the turn of the millennium, a slew of new methodologies emerged, completely overhauling software testing. These methods completely changed the way people approached testing. At every stage of the SDLC, testing was now considered essential. Quality assurance and control have become more critical at every step.

Automation aided in the rapid and accurate execution of regression and sanity testing. Testing was elevated to a new level thanks to automation. The testers were further empowered to carry out their responsibilities with increased efficiency thanks to various automated testing frameworks.

Scaling up the testing process was also necessary during this period. Crowdsourcing and Cloud testing let the company manage product testing faster with less infrastructure and workforce investment.

**4\. Continuous testing era**

Customers wanted to see an intermediate functioning model of the eventual product when the business dynamics began to shift. As a result, there was an increase in demand for regular and medium software releases.

High connection and faster deployment and testing across different platforms were made possible by upgraded network infrastructure. This allowed for more frequent delivery, which resulted in more testing effort.
Continuous Integration and Continuous Deployment have become central concepts. Ongoing testing has also become more critical as a result of these developments.

Shorter delivery cycles have resulted from the rise of DevOps and CI/CD. Risk assessment in real-time has become increasingly important. At every level of the software development life cycle, risk assessment and management were required. Continuous testing aids in the direction of such risks by identifying and resolving issues before each software release.
The business stakeholders expected an interim release with short deadlines and no sacrifices on the eventual product’s quality. Continuous testing needs to improve its efficiency to keep up with these demands. That’s where artificial intelligence comes into play in the testing process.

**5\. The Age of Artificial Intelligence**

Simply put, Artificial Intelligence is a machine’s capacity to see, analyze, and learn to imitate human behavior.

AI algorithms are based on data analysis that predicts the future. This implies that AI testing is primarily reliant on data.

Many AI-powered testing solutions are now available to assist with unit testing, API testing, UI testing, and other tasks. Visual testing is a famous illustration of how AI may be used in testing.

**6\. Summary**

Within the last few years, the software sector has evolved dramatically. While it is difficult to forecast precisely what the next decade will bring, as the IT sector continuously evolves, a new variety of challenges will appear, providing a new set of issues for quality assurance professionals to solve.

While QA professionals are sometimes overlooked, their contributions to DevOps are becoming more widely recognized. Simultaneously, testing will become endemic throughout other aspects of the software lifecycle process, with rapidly emerging technologies bringing tests within reach of a more significant number of team members.

Explore how software testing evolved, the approaches used in development and what changing practices mean for QA engineers.

From the front lines