It’s been a while since I wrote the previous 

, and a lot of you probably were wondering what would be the next steps after the initial interview.

For the last few years, we grew significantly and the process changed a few times over that time. But the core approach and principles didn’t.

Our objective is to find a so-called 10x engineer, a person capable of doing things in order of magnitude faster than an average engineer would do. And, of course, without compromises on the quality of deliverables.

Hiring process became much more challenging, and competition grew dramatically. We can’t afford any longer to keep candidates in the loop for weeks, sometimes even for days. At the same time we don’t want to hire the wrong person, and don’t want to waste pointlessly precious time of our software engineers.

Currently our process consists of the following steps:

1. Vetting resumes and profiles on job sites and LinkedIn.

Which is performed by our Recruiters. They make sure the candidate possesses a great level of verbal and written English, fits into our corporate values and checks our pre-initial technical questions  — “brick problem”,

algorithmic complexity knowledge, quadratic equations, etc. Usually those calls last 10–20 minutes and we can narrow down candidates significantly and make sure that those who will speak with our software engineers won't get stuck on trivial questions and make an interview uncomfortable and messy for both parties.

This interview we’re skipping for Mid/Senior positions and performing mostly for Junior ones. You can read about it in my previous 

Executed by one or two of our middle plus level software engineers where they ask technical questions - both specific to the technology we’re interviewing for as well as the ones that show the candidate logical and algorithmic thinking.

Usually it requires 4-8 hours to finish. For example one of test assignments for the middle plus C# position was about implementing REST API service with ElasticSearch backend.

In some cases the client wants to run his own process over the candidate. Still we don’t want to show the client a weak candidate, therefore our process is still relevant and mandatory.

Overall the hiring funnel looks as shown below.

As you can see just 1 out of 26 candidates selected on the vetting resumes’ stage passes the entire process.

As a result this process allows us to deliver complex and challenging projects to our clients with a top bar of quality and possibility scale continuously and quite swiftly.

In the next articles we’re planning to dive even deeper into the hiring process. We'll also discuss an interesting case when the Agency that provides tech courses tried to hijack our interview process. Please subscribe to not miss those exciting details.

How we hire a Rockstar Developer — Part 2

Our objective is to find a so-called 10x engineer. And, of course, without compromises on the quality of deliverables.

 (the creator of GoAWK) for being really patient and helpful throughout my contribution process, providing thorough and insightful code reviews.



 is a measure that tells how much of your source code is executed by tests.

 is a task/command runner that I’m developing. It’s sort of similar to the well-known make tool, but without most of its idiosyncrasies (and with a couple of unique features!).

It may sound surprising, but I wrote it in AWK. I won’t lie: writing it in AWK started more out of curiosity than out of real need. To me, limits encourage creativity. Few people know nowadays that AWK is a full-fledged programming language, though really minimalistic.

Makesure started more like an experiment to see how far writing a tool in AWK can go. It appears to be pretty far. I don’t think this is an exception, but rather a consistent pattern, due to the true genius of the AWK authors.

To take an example from another project written in AWK:

!
To bytecode; I wanted to use the awk-based compiler as the initial bootstrap stage for a self-hosted compiler. Disturbingly, it worked fine. Disappointingly, it was actually faster than the self-hosted version. But it’s so not the right language to write compilers in. Not having actual datastructures was a problem. But it was a surprisingly clean 1.5kloc or so. awk’s still my go-to language for tiny, one-shot programming and text processing tasks.

The other idea behind choosing AWK for Makesure is the ease of parsing. For example, when parsing this Makesure syntax:

If you know a bit of AWK, you understand that this syntax is fairly easy to parse with it. AWK already does word-splitting for you, so all you need is this:

Essentially, using a limited tool for the job (AWK) motivates you to comply with the 

 principle, which I’m a big proponent of. You don’t invent fancy syntax, but rather rely on syntax that can be parsed in a straight-forward way.

Time passed, and the source code for Makesure grew to a 

, but I was not sure how good the coverage was, whether all critical scenarios were tested or not.

Thus the need to test coverage 

. My research revealed that no AWK implementation had a code coverage facility. And so I decided to add one to an AWK implementation. The most suitable for such an addition appeared to be GoAWK.

Of course, some of my other motivations were practicing my Go and AWK programming skills.



Essentially, to collect code coverage statistics, we use source code instrumentation. That is, each line of code is annotated with a piece of tracking code (details below). Thus, when the instrumented program runs, the tracking code is triggered each time a code line is hit. At program completion, all collected coverage profile data is written to a file. This file is then used to create a human-friendly coverage report like the one below:

How code coverage for AWK differs from mainstream languages

 tool. It provides a really nice and simple way to test a CLI tool as a black box.

The tests in 

 and simply compares the actual output with the expected output using a normal diff. If there is a difference, the test fails and the diff is displayed to the user.

In essence, such tests are end-to-end tests that are on the top of the well-known 

. This is very good, since this style of testing is equivalent to how a 

user uses the tool, giving a much higher chance of catching 

bugs.

Using this approach, I created a comprehensive test suite for Makesure, with a typical test file 

.

The usual approach to testing (like in Go, Python or Java) is to create a set of tests (usually in multiple source files), then to use a “test runner” to run all them at once. And there lies a subtle but important difference from the approach described above.

In the case of a test runner, you run it once for all tests, so it can form the overall coverage profile when all the tests are completed.

In the case of 

 underneath) is called many times with different arguments. Which means we want a way to assemble the final coverage profile incrementally.

This poses additional implementation challenges. We need the ability for separate runs of an AWK program to be able to append to a single coverage profile. This implies that the internal format of this file needs to be “appendable”, but also requires that the reporting facility that consumes the file understands this “appendability”.



A couple of years ago I came across the article 

. The article was pretty insightful for me, as it gave enough technical explanation, and described typical challenges when implementing code coverage for a particular programming language.

The author based his implementation on the 

 coverage tool, initially targeted to JavaScript. But the author managed to generate coverage profiles for another language (Solidity) in Istanbul format, allowing him to reuse the reporting facility of Istanbul for free.

My plan was to use a similar approach. But my research showed that the Istanbul 

 was not append-friendly.

The other direction of my thought was defined by the classic book 

 by Alfred V. Aho, Brian W. Kernighan, Peter J. Weinberger (the A, W, K of AWK). As an aside, this book is an absolute pleasure to read and amazingly relevant today, despite being published in 1988.

On pages 167-169 of this book is section “7.2 Profiling”. It describes a very simple approach to how one can implement the profiling of a program with just two AWK scripts: 

 (they’re just a few lines of code each!).



 does (admittedly naive) transformation of the input source by inserting a statement of the form 

 clause that outputs the collected statement counts in 

 attaches the statement counts from this file to the original program and displays the counts together with the original source code.

I was completely fascinated by the simplicity and clarity of this approach!

Despite the fact that this approach is far from perfect and practical, I really considered using an improved version of this approach. However, it was clear that to make it more precise and robust, I’d need to transform the AWK program’s AST (abstract syntax tree), not just perform a naive source code modification.



While working closely with AWK for my project, one day I came across GoAWK. Out of curiosity I tried running Makesure with it. This revealed some bugs in GoAWK, which I reported, and they were fixed promptly by Ben Hoyt, the creator. So eventually GoAWK passed the test suite of Makesure.

At that time I started getting interested in learning the Go programming language. So I was happy to contribute and fix some minor bugs I encountered. Overall, I really liked the GoAWK project and especially the author behind it. I can’t help but recommend 

 – very well written and interesting.

So I thought that whatever implementation approach I choose, I would like to use GoAWK as a base. Since GoAWK was written in Go, I decided to take a look at the coverage support in Go itself. This was when I came across Go’s 

. I was immediately convinced!

The functionality was not as advanced as Istanbul’s, but still enough. The implementation seemed to be relatively simple. But most importantly, their coverage profile format appears to be designed with appendability in mind! (Though, to my knowledge, this feature is not directly used by the Go tools themselves).

So I decided we should add code coverage functionality to GoAWK, but use Go’s coverage profile format, so that we could reuse the Go machinery (

To better understand what follows, it may be beneficial for the reader to first read 



GoAWK uses pretty standard patterns in programming language implementation and execution strategy:

 1. Firstly, the input AWK source (as a string) is processed by the 

 2. Then the list of tokens serves as input for the 

, the output of which is an AST (abstract syntax tree).

 that was initially part of the parser. It analyzes the AST and annotates it with some additional data, like information about variable types.

, producing a list of opcodes and their arguments – the GoAWK bytecode.

 4. Finally, the bytecode serves as input to the 

, which has a Virtual Machine inside. It runs the opcodes instruction by instruction to execute the program.

Now I needed to understand how to fit the code coverage functionality into this scheme.

As I explained earlier, we need to instrument the source code for coverage tracking. It’s much easier to explain using an example:

Given the following AWK source:

the instrumented code will look like this:

It was obvious that this tracking code insertion should take place at the AST level. So I imagined we’d need to add an additional step between 2 and 3: it would take AST as input, pass it through a “coverage annotator” (yet to be added), and produce the transformed AST.

But it wasn’t so simple in practice! The main problem was the tight connection between the parser and resolver. In fact, both of them happened in the same pass, so it was impossible to run them separately.

Let me explain why this is important. If I just changed the AST by adding the required nodes for the 

 statements, those new nodes would lack some tiny (but important) pieces of information filled in by the resolver. So somehow I needed to run the updated AST through the resolution step once again. But this was technically impossible, because the resolver (being part of the parser) could only consume what the parser consumes – that is, the list of tokens.

So, I thought, why not just render the modified AST back to AWK source and then start the whole process from step 1. Luckily, GoAWK already had a 

 implementation for all AST nodes, so it could render AST back to AWK source. Unluckily, this AWK source 

was not guaranteed to be correct in all cases

, because its purpose was to output the parsed AST for debugging (the 

 flag).

This is when I added the first dirty hack: I patched the instrumented AST (more precisely, the inserted pieces) as if this was done by Resolver itself.

The second hack I used was even nastier. When I inserted coverage instrumentation like so:

I also internally store the information that describes it, such as the filename and source lines being covered. This information is captured in the 

So internally we have the following (Go pseudocode):

Storing this data is needed for building the resulting coverage profile (in the format used by 

Each line above describes collected coverage for some block of code, and has the following format

Now, remember that you can run AWK with multiple source files, like so:

But GoAWK, in step 1 above, just joined all source files into a single string and used that as input to the lexer.

This means that by the time we’ve got the AST after step 2, there is no way to tell which AST node came from what input file. Thus, we aren’t able to fill in the 

 during instrumentation.

So to pass the required 

 information to the AST, it needs to wire it through both the lexer and parser, I thought. For this I introduced a 

 that I inserted at the start of each file. Thus, when sources were joined, this token represented files boundaries, which meant that at parse time I was able to track the filenames and local positions in each file.



Although the approach worked well in practice, it was clear that it was ugly, and that it had zero chance to be merged as is. Ben came up with a 

 about structural things he’d like to see addressed before merging this in.

There was no other way than to undertake a couple of serious refactorings before we attempting to merge my code coverage support.

Frankly, I was not upset at all, but rather excited! Firstly, I got a chance to do even more useful work for a project I liked. And I was glad to keep sharpening my Go fu further.

The biggest thing to start with was decoupling the parse and resolve steps. This was a bit scary to touch. Even Ben described this part of code as follows:

In fact, the resolver was one of the harder pieces of code I’ve written for a while. It’s the one piece of the GoAWK source I’m not particularly happy with. It works, but it’s messy, and I’m still not sure I’ve covered all the edge cases.

But I think I understood how it worked overall, and how I could do the refactoring. Reading Ben’s tech writing was a big help.

I needed a way to traverse (and update) the AST for the resolving step after parsing.

For this 

. Once the visitor functionality was in place, the AST traversal needed for resolving 

 served the purpose of resolving global positions in the joined source code back to local positions in the input source files. This was needed to get rid of hack #2 mentioned above.

When both the refactorings were reviewed and merged to master I was able to submit my 

final clean implementation of code coverage

 on top.

Overall, I highly recommend this approach to big contributions. You should not try to fit all your changes into a single pull request. Each PR should be highly cohesive, that is, solve only a single problem. That is much easier for the project owner to review and accept such PRs. Also, such PRs will be valuable on their own, even if not all of them manage to reach the master branch. As John Ousterhout says, 

problem decomposition is the most important idea in all of computer science

Running GoAWK coverage on Makesure revealed 

. This helped to find a bug (which has already been fixed).



As I’ve mentioned, Go’s approach to code coverage is not very advanced. It implements 

coverage (the same applies to GoAWK coverage). For simplicity, 

. Other coverage tools, like Istanbul can provide more detailed coverage, like coverage for 

.

To illustrate that last point, let’s imagine this code:

You can have it all green, but still something is not covered: the implicit “else” branch is not covered. In other words, we want to make sure both true and false variants for 

 are covered.

It would be really nice to improve this for GoAWK coverage and maybe even for Go itself, but I’ll leave that for future work!

The Go Blog: “The cover story” by Rob Pike

 – the book by the AWK creators, a must read!

Code Coverage for GoAWK

My research revealed that no AWK implementation had a code coverage facility. The most suitable for such an addition appeared to be GoAWK.

Let’s consider the most popular options for adopting blockchain for retail companies. All the possibilities suggest that we can build the system from scratch or make a bridge between the existing solution and a new one for the first time. Moreover, it allows for reducing costs and testing hypotheses safely.

Blockchain is the ideal tool to build something more significant than the outdated encouraging methods in other retail companies.

We can build a genuinely gamified micro-economy among the company workers.

The first step is to create your crypto assets that can bring value by themselves,

Further, the manager can set up the rules that control the rewarding system, for instance: employee rating - where each employee can reward another with a special NFT, monthly sales - when an employee overcomes such a limit, they get a crypto token for the reward, consumer rating - when a consumer can not only say thank you but gives a bonus to the employee via two clicks on the mobile app.

An internal point system gathers all the information and allows one to understand the current situation and foresee future employee behavior.

Employees have complete control over their tokens, so they can buy goods in the internal store, trade tokens for money, or transfer them to each other as a reward for performing particular tasks.

Brand loyalty has always been one of the keys to success for retail businesses, especially nowadays after covid.

There are a few ways to improve your loyalty program:

Charge crypto tokens for buying goods in the store and allow you to pay with these tokens in your store or affiliate networks.

Create an NFT collection associated with your loyalty program. For example, it could be 10,000 unique cartoon pictures with different designs that the clients can sell in the future.

The retail application can convert monthly cashback rewards to popular crypto such as BTC, ETH, etc.

Consumers can donate their tokens to some charity organization from the affiliate networks.

The last but not the least option is creating the cash app with a debit cash card. Each time the users pay with the app, they receive some percent cashback paid out in internal tokens or popular cryptos like BTC and stablecoins.

Tokenization is an updated version of traditional fractionalized property ownership in the real estate business. We can adapt this approach to the retail industry and attract more investment to open a new store or to expand an existing one.

The idea is simple - you can just convert your store into digital tokens; everyone who buys those tokens becomes an investor in your property and own a portion of the equity. Furthermore, the system can obligate each investor to pass through the KYC (Know Your Customer) process for authorization and ask additional questions before allowing them to buy tokens.

In their turn, investors get passive income via affordable investment.

Control the whole supply chain to prevent counterfeit goods and fraud; also, it builds transparency and allows end users to know where their order is and your employee to organize the proper inventory management.

You can allow the use of crypto as a payment method in your store.

There is also a way to provide direct person-to-merchant transactions and allow clients to receive distributed loans within your society.

Crypto assets are smartcontracts-controlled objects that exist only in a blockchain network and can prove ownership and provide transfer functionality. If the object initially wasn’t a digital asset, it could become one. For example, you can convert a photo into an NFT or create tokens representing the property's ownership.

There are two popular types of digital assets:

Cryptocurrency - fungible token, like a reward point

NFT - unique and not mutually interchangeable cryptographic token like an art object or branded T-shirt for a client’s metaverse hero or another personal gift.

One of the obstacles on the way to absorbing blockchain is necessary to install and set up crypto-wallets, understand how blockchain works, etc.

The mobile application eliminates this issue because the app works like a wallet. Different options depend on the market: check employee rewards and transactions, make a gift, chat with each other, buy, send and receive crypto assets. In addition, the app can transform the phone into a physical loyalty card through integration with NFC.

The control center is a web application that provides all necessary functions to set up, observe and control the system.

There could be a variety of subsystems such as:

Program manager: The primary tool for creating and adjusting the different programs such as the Loyalty program, employee recognition program, etc.

Block explorer: an engine that enables everybody to retrieve real-time and historical data about transactions, addresses, and more.

Token builder: service for deploying and controlling tokens, including minting, burning, etc. Here admin can create new badges, for instance.

Analytics: an engine that allows monitoring of all the system’s metrics via charts on the main dashboard. You can inspect in real-time how your consumers, partners, or employees are reacting to different incentives and a variety of options for report generation.

Alarms: triggers that inform responsible persons about some unusual activity etc.

Blockchain in Retail: Use Cases

Blockchain technology allows retail companies to incentivize customers, employees, and partners.

The real estate industry could have three primary benefits from tokenizing real estate assets, such as:

Reduce associated costs and processing time

Look at these huge reasons to implement blockchain more closely in your real estate business.



Real estate transactions involve multiple people in different roles, lengthening the process. Blockchain technology can automate various processes by creating smart mortgage contracts that are approved as soon as all documents and requirements are fulfilled, rather than making the clients wait months for approval and going back and forth with brokers, banks, lawyers, etc.





The ownership acts are usually made of paper, which we all know can be damaged, lost, or subject to fraud. The legal process of transferring ownership can be long and complicated and require a lot of money. Blockchain technology can be a great solution, as all records are tracked on an immutable ledger that can act as a trusted and reliable source of information for both parties to a deal.





The allure of investing in non-traditional assets, such as tokenized ownership, is that could reduce the entry threshold for new investors by allowing people to release a custom percentage of their home's equity in the form of tokens that could be traded on the market. This way, we increase liquidity and give people different ways to benefit from their property or investments.

Blockchain in Real Estate: Top 3 benefits

The real estate industry could have three primary benefits from tokenizing real estate assets.

Before writing a single line of code, we must understand who our end-users are. For example, a young single mom can behave differently than lone older adults or large families. So just define the list of the most popular groups of consumers or employees whatsoever and create at least one persona for each of them.

There could be different characteristics. Just make this list not so big:

Understanding these things will help create the best product for all these people and increase the chances of a successful product launch and absorption.


Before spending money on the development, we can run the discovery phase and determine which minimum functionality must be implemented to validate the original idea.

We can define minimal deliverables and develop the proof of concept just for testing purposes with the group of potential end-users. There is always a place to pivot and change the original idea drastically.

After the previous phase, we can go further and build a Minimum Viable Product that can be delivered to the customers.

How to start gaining from blockchain adoption

Here we describe the three first steps to help you save time and money on blockchain adoption.

How we hire a Rockstar Developer — Part 2

1. Vetting resumes and profiles on job sites and LinkedIn.

2. Screening call.

3. Initial Interview.

4. Technical Interview.

5. Test assignment.

6. Client Interviews.

Other blogs