Check before joining a software firm


In my job experience, I got names of many software companies. Some seem good, but there are some internal issues. If anyone miss to know any of these, he/she may suffer after joining there.

I think it is a good idea to have a checklist for this. Here it goes!


1. Does that company follow software engineering process?
In my experience, I found some senior people who STRONGLY BELIEVE that no process can be applied in their projects. Also, some even don’t know the difference between Software Engineer and Programmer.

2. How about their interview process? That is they will take your interview and you will also get idea about them.
Some companies don’t know how to take interview for Senior software engineer, software engineers or programmers. All seem same to them. So, if you are appearing interview for sr s/w engg, but their interview seems that for programmers, you should know that they will assign you task of programmers.

3. How many hours do you “actually” need to work a day, on average? Can a programmer can work more than 8hrs a day? Every overtime just add bugs in projects.

4. How frequent is overtime and working in weekend? In some companies, 11/12 hrs a day is normal working hours and their projects are always buggy. And same about weekend, on an average 3/4 weekend are added to working day in a month.

5. How friendly is the relationship among the engineers and also with management?

6. Notice period. when employees try to resign or company try to terminate an employee’s job, what is the notice period. Some companies don’t follow the this rule. They just terminate job from next day and pay 1 or 2 months salary.



1. How many projects are currently going on?

2. What is the average age/length of the projects? How many years employees are involved there? that is, project is long, but for some reason, employees can not stay there.

3. Do they work on products or projects for clients? Products are so long and all are preplanned. So. company has to release 1/2 times a year with the specific features. So, work load is distributed in whole year. but if projects for clients, sometime no task, sometime so much pressure.

4. Which technologies does the company work with? which domain etc.

SALARY and other benefits:

1. Office space or location. It shows how much the company is serious about their business, how much the company are investing for this business. It shows the job security, financial strength.

2. What is the salary range for a fresher?

3. How many times in a year do your company give salary increment? Do they review in time or some months delay?

4. What is the average percentage of increment?

5. Do you feel that your job is secured? How many years employees stay at that firm? Can this company show any long-term vision to employees?

6. What are the other benefits?

7. Do they use documents such as offer letter/appointment letter, experience letter, release letter? Get the offer letter, read the terms and conditions. You and the company will sign. You will take one copy and company will take another copy. some companies have some plan to cheat. They won’t use any documents of proof of job.

8. What is the payment method? Bank account or cheque or cash. That is, check whether their salary payment method is official or not. If they pay salary in cash, what are the proofs that you got salary, or you got some part of salary and some part will be paid, or how can you claim that your company didn’t pay your salary.

And at last Joel Test

The Joel Test

Do you use source control?
Can you make a build in one step?
Do you make daily builds?
Do you have a bug database?
Do you fix bugs before writing new code?
Do you have an up-to-date schedule?
Do you have a spec?
Do programmers have quiet working conditions?
Do you use the best tools money can buy?
Do you have testers?
Do new candidates write code during their interview?
Do you do hallway usability testing?

Better score, better company..

So, you should choose your employer as like as employers choose their employees.

[ Idea courtesy: Ahmad Ferdous Bin Alam’s post  Checklist Before You Join a New Company ]

Association vs Aggregation vs Composition


, , ,

In programming experience, I found confusion about Association, Aggregation and composition. So, Here I am trying to clearing the concepts.

Association is a relationship where all object have their own lifecycle and there is no owner. Let’s take an example of Teacher and Student. Multiple students can associate with single teacher and single student can associate with multiple teachers but there is no ownership between the objects and both have their own lifecycle. Both can create and delete independently.


Aggregation is a specialize form of Association where all object have their own lifecycle but there is ownership and child object cannot belongs to another parent object. Let’s take an example of Department and teacher. A single teacher cannot belong to multiple departments, but if we delete the department teacher object will not destroy. We can think about “has-a” relationship.
Another example, Wheels are the part of Car. Car owns the wheels, but wheels can exist, if car is not available.


Composition is again specialize form of Aggregation and we can call this as a “death” relationship. It is a strong type of Aggregation. If owner object is destroyed the other one will no longer exist. Let’s take again an example of relationship between University and Department. University can contain multiple departments. There is no independent life of departments and any department cannot belong to two different universities. If we delete the university, departments will be automatically deleted.
Let’s take another example relationship between Questions and options. Single questions can have multiple options and option can not belong to multiple questions. If we delete questions options will be automatically deleted.


So in summary, we can say that aggregation is a special kind of an association and composition is a special kind of an aggregation. (Association->Aggregation->Composition)


Figure : Association, Aggregation, Composition

How struct manage its variables?


, , ,

Suppose we have struct like this.

double dVal;
int nVal;
char chVal;
} Data1;

So what will be the size of Data1?
We think like
sizeof(char) + sizeof(int) + sizeof(double) = 13. Is it?

But Surprisingly we are wrong.

Again look at another struct like this.

int nVal;
char chVal;
char chVal2;
double dVal;
} Data2;

We think like
sizeof(char) + sizeof(char) + sizeof(int) + sizeof(double) = 14. Is it?

In both cases, sizeof(Data1) and sizeof(Data2) will be 16. how?

So, struct stores its variables in different way. Let’s discuss.

1. struct allocate memory for its first variable as same as the most longest variable used in that struct. Here double is most longest. so, it will allocated 8bytes for the first variable.

2. Then come for the second variable. It checks the size of the data type of the second variable. If already allocated memory for first variable, is enough then struct doesn’t allocate new memory. Otherwise, allocate big size like first variable.

Now discuss about our example.

struct Data1
1. For double it will allocate 8bytes,
2. For int, it will also allocated 8bytes.
3. For char, I won’t allocate any, because already 4bytes is extra from int type.

struct Data2
1. for int datatype it will allocate 8bytes, as double needs 8bytes.
2. for char it will need 1byte. As Data2 have already 4bytes extra, so no need to allocate for next two char.
3. Now Data2 have 2 bytes extra, but double needs 8bytes. So, 8 bytes will be allocated.

I think we all are clear now.

Design Principles


, , ,

Object Oriented Analysis and Design(OOAD), that is, design principles represent a set of guidelines that helps us to avoid having a bad design.

Let’s discuss some important issues. We can call it SOLID principles (Single responsibility, Open-closed, Liskov substitution, Interface segregation and Dependency inversion).

Single Responsibility Principle
A class should have only one reason to change.

In this context a responsibility is considered to be one reason to change. This principle states that if we have 2 reasons to change for a class, we have to split the functionality in two classes. Each class will handle only one responsibility and on future if we need to make one change we are going to make it in the class which handle it.

Open Close Principle(OCP)
Software entities like classes, modules and functions should be open for extension but closed for modifications.

OPC is a generic principle. You can consider it when writing your classes to make sure that when you need to extend their behavior you don’t have to change the class but to extend it. The same principle can be applied for modules, packages, libraries. If you have a library containing a set of classes there are many reasons for which you’ll prefer to extend it without changing the code that was already written .

Liskov’s Substitution Principle(LSP)
Derived types must be completely substitutable for their base types.

This principle is just an extension of the Open Close Principle in terms of behavior meaning that we must make sure that new derived classes are extending the base classes without changing their behavior. The new derived classes should be able to replace the base classes without any change in the code.

Ostrich is a Bird (definitely it is!) and hence it inherits the Bird class. Now, can it fly? No! Here, the design violates the LSP.

Interface Segregation Principle
Clients should not be forced to depend upon interfaces that they don’t use.

This principle teaches us to take care how we write our interfaces. When we write our interfaces we should take care to add only methods that should be there. If we add methods that should not be there the classes implementing the interface will have to implement those methods as well. For example if we create an interface called Worker and add a method lunch break, all the workers will have to implement it. What if the worker is a robot?

Dependency Inversion Principle
High-level modules should not depend on low-level modules. Both should depend on abstractions.
Abstractions should not depend on details. Details should depend on abstractions.

Dependency Inversion Principle states that we should decouple high level modules from low level modules, introducing an abstraction layer between the high level classes and low level classes. Further more it inverts the dependency: instead of writing our abstractions based on details, the we should write the details based on abstractions.

Suppose, for some reason Printer should be used in a PC. Then we need a connection port. So, PC and Printer both should have same connection port option. If we need to use Camera in a PC, it will be same. that is the dependency.
If we use abstraction layer, It is so easy. That is USB port.