In his criticism, replace American grads with corporations and you get:

Many corporations are looking to enter the tech field are preoccupied with getting rich

Of course, corporations want a cheap labor workforce that they don't have to train.

A good college education should give you a solid foundation for learning new things; not just job training.

I concur. It should also be noted that the work culture in the US is different than that of India. Very often, foreign companies investing in the U.S. make the mistake of expecting the same uniformity in the local workforce that they are used to seeing back home.

I should also mention the monumental levels of competition overseas students like in India have to clear to have a shot at a school like IIT, and I guess this radiates into everything else that follows. http://en.wikipedia.org/wiki/Indian_Institutes_of_Technology...

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.]

You are very correct about these observations.

I am an Indian myself, and some time ago I wrote an article that tried to explain why the engineers in Indian outsourcing companies tend to be of low quality: http://www.diovo.com/2008/08/why-outsourcing-sucks/

The only thing I would like to add is that I think that this percieved difference between the US and Indian engineers is because of our view point itself, and not because of the lower quality of CS education in India as such. Outsourcing companies tend to recruit low quality engineers and so you find more of them there.

These outsourcing companies recruit in thousands each year. This means that they don't give a ____ about quality.

The US counterparts recruit good engineers.

If you want to really compare the quality of US and Indian engineers, compare the quality of them in the startups.

"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."

I find it interesting that this understanding corresponds to the immutable data types used in functional programming languages. In Clojure, for example, a function that appears to alter a map actually creates a new map that shares some of its values with the old one.

There is this notion that the ideas of functional programming are more advanced, or harder to understand than paradigms like OO with mutable data. But in this case the intuition of a naive programmer more closely follows the immutable functional paradigm.

Of course, it is just as likely that this same programmer will expect the same data structure to be mutated in other scenarios, and ascribing a consistent model to his understanding of the code is an invalid assumption.

Just curious. If you have so many negatives in favor of Indian engineers, why do you still work with them? Is it because of cost effectiveness or is it because you think every engineer has negatives and these are just specifics to Indians?

With regards to my own business, I'm solidly in the let-it-all-hang-out camp. I'm also willing to tell you a few anecdotes from my professional career, but that is about as far as I can go. I really can't discuss strategic matters from my day job -- it would be a breach of their trust in me.

Oh, do you have to work with them during your day job? I thought it was regarding BingoCardCreator

Oh, BCC is a totally different story. I've worked with an Indian freelancer or two before, including most notably the young lady who did the site design I'm currently using. Using that experience as an example -- it wasn't totally friction-free but I got something valuable accomplished which I couldn't do myself. It would have been cheap at five times the price.

With regards to BCC, I have no intention of outsourcing any project which is not small, self-contained, and describable in a page or less. That means coding the program/website stays in-house. Or, hmm, in apartment kitchen as the case may be.

I must say, my brief experience in managing a team of Indian developers had all the same sorts of issues. There were certainly bright and talented individuals, but the inability to rely on any given level of competence was maddening. I think it was made all the worse by a cultural fear of challenging authority that made them extremely averse to admitting any inability to understand or comply with direction. They would all smile and tell me they understood everything and then produce code with basic flaws that proved they didn't understand anything, even core concepts that were well within the supposed certifications they had. It took a lot of time but eventually they became a reasonably productive team, but I'd hesitate to recommend any company go this route unless it's a major and long term project because the overhead of getting through it all is enormous.

I may be wrong but I'm fairly sure that /ab+/ would not match the string "abc". I might just be using a different library but /ab+/ would match "ab", "abb", "abbb", etc. The plus means one of more of the previous character. /ab?/ would match "abc" though...

The regular expressions built into many programming languages have the semantics of matching any part of the string, not necessarily the whole string. If you want to match the whole string, you're supposed to put ^ at the beginning and $ at the end, or something like that.

It'd match the string, the same way /a/ would match "abcdefg."

grep -o /ab+/ would only show "ab" from "abc"

iirc, /ab(?![^b]+)/ would match "abb" but not "abc"