Ivan Shamatov: how to write money
Hello!
We are preparing for the upcoming RubyRussia 2019 conference (have you already marked September 28 in the calendar?) And are talking with our speakers about life, the community and programming. In today's interview, Felix Yasnopolsky from Evrone talks to Ivan Shamatov: the leader of the Saint P Ruby Community ( here you can join the cozy community chat on Telegram) and VP of engineering at Cybergizer.
What will your speech be about at the upcoming conference?
I want to show that money in programming is easy! With the help of money, we express some value of a product or service. In general, they can be described as a tuple of dimension 2, consisting of a digital value (for example, 100) and a character value (for example, USD, $). In the case of operations with money with the same symbols, the mathematical apparatus is relatively simple, but even here you can find pitfalls. What can we say about the scenario of converting money from one currency to another. Here the ideal mathematical world collapses and the business accounting begins. I will show how to understand some of the scenarios and what errors can be on examples of practices from fintech projects.
Why did you choose this topic?
I participated in the development of a payment system for the subway, Aeroexpress, a system for paying utility bills for some states in the USA, and many others. The very first script that I wrote for money is a php script to pay for Internet through terminals in Pushkin. The next time I came across the topic of money when I worked at Cryptopay - there were also transfers and transactions there. Then I went to work at Toptal, where I was part of a billing team. Getting ready for the conference, I thought that many people could talk about the features of Ruby, but few people understand how to write money and how to do it right. And this is a topic that we often encounter in a variety of projects.
What technologies besides Ruby do you like?
I really like JavaScript. Enjoy the ease of writing on ES6. I like the paradigms that come to Ruby from other languages: in this case, it becomes not necessary for us to use these very other languages. You can open a concurrent gem and see a bunch of tools from Go, Clojure, Java and JavaScript. I like that in different languages it is necessary to use different ways of thinking. There are people who go from Ruby to Go to maintain the principles of Ruby thinking. Or come to Ruby with principles from PHP. This does not work in programming: each language has its own approach, its own workflow, its own mindset. You need to understand how to write programs in the framework of a particular technology.
I am very interested in mobile development: the same patterns, the same MVC, but everything works in a completely different way. It was very interesting to study React and Redux - a great repo for a typical rail :)
Tell us about your biggest failures and reasons for pride.
I can be proud of the projects in which I participated, to which I had a hand. For example, a project that makes it possible to pay by pay with an Aeroexpress card in Moscow. The same system is used in the metro of Kazan. I wrote a client for turnstiles on JRuby, and the Rails backend, which services these transport transactions, works with various APIs. It was a very interesting project, with only three developers participating in it.
Fakapov not ashamed, even when they happen. A person has the right to make a mistake. Mistaken - and you don’t do that anymore.
One of your activities is mentoring. Why are you doing this?
I myself always had mentors who suggested what and how to do. These are guys from different chats, people with whom I spoke at conferences and meetings. When I reached a certain level, I began to mentor both offline and online. Now I deal with people who came to us from Rubizz 's. This is one of my main projects for today, an intensive practical study of Ruby for beginners. Children are given maximum freedom of action and the right to make mistakes. And only after the cones are full, does the mentor explain why this was a mistake and why you should not do this. I believe that this is the right approach: some things cannot be understood until you collect this rake yourself. If you have never used callbacks incorrectly, you will not understand what could be the problem with them. And why do many people in the community hate callbacks.
I heard that you tried to get into the Toptal team six or seven times. It's true?
Yes, it’s true, I talked about this many times. Toptal has pursued an aggressive, or rather, proactive, hiring policy since the start of the company. I was invited for interviews about once a year. After repeated unsuccessful attempts, I decided that I would not try anymore. But my friend, with whom we once started our journey in Ruby, got a job there and suggested that I try again. And this time I was able to go through all the stages of the interview. There is a big technical test at the entrance, then an interview, then one more, and another ... And now I think that conducting 5-6 stages of interviews is a very cool practice. Only in this way can you understand who is in front of you, whether you want to work with this person, whether he will fit into the team. And I understand why they didn’t take me for the first time, I really didn’t pull then.
How, in your opinion, should an ideal job interview and hiring process be arranged?
When I helped with the selection of people for the previous team, Cryptopay, we had two stages. As a test task, we gave a piece of code for refactoring. Based on this piece of code, we did a preliminary assessment of the candidate. Then we conducted an interview in the format of live coding in order to understand whether this person is suitable for us. Live coding allows you to understand how a person thinks. You can evaluate not only what is written, but also how the developer uses the operating system, IDE, does the hotkey know how deeply he understands certain topics, what approaches he uses, what questions he asks his colleagues in the process. This approach provides much more information about a person than a test or interview about algorithms.
But I believe that this is not enough. Now, at Cybergizer, I often hire people I’ve already worked with. There are people with whom we did not work, but together they wrote some kind of open source. Such a joint activity allows you to see how a person writes code. And you also understand how your workflow coincides, how mentally close you are.
I do not consider myself an expert on hiring, my approach also misfires. One of my recent mistakes: I did not want to take the person after the livecoding session for an interview, he did not impress me. But other team members voted for him, and we began to work together. And in collaboration, I realized that this is a high-class specialist. There was an absolutely opposite case when I was a man with all my hands, and as a developer, he was nothing. After these two cases, I am not ready to judge the correctness of any particular hiring method. Maybe lucky, maybe not lucky. To paraphrase a famous joke:
- How do you manage to hire such good developers?
- This is all the experience of hiring good developers!
- And how to get such an experience?
- We need to hire different developers.
It seems strange to me that so many are interested in how to attract good specialists. But few people are interested in how to become a company in which good specialists will want to work. Or maybe you should think about it first of all?
You are organizing meetings and meetings of Saint P Rubyconf in St. Petersburg. Why and why are you doing this?
This is part of the Ruby culture - community contributor. Someone embeds code, writes opensource. I contribute to what I get. Many people think that in order to make any contribution, you need to be seven spans in the forehead. But this is not so! Almost 10 years ago, when I was at the very beginning of my journey to Ruby, I with the team of guys translated into Russian and voiced RailsCasts. So everyone can be useful to the whole community: it doesn’t matter whether you update the dock in gem, write an article or organize a mitap.
See you at RubyRussia September 28th!
Watch the program and join here , the next price increase is expected after September 15.
Thanks to the companies that support us:
Organizer - Evrone
General Partner - Toptal
Gold Partner - Gett
Silver Partners - JetBrains , Bookmate and Cashwagon
Bronze Partner - InSales
We are preparing for the upcoming RubyRussia 2019 conference (have you already marked September 28 in the calendar?) And are talking with our speakers about life, the community and programming. In today's interview, Felix Yasnopolsky from Evrone talks to Ivan Shamatov: the leader of the Saint P Ruby Community ( here you can join the cozy community chat on Telegram) and VP of engineering at Cybergizer.
What will your speech be about at the upcoming conference?
I want to show that money in programming is easy! With the help of money, we express some value of a product or service. In general, they can be described as a tuple of dimension 2, consisting of a digital value (for example, 100) and a character value (for example, USD, $). In the case of operations with money with the same symbols, the mathematical apparatus is relatively simple, but even here you can find pitfalls. What can we say about the scenario of converting money from one currency to another. Here the ideal mathematical world collapses and the business accounting begins. I will show how to understand some of the scenarios and what errors can be on examples of practices from fintech projects.
Why did you choose this topic?
I participated in the development of a payment system for the subway, Aeroexpress, a system for paying utility bills for some states in the USA, and many others. The very first script that I wrote for money is a php script to pay for Internet through terminals in Pushkin. The next time I came across the topic of money when I worked at Cryptopay - there were also transfers and transactions there. Then I went to work at Toptal, where I was part of a billing team. Getting ready for the conference, I thought that many people could talk about the features of Ruby, but few people understand how to write money and how to do it right. And this is a topic that we often encounter in a variety of projects.
What technologies besides Ruby do you like?
I really like JavaScript. Enjoy the ease of writing on ES6. I like the paradigms that come to Ruby from other languages: in this case, it becomes not necessary for us to use these very other languages. You can open a concurrent gem and see a bunch of tools from Go, Clojure, Java and JavaScript. I like that in different languages it is necessary to use different ways of thinking. There are people who go from Ruby to Go to maintain the principles of Ruby thinking. Or come to Ruby with principles from PHP. This does not work in programming: each language has its own approach, its own workflow, its own mindset. You need to understand how to write programs in the framework of a particular technology.
I am very interested in mobile development: the same patterns, the same MVC, but everything works in a completely different way. It was very interesting to study React and Redux - a great repo for a typical rail :)
Tell us about your biggest failures and reasons for pride.
I can be proud of the projects in which I participated, to which I had a hand. For example, a project that makes it possible to pay by pay with an Aeroexpress card in Moscow. The same system is used in the metro of Kazan. I wrote a client for turnstiles on JRuby, and the Rails backend, which services these transport transactions, works with various APIs. It was a very interesting project, with only three developers participating in it.
Fakapov not ashamed, even when they happen. A person has the right to make a mistake. Mistaken - and you don’t do that anymore.
One of your activities is mentoring. Why are you doing this?
I myself always had mentors who suggested what and how to do. These are guys from different chats, people with whom I spoke at conferences and meetings. When I reached a certain level, I began to mentor both offline and online. Now I deal with people who came to us from Rubizz 's. This is one of my main projects for today, an intensive practical study of Ruby for beginners. Children are given maximum freedom of action and the right to make mistakes. And only after the cones are full, does the mentor explain why this was a mistake and why you should not do this. I believe that this is the right approach: some things cannot be understood until you collect this rake yourself. If you have never used callbacks incorrectly, you will not understand what could be the problem with them. And why do many people in the community hate callbacks.
I heard that you tried to get into the Toptal team six or seven times. It's true?
Yes, it’s true, I talked about this many times. Toptal has pursued an aggressive, or rather, proactive, hiring policy since the start of the company. I was invited for interviews about once a year. After repeated unsuccessful attempts, I decided that I would not try anymore. But my friend, with whom we once started our journey in Ruby, got a job there and suggested that I try again. And this time I was able to go through all the stages of the interview. There is a big technical test at the entrance, then an interview, then one more, and another ... And now I think that conducting 5-6 stages of interviews is a very cool practice. Only in this way can you understand who is in front of you, whether you want to work with this person, whether he will fit into the team. And I understand why they didn’t take me for the first time, I really didn’t pull then.
How, in your opinion, should an ideal job interview and hiring process be arranged?
When I helped with the selection of people for the previous team, Cryptopay, we had two stages. As a test task, we gave a piece of code for refactoring. Based on this piece of code, we did a preliminary assessment of the candidate. Then we conducted an interview in the format of live coding in order to understand whether this person is suitable for us. Live coding allows you to understand how a person thinks. You can evaluate not only what is written, but also how the developer uses the operating system, IDE, does the hotkey know how deeply he understands certain topics, what approaches he uses, what questions he asks his colleagues in the process. This approach provides much more information about a person than a test or interview about algorithms.
But I believe that this is not enough. Now, at Cybergizer, I often hire people I’ve already worked with. There are people with whom we did not work, but together they wrote some kind of open source. Such a joint activity allows you to see how a person writes code. And you also understand how your workflow coincides, how mentally close you are.
I do not consider myself an expert on hiring, my approach also misfires. One of my recent mistakes: I did not want to take the person after the livecoding session for an interview, he did not impress me. But other team members voted for him, and we began to work together. And in collaboration, I realized that this is a high-class specialist. There was an absolutely opposite case when I was a man with all my hands, and as a developer, he was nothing. After these two cases, I am not ready to judge the correctness of any particular hiring method. Maybe lucky, maybe not lucky. To paraphrase a famous joke:
- How do you manage to hire such good developers?
- This is all the experience of hiring good developers!
- And how to get such an experience?
- We need to hire different developers.
It seems strange to me that so many are interested in how to attract good specialists. But few people are interested in how to become a company in which good specialists will want to work. Or maybe you should think about it first of all?
You are organizing meetings and meetings of Saint P Rubyconf in St. Petersburg. Why and why are you doing this?
This is part of the Ruby culture - community contributor. Someone embeds code, writes opensource. I contribute to what I get. Many people think that in order to make any contribution, you need to be seven spans in the forehead. But this is not so! Almost 10 years ago, when I was at the very beginning of my journey to Ruby, I with the team of guys translated into Russian and voiced RailsCasts. So everyone can be useful to the whole community: it doesn’t matter whether you update the dock in gem, write an article or organize a mitap.
See you at RubyRussia September 28th!
Watch the program and join here , the next price increase is expected after September 15.
Thanks to the companies that support us:
Organizer - Evrone
General Partner - Toptal
Gold Partner - Gett
Silver Partners - JetBrains , Bookmate and Cashwagon
Bronze Partner - InSales
All Articles