I have been managing a portion of my company's Indian outsourcing operations for the last two years. Speaking in generalities, I think that the system over there privileges "methodologies" and certifications over both core skills and core CS concepts.

I have talented Java engineers working for me who I have had to teach regular expressions to. Many American engineers with graduate degrees in CS from a good university would be able to predict that /ab+/ matched the string "abc". It would be unlikely in the extreme for them to have never heard of the word "regular expression" before. I am oh for five on this with my most recent five Indian engineers. Even after teaching them basic regular expressions I have not found them capable of using them to accomplish tasks without specific direction.

(For example, if someVariableName is used in the project, and the customer later informs us that our naming of it does not match their understanding, we might have to rewrite that variable name and associated variables and methods globally. It should be trivial to find all instances of that with a search by regexp, right? But they don't hear that in the instruction "X is now called Y, change all appropriate variables and methods" -- instead, two days later I'm told they're done with a job that I expected to take a few hours, and then I fire a regexp against the source tree and see that 40% of it is still not done.)

I have frequently had to explain bugs to our engineers which resulted not from chance or carelessness but from simple ignorance of core CS101 concepts, such as pass by reference. (Example: In our first code review, I noticed a lot of reuse of HashMaps to carry parameters to DAOs. I told folks to not reuse them, because that introduces the risk of somebody changing the HashMap in the DAO, thus causing later users of the map to have unexpected behavior. I was told, by our most talented Indian engineer, that this would not happen because the values in the HashMap would magically spring back after the DAO was done with it. This does not happen, and it is a CS101 misconception. Sure enough, we had bugs caused by reuse. So, after a remedial CS101 lecture to the team, I reiterated that maps were not to be reused, because they would cause bugs. What do I find in Code Review #2? More reuse of HashMaps, with "final" applied to all of them. Final does not magically turn pass-by-reference into pass-by-value. (The fact that this obviously did not fix the bugs and would have been caught by ANY testing of the code is another matter. We get that a lot.)

When I ask our engineers what they wanted to accomplish in terms of professional growth in their time in Japan, the answer was unanimous: study for certs, which they all already had several of. I'm not necessarily hostile to certs in theory, but I'm sure starting to cool to them in practice.

As for teaching "tools": I won't be too harsh on India because American universities fail at it, too, but if they're teaching fundamentals of source control or IDEs I have yet to see any evidence of it. We have been trying to change a corporate culture at our Indian partners away from having one "source control master" per twenty engineers. They're the only ones permitted to commit -- everyone else mails their code to the source control master, who integrates it. This is to "stop people from breaking the build".

Our Indian colleagues have their own requests for us. For example, they would prefer not to use source control, "since it adds overhead to our management processes".

I freely admit that I only have seen about three corporate cultures from over there and may just have terrible, terrible luck.

[Edited to add: Neither my company nor I are blameless for this state of affairs. Believe me, we have many, many areas we could improve upon collectively, and I have many, many individual weakpoints, including a longstanding cavalierness about how much testing needs to be done prior to shipping. I don't want it to sound just like I'm blaming our Indian colleagues.]