5 ms·

The article makes a case for "the failure of the U.S. education system to prepare the country's next-generation tech workforce": Many American grads looking to

by quizbiz 17y ago

The article makes a case for "the failure of the U.S. education system to prepare the country's next-generation tech workforce": Many American grads looking to enter the tech field are preoccupied with getting rich, Vineet said. They're far less inclined than students from developing countries ... to spend their time learning the "boring" details of tech process, methodology, and tools--ITIL, Six Sigma, and the like.

kqr2 17y ago
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.
- avner 17y ago
  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#Entrance_competition http://en.wikipedia.org/wiki/Indian_Institutes_of_Technology...
deleted 17y ago
[deleted]
patio11 17y ago
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.]
- paraschopra 17y ago
  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?
  - patio11 17y ago
    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.
    - paraschopra 17y ago
      Oh, do you have to work with them during your day job? I thought it was regarding BingoCardCreator
      - patio11 17y ago
        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.
- niyazpk 17y ago
  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/ 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.

by quizbiz 17y ago

kqr2 17y ago

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.

avner 17y ago
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#Entrance_competition http://en.wikipedia.org/wiki/Indian_Institutes_of_Technology...

deleted 17y ago

[deleted]

patio11 17y ago

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

paraschopra 17y ago
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?
- patio11 17y ago
  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.
  - paraschopra 17y ago
    Oh, do you have to work with them during your day job? I thought it was regarding BingoCardCreator
    - patio11 17y ago
      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.
niyazpk 17y ago
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/ 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.