Software Is Eating the World

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!

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.

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.

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. 

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

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

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