Too specific job requirements

[sriram sankar]

Recently i found that employers are too picky in their selection( due to recession:).

The requirements for a Java developer is too specific, only a few may actually have it.

Like Spring/Hibernate - 6 years experience, i don't know how many will really go into this ...


Share your thoughts.

[Joe San]

Spring / Hibernate is not something specific these days. They are like the common skills that a person with 6 years of experience should have if that person is working on the JEE platform. Atl east I would say this.

[Ulf Dittmer]

Take all this with a grain of salt. Spring didn't hit version 1.0 until March 2004, so it would be kind of tough to have 6 years of experience with it (few enterprises would consider using pre-release software). Also, what's the difference between a developer having 4 years of experience with a product and one having 6 years of experience? Lastly, "experience" can mean different things; I'd rather hire a developer who has 2 years of experience with Spring who has written code that uses one of its classes every week of those 2 years, than one that has been working with code that used Spring for 6 years, but has never worked with the actual Spring API; both could claim "experience" with Spring.

[Digvijay Kumar]

They are even specific about application server like 2 year in weblogic 9.x and above.

[Digvijay Kumar]

Jothi Shankar Kumar wrote:Spring / Hibernate is not something specific these days. They are like the common skills that a person with 6 years of experience should have if that person is working on the JEE platform. Atl east I would say this.

I do not agree.
what if person has worked in core java, ejb, jms, ajax, direct jdbc,web services, database for 6 years.He/she has more strong profile than spring and hibernate

[Joe San]

Digvijay Kumar wrote:

Jothi Shankar Kumar wrote:Spring / Hibernate is not something specific these days. They are like the common skills that a person with 6 years of experience should have if that person is working on the JEE platform. Atl east I would say this.

I do not agree.
what if person has worked in core java, ejb, jms, ajax, direct jdbc,web services, database for 6 years.He/she has more strong profile than spring and hibernate

There is the catch. If you claim that you work on EJB (I assume EJB 3.0 here), then I would expect you to know the alternative equivalent which is Spring. Of course JPA which got modelled from Hibernate is already part of the EJB 3.0 specifications. Maybe the API's differ but the core underlying concept is the same.

[Ulf Dittmer]

If you claim that you work on EJB (I assume EJB 3.0 here), then I would expect you to know the alternative equivalent which is Spring.

I don't see why. Spring is substantially different from EJB; it doesn't even address all the same problems. Having experience with one has no correlation with having experience with the other. (Unless by "know" you mean just having a general knowledge about what a particular framework does; I would agree that every enterprise developer should have that about EJB, Spring, Hibernate and lots of other frameworks and APIs.)

[Digvijay Kumar]

If you claim that you work on EJB (I assume EJB 3.0 here), then I would expect you to know the alternative equivalent which is Spring.

i think ejb3 was not there 6 years back. i was talking about ejb2, but even if it is ejb3, i did not mean 6 years in ejb3.
when i said 6 years, it is combined experience of the technologies i mentioned ejb, jms, jdbc, database, web services,ajax.
like 3 years in ejb2,jms, 1 year in jdbc and database, 2 years in ajax and web services.

ejb3 is not equivalent of spring, spring is IOC container, ejb3 is JPA implementation.

[Ulf Dittmer]

ejb3 is JPA implementation.

Let's be precise: Hibernate, OpenJPA and EclipseLink are JPA implementations. EJB 3 is a specification that comprises much, much more than persistence (the part that the JPA API handles).

[Digvijay Kumar]

agree.

[Tim Holloway]

Actually, the "laundry list" recruitment hasn't been as blatant during this recession as the last one, where I could easily find lists with a dozen or more "must-haves" coupled with a dire warning not to even apply unless you were a perfect fit. Which was statistically unlikely, and probably only really served to find out who was willing to lie profusely to get the job. Especially since they demanded more experience than anyone who hadn't actually been on the product's development team could possibly have.

I think 6+ years of Spring pushes it. I've worked with Spring a long time, but I'm not sure that it's been that long. Though time files when you're having fun. In any event, almost no software product is static enough that what you knew 6 years ago is all that relevant to current technology. In IT, the value of experience isn't in what you learned about a specific platform, but what you learned from many platforms.

I'm not sure if the relative scarcity of "laundry lists" this time around means that recruiters have wised up or is just an indication that they're not even trying to hire anymore. On the other hand, a major (Fortune 500) shop here in town placed a truly remarkable ad in various places right before Christmas, that was actually looking for realistic, practical general IT skillsets. And they had been one of the laundry list offenders in previous times.

[Joe San]

Ulf Dittmer wrote:

If you claim that you work on EJB (I assume EJB 3.0 here), then I would expect you to know the alternative equivalent which is Spring.

I don't see why. Spring is substantially different from EJB; it doesn't even address all the same problems. Having experience with one has no correlation with having experience with the other. (Unless by "know" you mean just having a general knowledge about what a particular framework does; I would agree that every enterprise developer should have that about EJB, Spring, Hibernate and lots of other frameworks and APIs.)

What you learn in EJB 3 is the DI principle which was inspired originally from Spring. What else technically that you need to know in Spring apart from the DI principle (apart from Spring specific API's)? If one can understand this principle, then learning Spring / EJB 3 should be a breeze. Well, last year, I worked on EJB 3.0 and when I started self reading Spring, I found it nothing new apart from Spring specific way of dealing with the different tiers of the application.

[Tim Holloway]

I was working with Dependency Injection long before I heard of Spring. And to be truly proficient in Spring, you not only need to know the core tech, but be able to use the various add-ons, like the web framework, the ORM framework (EJB/JPA and otherwise), etc.

So I'll have to side with Ulf on this one. If I was hiring for Spring, EJB3 would be a plus skill in the sense that any major platform is a plus skill, but I wouldn't consider that it confers much in the way of expertise with Spring.

[sriram sankar]

If some one works with a ORM tool like Toplink and the requirement ask for hibernate. The recruiter is so keen for Hibernate in the resume...

[Digvijay Kumar]

What else technically that you need to know in Spring apart from the DI principle (apart from Spring specific API's)? If one can understand this principle, then learning Spring / EJB 3 should be a breeze.

have you worked on spring?

[Digvijay Kumar]

sriram sankar wrote:If some one works with a ORM tool like Toplink and the requirement ask for hibernate. The recruiter is so keen for Hibernate in the resume...

these recruiters really irritate.

[Jimmy Clark]

As always, my initial stance is to suggest that you seek companies that are using it's own internal HR staff to do the recruiting. Technical recruiters, either independent or part of a recruting firm, are like car salesmen. There are few good ones and a ton of bad ones that will waste your time.

When HR does the recruiting, they will typically guide and help you along the way while you interview with the hiring authority and his/her team. There is no sales commission involved and the HR and the hiring authority share a common interest.

When dealing with technical recruiters you really need to create your own set of requirements for dealing with them. For example, ask them how long they have been recruiting, who have they worked with in the past, do they understand situational leadership principles....basic questions. In time, you will be able to identify "good" recruiters and "good" job descriptions, and be able to ignore the "bad" ones.

Good luck!