davit301

[davit301]

Transformational Leadership

Transformational leadership is when leader’s behavior influence followers and inspire them to perform beyond their perceived capabilities.

[davit301]

Are you ready for your next tech interview?

Do you remember your first tech interview? You prepared for a long time for that interview. You paid attention not only to refresh your skills, but also to your dress code etc. Finally, you successfully passed all interviews and got your first job. After spending several years and getting promoted, one day you woke up and understood that you wanted to achieve the next step in your career. And again, you started preparations for your next tech interview and in parallel searched for a good company where you can continue your growth.

As a professional, along with technical skills one learns to value company culture, which becomes one of the main criteria of choosing between job offers. As a matter of fact, interviews become not just a questionnaire directed one way from interviewers to candidates, but two-sided observations where the candidate gets to know the company culture.

An interview is the first hand experience a candidate has with a potential employer, which is maximally used from both sides to impact the other party. Initially, apart from technical growth and financial prosperity, company culture is one of the main factors that builds and shapes an employee. This is why at some level of career, financial offer is moved back from being a leading priority, and a candidate cannot be headhunted with just a big joining bonus and a paycheck. Moreover, it is vital for companies to stabilize and eliminate an unhealthy environment, which may result in high turnover. This is why mutual understanding of team fit needs to be observed and agreed on during interviews.

In this article I have listed some questions which can be asked by an interviewee while joining an IT company. The topics are divided into 2 generic groups: organizational and technical.

Organizational

Organization-related questions should be asked to understand the processes the company is using. Key points of this include performance reviews and career planning systems.

Processes

Are you using agile/scrum methodology? How long are your sprints?

Do you have 1:1 sessions?

Do you have an onboarding plan? How are new hires integrating?

Team culture

What are team values and team mission?

Are teams autonomous?

How usually are you doing team building events?

How does a team celebrate success and achievements?

Performance reviews, career and personal growth

What are your engineering levels?

How many times are you doing performance reviews during a year?

How are you measuring team and individual performance?

Do you have a self development plan? How can I reach my next level?

Can I switch my track? Is it possible to switch from individual contributor to management?

What are typical “next steps” for people in this role?

How long do people typically stay in their role before moving on to something new?

Other

Do you have book clubs?

Are you doing knowledge sharing sessions?

What kind of employee appreciation mechanisms do you have?

Do you have a stock plan? Are you paying bonuses?

How does a company address failures?

Technical

The other primary aspect of interviews are technical questions, which should be asked by the candidate to find out how the potential employer company matches his/her own technical goals.

Code branching, code organization and code review

What is your code branching structure?

How do you do code reviews? How many people are involved?

What kind of tools do you use to keep code clear and safe?

Have you implemented CI/CD processes?

What is your strategy when tests are failing during merge request or commits?

Testing

Do developers write unit/integration/UI tests?

Do you have UI tests and can developers run them?

Do you have SLAs and other processes to react to production issues?

Are you doing A/B testing?

Releases

What is your release cycle?

How much of your release cycle is automated?

Are your releases automated or do you do them manually?

Other technical questions(Here you can ask pure technical questions like listed below)

Do you use C++ 14?

Which version of Java do you use?

Do you use NoSQL database?

In general asking those questions will help candidates understand if the company meets their expectations or not. Questions should be asked to separate myths and truth about the company and its culture.

Ask questions to prove your assumptions and make your best decision!

Good luck!

[davit301]

How to Build High Performance Teams

In this video I’m talking about How to Build High Performance Teams. During my presentation I covered the following topics: [WATCH FROM 5:09:00]

What is a high performance team?

Stages of team development(forming, storming, norming, performing).

Common barriers faced by high performance teams.

About leaders.

Psychological safety.

Structure and clarity.

Meaning and impact of the work that team do.

And WHAT MAKES TEAM GREAT?

[davit301]

From zero to VIPER

Every time when we start development for new application we start with a single decision which architecture to use. VIPER is one of the modern approaches for mobile development. VIPER was partially modified by several world class tech companies to generate new approaches. In this talk I’ve presented main principles of VIPER and how to use it.

[davit301]

Native UI automation for iOS

How often are you writing tests for your own code? Are you familiar with unit, integration or UI tests? XCode provides great tools and framework to write native UI automation for your iOS apps. Watch the video to learn how can you do that.

[davit301]

How to organize code branching

Nowadays it’s hard to imagine coding without version control systems. Today’s systems are so huge that you even can’t work with single branch. As a result we’re facing a question how to organize code branching, where to write code, where to keep code to release and stuff like that. There are different version control systems and there are different approaches how to organize code branching. 

Today we will discover one of common approaches. Let’s call it master-release-develop. This approach have the following top hierarchy:

At the top we have our master branch. This is the most stable branch and we move code here from release as soon as our code goes to production. This branch only used to keep updated code. We don’t do changes in this branch directly, only update it from release. If you are using git It’s a good practice to tag release here so anytime you can checkout to specific release version. 

Next branch in this hierarchy is release. Release branch is used to keep your “code freeze”. We are going to push code to production from this branch. Before release we do critical bug fixes here. And every moment this branch is ready to go to production. After fixing critical issues in this branch it’s absolutely ok to update branches below this hierarchy. In our case we have only develop branch under the release. Despite of master, we can move code from here to develop and vice versa.

Develop branch is next one in our hierarchy. This branch is kind a base branch for all our develop-XXX branches. It also should be in a “good” state to allow developers use it as a base branch and make child branches for features or bug fixes.

Actually those 3 branches are the main root. After develop we make new branches from it for a specific features or bug fixes. That branches merge with develop and going up till master. This is a good principle to keep separate working branches. Each branch responsible for specific state of code. In every moment you know exactly where to find interesting code or from where to add/create new branch.

Sometimes developers use single branch for each bug, sometimes they create branch for a bunch of bugs. This culture is more specific to company’s approach, but in general having this structure helps a lot to keep things organized, working, separate and clean.

[davit301]

Pillars of clean code Pitch at Barcamp Yerevan 2017. Talking about pillars of clean code. What we can do to make our coding experience better.

[davit301]

10 pillars of clean code

We are writing codes every day and as a result our code base grows and grows. Every day we write a code which can be clean and help to write clean code tomorrow too. On the other hand, we can write a code that will become a pain and become harder and harder to maintain it. So, what can we do to keep our code clean, flexible and easy to maintain? I’m coding since 2005 and during this period I wrote some pillars of clean code for me and today want to share them with you.

Don’t hurry When you rush, the result is a non-working, unoptimal or a duplicant code. The best case scenario can be a working code which will be a source of issues later. Be patient, keep calm and code clear.

OOP Write object oriented code. Do not hesitate to create as much modules/classes as needed for clear and clean OOP code. Decompose things and keep each of them responsible for one thing.

Testing Do not miss to write automated tests for your code. Write unit, integration and UI tests. This will help you to find broken the code as soon as possible. Also, you can do continuous integration easily. More tests less bugs in the future, so write tests!!!

Flexible Code should be flexible. You should write a code which can be easily modified or replaced later, without touching tons of files. Also, a flexible code allows you to replace some components and keep whole system work fine.

Keep it simple Keep calm and write simple codes. There is no need to write 50 lines of codes to calculate sum of tree variables. Think as much as you need but code once, code clear, code short. Remember as much you type as much you get issues, as much you increase untested and uncovered code.

Think how it will be used When implementing new classes and methods think how they will be used. Usage shows interface. Try to look at your interface from user viewpoint. At that time, you will see how to keep them simple and easy to use.

Think how it will be extended Think how your code will be extended tomorrow. Try to keep them flexible. Use design patterns.

Solve problems when they appear - no code for 2100 If you are fixing an issue, just fix an issue. Do not think about unbelievable cases and do not write 500 lines of unused code just because someday someone somewhere maybe will use it. There is no need to spend time on things which will never happen. Do what you need to do now. If you will keep things flexible, simple and extendable it will be easy to make changes later.

Don’t touch what you don’t need  If you are fixing issue fix issue, do not start touch other files and codes. In that case, most of the time you will produce new issues, so do what you should do and not make issue fix something like refactor.

One commit one fix One commit should have one issue fix, one task implementation. When you do one commit for bunch of issues it will be difficult later identify which code broke something working, it will be difficult to revert something. If you are integrating some library do one commit for it. Then start use it and do other commits but do not commit everything once.

Sure, there are other things which are important too but in my opinion those 10 pillars are the most common and following this rules will cover other not mentioned things.

[davit301]

Core spotlight search and 3D touch in iOS 9

[davit301]

Company culture in IT companies, what’s good what’s bad

[davit301]

Hiring: Sunrise and sunset of IT companies

I want to start this article with one of my most favorite quotes from Netflix’s CEO. Reed Hastings once said: “Do not tolerate brilliant jerks. The cost to teamwork is too high” and I totally agree with him. TEAM AND TEAMWORK is the cornerstone of success in every company.  

I’m in IT industry since 2006. During those years I’ve worked for 4 companies, saw sunrises and sunsets and today want to share what I saw and what I think with you all.

Now, when I’m looking back and analysing companies I’ve worked for, I can surely say that success comes from hiring and company culture. Universally, company culture is about the employees and making sure they have a fun and productive working environment, they have a chance to grow personally and professionally, they are happy and productive. Company culture is important, it’s a “magic” thing which can make or break the company.

A Piece of history

The term “corporate culture” was developed in the early 1980s and widely known by the 1990s. Corporate culture was used at this time by CEOs, directors, managers, HRs and recruiters to describe the character of a company.

Sunrise

First employees should be hired with caution because they are the founders of your company culture. They are the founders of all main principles and it will be great to do if not everything then most of the things right from the 1st day.

One of the companies where I’ve worked was in the electronic trading area. That company had(hopefully now also does) great technical culture. The code was brilliant, developers were world class professionals. A lot of them now work at Google, Microsoft, Amazon, Deutsche Bank, Bloomberg and other 1st class companies. I remember when I was a student I had a dream to work there. Their hiring slogan was “best of the best of the best”. Those best people created one of the best companies and I had a chance to work there, learn from them and be proud that once I was part of them.

As employees leave companies after some time working there and replacements are hired, the company culture will change. And it’s very important to hire people with similar mindset, to hire people who can fit team culture and be trusted and supportive.

One of the companies where I’ve worked was a financial brokerage company. I joined the company not at the best time in terms of relationships among employees, atmosphere was incandescent. During next few months a lot of new employees joined the company and guess what happened. I started to see improvements absolutely everywhere. After a year that company was in the local leaders list. I love that company very much. I had a chance to grow there both personally and professionally. I felt that I was important there. I spent more than half of my career there, I got new friends and it was very-very difficult for me to leave the company. And again I am proud that I’ve worked there, was a part of something cool and bright. This was a great example for me, how every newcomer can bring bright with him/her and make things better and better.

Currently I work at another great company. Great from it’s 1st day, great with it’s employees technical background, great with interpersonal relationships, great with everything. This was an example for me how to be perfect from the beginning and keep that perfection with correct hirings: hire someone similar to you and keep your culture.

Sunset

Usually we miss bad things and mostly remember good in our life. The same for me in my career. I’m trying to remember bad things which I saw in my career but mostly I can’t. From bad things I can say one common thing. People with negative attitudes at the office can bring down the whole team. Negative people I met have some common characteristics and here are some of them:

Usually they are “The Bad News Bears”.

They like gossip and they are gossip mongers.

Usually they are the drama queens or kings. 

Usually they are victims, in every situation they try to be as a victim to hide their non professionalism and weaknesses. 

People with negative attitudes are the accelerators of company sunset, so avoid and ignore them.

End

Once I analysed all the good things that I saw during my career and as a summary I want to say the following:

Don’t hurry and choose carefully. Hire people who fits your company culture.

Employee should know values and missions of the company and should follow them.

People with CXO title, managers and leaders should know that good and right decisions can come from anyone and anywhere in the company. So listen to everyone.

Team! and not a bunch of individuals, no jerks! Remember what Reed Hastings said.

Good companies don’t give employee more than he/she can handle.

Good companies take care of their employees and don’t treat them as a resource.

At good companies good employees feel that they are important and they should be recognized.

Good companies offer opportunities to grow.

At good companies employees trust and respect their leaders, managers, directors and people with CXO title.

At the end I want to mention Guy Kawasaki who is the author of my another favorite quote. Once Kawasaki said “Good people hire people better than themselves. So A players hire A+ players. But others hire below their skills to make themselves look good. So B players hire C players. C players hire D players, etc.” and I totally agree with him. 

Good luck and thank for reading.

[davit301]

Stories Assume Easy Change

Fred George talks about success delivery of Agile projects. One of the most important factors to that success is recognising that the programming style of developers on the team is not well­ aligned with Agile. Watch his talk at GOTO conference.

[davit301]

Cache friendly coding - myth or true?

After reading topics and/or books about data structures and algorithms we know that search complexity for linked list and array is O(n) and insertion complexity for linked list is O(1) whereas for array it is O(n). But is theory works in the same way in practice? Actually not always :)

The “problem” is that fast memory is expensive. Memory speed is not growing as fast as CPU speed and not optimal use of CPU cache and memory slowness adds performance issues. Lets imagine a situation where one employee processing documents very very fast but other employees who should deliver that documents are working slow, in that way employee with high performance will have a lot of idle time as he haven’t documents to process. We have the same issue when now using our CPU cache in a not friendly manner. 

Let’s back to the complexities example above. Taking into account search and insertion complexities for linked list and array we can say that searching and inserting element in linked list should be much faster than for array. But the problem is that pointer arithmetics is slower than accessing elements located one after one in the cache. As we know CPU have caches (like L1 cache) and using it to reduce the average time to access data from the main memory. Look at the chart below to feel the difference:

Now lets see is it real that in some cases search and insertion in array(C++ vector in our example) is faster than in linked list (C++ list in our example).

I’ve tested this code for std::vector, std::list and std::set for 1000, 10.000, 100.000 and 1.000.000 elements (I’ve built and tested example below using Mac Book Pro with OS X El Capitan with 2.5 GHz Intel Core i7, 16GB 1600 MHz DDR3 memory and 512GB SSD drive).

#include <iostream> #include <vector> #include <set> #include <list> #include <chrono>

const auto needle = 5430127;

template <class Cont> void do_find_insert(Cont &cont) {    auto it = std::find(cont.begin(), cont.end(), needle);    cont.insert(it, typename Cont::value_type()); }

void do_find_insert(std::set< int > &cont) {    auto it = cont.find(needle);    cont.insert(it, 0); }

template <class Cont> void find_insert(Cont &cont) {    auto start_time = std::chrono::high_resolution_clock::now();    do_find_insert(cont);    auto end_time = std::chrono::high_resolution_clock::now();    std::cout << std::chrono::duration_cast<std::chrono::microseconds>(end_time - start_time).count(); }

int main(int argc, const char * argv[]) {    std::vector<int> vec;    std::set<int> set;    std::list<int> list;

   for (int i = 0; i < 10000000; ++i) {       vec.push_back(i);       set.insert(i);       list.push_back(i);    }

   std::cout << "Vector: ";    find_insert(vec);    std::cout << " microsecond";

   std::cout << "\nSet: ";    find_insert(set);    std::cout << " microsecond";

   std::cout << "\nList: ";    find_insert(list);    std::cout << " microsecond\n\n";

   return 0; }

Case 1: 1000 elements, searching 543 number, results are the following: Vector: 11 microsecond Set: 9 microsecond List: 3 microsecond

Case 2: 10000 elements, searching 5430 number, results are the following: Vector: 23 microsecond Set: 3 microsecond List: 38 microsecond

Case 3: 100000 elements, searching 54301 number, results are the following: Vector: 220 microsecond Set: 22 microsecond List: 684 microsecond

Case 4: 1000000 elements, searching 543012 number, results are the following: Vector: 2158 microsecond Set: 15 microsecond List: 4621 microsecond

As you can see if we have small number of elements linked list have better performance as it can spread elements near to each other, but when we have large number of elements array is better as it use advantages of CPU cache and accessing elements stored one after one is much “cheaper”.

[davit301]

Managers become leaders - Scrum at Scale

[davit301]

Facebook’s iOS app architecture

[davit301]

The magic of “mutating” keyword in Swift

Swift is a new programming language for iOS, OS X, watchOS and tvOS apps. It brings brand new way to develop applications. Swift have new syntax, new language features, it collects a lot of cool things from other programming languages and have it’s own set of nice and cool features. Let’s see what mutating keyword do in Swift.

In Swift structures and enumerations are value types. By default, the properties of a value type cannot be modified from within its instance methods. But if you want to modify a property you need “mutating” behaviour for that method. In opposite to this class doesn't have immutable or mutable behaviour, because it is not a value type, it’s reference type. “mutating” keyword is something like a mix of “const” and “mutable” keywords in C++. 

Let’s see an example which clearly shows how “mutating” keyword works in Swift:

import Foundation

class ClassToTest

{

   var member = 5

   func printMember()

   {

       print("class member value is \(self.member)")

   }

   func makeSquare()

   {

       self.member = self.member * self.member

   }

}

struct StructToTest

{

   var member = 7;

   func printMember()

   {

       print("strcut member value is \(self.member)")

   }

   mutating func makeSquare()

   {

       self.member = self.member * self.member

   }

}

var classObj = ClassToTest();

var structObj = StructToTest();

// At the end replace var in classObj and structObj declarations with 

// let and check what happens.

// Do changes like in the commented lines below.

// let classObj = ClassToTest();

// let structObj = StructToTest();

print("before mutating")

classObj.printMember()

structObj.printMember()

classObj.makeSquare()

structObj.makeSquare()

print("after mutating")

classObj.printMember()

structObj.printMember()

Output of this code is the following:

before mutating

class member value is 5

strcut member value is 7

after mutating

class member value is 25

strcut member value is 49

Try also play with let and var keywords as described in the comment to see what kind of error compiler will show. 

[davit301]

Node.js clustering - scalability and deployement

Scalable applications are not just dependent on systems but rather the application architecture used. Node.js if properly used can be a great asset in any scalable network.

Node.js scalability

Node apps essentially run single-threaded, even though file and network events could leverage multiple threads. So, how is production scaling achieved in Node.js?

To take advantage of multi-core systems, Node applications can be run as cluster of Node processes to handle the load. However there are programmatic and runtime ways of managing these clusters.

The node-cluster module is the basic mechanism allowing a master process to spawn worker processes and allowing developer to share a socket across multiple networked Node applications. The master – worker logic is simple, this is achieved using file descriptors and serialisation. When you call server.listen(…) in a worker, it serialises the arguments and passes the request to the master process. If the master process already has a listening server matching the worker’s requirements, then it passes the handle to the worker. If it does not already have a listening server matching that requirement, then it will create one, and pass the handle to the worker.

Primarily Node.js is best used for:

Network applications

Non blocking operations

Dynamic applications

Real-time applications

JSON api server

Ajax heavy applications

Distributed single purpose applications

What are some bad uses of Node.js:

CPU heavy applications

Static html based applications

Large complicated applications

The best use of Node.js is when combined with some other application framework. For example use Node.js as your API server and use C++ for any CPU intensive work. You can even use Node.js as a form of socket server and use other frameworks as your application layer combined with some message queueing systems such as ZeroMQ or Amazon Simple Queue Service or something else.

Node.js deployement

There are a lot of ways to deploy your Node.js application. Amazon web services are one of them. I’ll skip Amazon Web Services introduction and how to launch your virtual machine via Amazon EC2 service.

Install Node.js and NPM

The most effective way is to set up GCC/C++ and compile Node.js for your Amazon Linux distribution. We need to install gcc and openssl for compiling, git to get Node.js source code. 

sudo yum install gcc-c++ make

sudo yum install openssl-devel

sudo yum install git

git clone git://github.com/joyent/node.git

cd node

git checkout vX.Y.Z

./configure make

sudo make install

Running Your Node.js Application in AWS

You simply execute your script on the server the same way you have been executing on your machine. The best way to get the code on the server is simply to use a source control repository (such as github) and clone the code on the server. Just do the following simple commands:

git clone git://github.com/youcompacy/yourproject.git

git checkout master

npm install

node your_app.js

And that’s pretty much it. Your application is now ready for public consumption.