I worked with Itelligence from June 2013 to April 2015 as a SAP SD consultant. Before that, I worked for approximately 8-9 months as a junior developer. My first stint as a developer went horribly wrong and I was fired. I then went out and got trained on SD, CRM and BO. I came back to the same company, cracked the interview and started working as a SD consultant.
In the past one year, I have been looking for jobs for my experience level – 1 year 10 months. I didn’t collect the earlier 8-9 months experience letter since it was on a different company name and was not on the same skill set. My experiences in the last one year is what I am going to be writing about and the common problems that one faces while applying for jobs and my experience of interviews with different companies.
The first topic I want to write about is experience. In IT, especially in domains such as ERP functional consulting, development, system admins, Basis and other roles, a candidate’s experience is often seen as a measure of that candidate’s proficiency and knowledge. The more the experienced, the more the knowledge and the more the proficiency. However, when I worked in the company, I didn’t find this to be true in a lot of cases. There are many developers and functional consultants who work at a higher productivity level, have more knowledge, have better in-system coding and configuration skills, better troubleshooting skills and also better communication skills than people with more experience than themselves. Also, the kind of work and company matters too. In Itelligence, they say that a person who works at Itelligence has 3 times the experience of an equally experienced person from a bigger MNC (typically the Delloites, Accentures, IBM’s HCl’s, TCS’s, Infosys’s, Tech Mahindra’s of the world). The reason is that in bigger companies, one rarely gets opportunities to work on actual coding or configuration – most of TCS’s projects are support projects – their clients have implemented SAP many years back and most of the times, the tickets that come up are background job and coding related issues – there is very little scope to do any new coding or configuration based on any requirements gathering and analysis. This results in employees who have worked on very few areas within their module/language. In small companies, there are a lot of implementation/development projects; the team size is usually small – this means that there is one person per module and one developer usually builds multiple objects per project. Such kind of experience is very rare in large companies. Hence, after a period of time, the employee from a large company either finds it difficult to cope up with the work style of a small company or does not have the same knowledge and work experience of an equally experienced person from a small company. This is one way in which experience itself does not necessarily translate to more knowledge, proficiency or troubleshooting skills.
Then comes the issue of fake experience. Many companies often inflate or fake the experience of their employees on client projects. My interest here is in looking at how a company thinks that a person with relatively less experience is competent enough to be working on a client project. If a company (and the managers) think that a person can work on a project even though he/she doesn’t have the number of years of experience that the company is claiming on his/her behalf, then it obviously means, by the company’s own admission that experience is not an indicator of proficiency, knowledge or quality of a person.
Next, consider the fact that in many companies, young people often are seen working in managerial and leadership roles. There are plenty of instances when a person joined as a fresher and in 7-10 years rose up (salary and title) even beyond the people who were senior to him when he was hired.
Mark Zuckerberg became the world’s youngest billionaire (or maybe tech billionaire?) and still, somehow, if he were to quit today and apply in some company as a PHP developer with 15 years experience, I’m not so sure he would either get a similar title or a similar salary in most companies, including Facebook. Its not that he doesn’t have the skills to build something like Facebook, or that he doesn’t have the experience of taking a small company into mega success and running a hugely successful company. It’s just that the industry doesn’t acknowledge that people are capable of performing much beyond the standards that companies set (arbitrarily?) for a particular experience level.
The above paras show that experience itself is not the indicator of proficiency and knowledge that it is made out to be.
All this brings me to the topic of why companies have rigid policies on experience and salary. When they themselves inflate the experience of their employees on projects, they are sending the message that experience doesn’t really matter. I am not going into the discussion of whether it is right or wrong to lie about experience – thats a different discussion – although I’m not sure, I think that experience started to become something clients insisted on when Software projects, including ERP projects started failing. Many clients had invested millions of dollars on buying and implementing a new system. They wanted, at the very least for it to work. However, mismanagement, consultants and developers who didn’t have the knowledge and proficiency , lack of a buy in from client management and key people all lead to project failures. A google search of ERP failures or Software project failures lists all these reasons and more. Such failures may have led clients to insist on experienced consultants and developers. The only problem with this is that a client doesn’t really understand the technology well enough to make any sort of estimate on what level of experience is required to develop/implement such a project. When I wanted to build a website, I had a meeting with a web development firm. All I did was tell them how the site should function and answered some questions they asked me. But beyond that, I did not have any idea as how the site was going to be built. Sure, I could have been cautious and told them that I want a person with 10 years experience to build my website. But then, I don’t really know the difference between a developer with 4 years experience, a fresher and a developer with 10 years experience. Not technically at least.As long as I get the website built the way I want it to, it works they way I want it to, it has all the features I wanted it to have, its been built within my agreed budget and I have tested and okayed the website for everything, I don’t really care about the experience of the developer who built it. Clients shouldn’t be dealing with the experience of developers/consultants/anyone, especially if they themselves don’t have anyone to estimate the effort and developer experience required to build/implement a project. When a client hires an IT service provider to develop/implement/maintain/support a system, they should trust the IT service provider to successfully develop and ship a working system. The trust deficit that the client has towards the IT service provider is a case for worry for IT service providers. They have to take steps to address this issue holistically – whether it means educating the client on technical issues or telling him the real complexity involved in building a system, IT service providers need to take action. Building systems for a client is often more difficult than building a product. iOS has the same features irrespective of who uses it, is built once, tested and deployed. An Accounting package, on the other hand, deals with tax laws that change periodically, are different from state to state and country to country and involves knowledge of Accounting – just being a proficient developer won’t cut it.
When companies think that experience is not an indicator or proficiency or knowledge ( seen from the fact that they inflate the experience of their employees on client projects), even companies should be a little relaxed about experience when hiring employees. Change policies that place an upper limit on the salary that a person with a certain experience level can draw. (eg fresher – 3 LPA, 1 year 4 LPA. 2 years 5 LPA, 3 yeats 6 LPA etc) These are loosely translated into career levels (although it is again quite possible and it even happens quite often that people with different experience levels are on the same career level).
This is quite common in the industry. I had applied to a company looking for SD consultants with 1-3 years experience:
In the above questionnaire, the company has a ceiling on the salary for 1-3 years experience – 450000.
At the bottom, they also have a question about bonds!. Sad.
All interviews should change from purely question answer to more hands on tests. A developer can be given a real Functional specification document and he can be asked to prepare a technical specification document and write a program in the system. His skills can be seen through his code. It doesn’t need to work on the first try, but an experienced developer can see the approach to solving the problem that the developer has taken. Things like Hackathons as a way to hire new employees are being discussed in the HR space and maybe it won’t be long before something like it materializes in mainstream interview techniques in major companies.
srinivaskari 