Stories
Slash Boxes
Comments

SoylentNews is people

posted by cmn32480 on Friday August 25 2017, @03:18PM   Printer-friendly
from the do-we-need-a-bridge dept.

The idea that American workers are being left in the dust because they lack technological savvy does not stand up to scrutiny. Our focus should be on coordination and communication between workers and employers.

Technology enthusiasts and entrepreneurs are among the loudest voices declaiming this conventional wisdom (see "The Hunt for Qualified Workers").

Two recent developments have heightened debate over the idea of a "skills gap": an unemployment rate below 5 percent, and the growing fear that automation will render less-skilled workers permanently unemployable.

Proponents of the idea tell an intuitively appealing story: information technology has hit American firms like a whirlwind, intensifying demand for technical skills and leaving unprepared American workers in the dust. The mismatch between high employer requirements and low employee skills leads to bad outcomes such as high unemployment and slow economic growth.

The problem is, when we look closely at the data, this story doesn't match the facts. What's more, this view of the nation's economic challenges distracts us from more productive ways of thinking about skills and economic growth while promoting unproductive hand-wringing and a blinkered focus on only the supply side of the labor market—that is, the workers.

https://www.technologyreview.com/s/608707/the-myth-of-the-skills-gap/

What do you think, is there a shortage of skilled workers ??


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 1) by Zal42 on Friday August 25 2017, @05:45PM (9 children)

    by Zal42 (5435) on Friday August 25 2017, @05:45PM (#559007) Homepage

    All of the companies I've worked for or with over the last decade or so have a rather difficult time finding qualified employees in the US. It's not for lack of trying -- it's because software engineers being trained are typically being trained in for particular subset of the industry. They know Java, Python, and are skilled at Stack Overflow, but aren't very capable outside of that. As a company, that's all well and good if you need those skills -- but it's not terrible helpful otherwise because of the large amount of training required to bring them up to speed.

  • (Score: 4, Insightful) by Anonymous Coward on Friday August 25 2017, @06:10PM (4 children)

    by Anonymous Coward on Friday August 25 2017, @06:10PM (#559032)

    If they can't figure it out, they don't need the work done that badly. Why is it always the employees responsibility to train for possible job openings from employers too cheap to cover the costs?

    Of they need the work done, they have to either provide the training or better pay. If better pay doesn't work, then they have to provide training as the market has spoken.

    Funny how the market is only working when it screws employees, otherwise it's a serious problem.

    • (Score: 3, Interesting) by Grishnakh on Friday August 25 2017, @07:03PM (2 children)

      by Grishnakh (2831) on Friday August 25 2017, @07:03PM (#559069)

      The other factor is location. I see a lot of job ads from companies in out-of-the way places like Indianapolis, Erie PA, Wisconsin, etc. You can get locals to work in places like that, but it's hard to entice people to move from out-of-state for a job in places like that which requires significant skills and experience. Not only is the location not terribly attractive to most people, but there's a huge danger that the job won't work out, and now you're stuck there or have to pay large moving expenses out-of-pocket to go someplace else for another job (and don't forget the cost of breaking your lease).

      This isn't such a problem if you offer a signing bonus and relocation reimbursement or bonus, like they used to do during the dot-com boom, since some candidates would be happy to try a different location esp. when the housing cost is lower and it's not as crowded as the urban centers, but these days it's hard to find companies offering this stuff, so they sit around wondering why they can't get anyone to interview for their job in BFE. They probably don't even want to pay to fly them there for an interview.

      • (Score: 1, Insightful) by Anonymous Coward on Saturday August 26 2017, @12:04AM

        by Anonymous Coward on Saturday August 26 2017, @12:04AM (#559170)

        Hell I applied at many places like that. Met 99% of their qualifications. Out of 100 or so maybe 10 called back. They are setting themselves up to hire H1B. They don't 'say' it but it is pretty obvious. I am not stupid. But why did they waste my time...

        I would even pay out of pocket to move. Its actually semi cheap to move if you box it up yourself which is not that hard.

        They probably don't even want to pay to fly them there for an interview.
        They do not even call you. I saw one that was some obscure variant of BASIC for a particular machine in the middle of nowhere. They wanted local candidates only. Yeah good luck with that.

      • (Score: 0) by Anonymous Coward on Saturday August 26 2017, @04:53PM

        by Anonymous Coward on Saturday August 26 2017, @04:53PM (#559494)

        Suppose you move from NYC to Melbourne, FL. You take a job at Raytheon, Northrop Grumman, Lockheed Martin, Thales, DRS, Harris, or one of the many cybersecurity start-ups. (nerdy defense contractor work)

        Half a year later, you realize that you hate your boss. Somehow, you also manage to get rejected by all the other local companies. You move back to NYC.

        You probably come out ahead based on cost of living. Just the taxes alone might do that. Just the rent alone might do that. Put those together though, along with all the other price differences, and you'll easily cover the moving expenses.

    • (Score: 2) by VLM on Saturday August 26 2017, @01:29PM

      by VLM (445) on Saturday August 26 2017, @01:29PM (#559425)

      The meta observation is they pretend to want an employee relationship involving long tenure, playing the pyramid game of promotions, training, but when the rubber meets the road, they really want short term pre-trained contractors.

      The solution seems obvious... fix the regulation thats confusing the marketplace at the high end, and at the low end, if want short term contractors, become a contractor.

  • (Score: 1, Interesting) by Anonymous Coward on Friday August 25 2017, @08:42PM

    by Anonymous Coward on Friday August 25 2017, @08:42PM (#559107)

    but it's not terrible helpful otherwise because of the large amount of training required to bring them up to speed.

    When was the last time you saw an ad for a retail job that required three years of experience operating a specific brand of cash register? Never, because they train you up. It seems that only the tech industry expects not to have to train people.

  • (Score: 1) by tftp on Saturday August 26 2017, @01:29AM (2 children)

    by tftp (806) on Saturday August 26 2017, @01:29AM (#559214) Homepage

    My personal anecdote is that we were searching like crazy and couldn't find any contractor who'd be able to take an existing Android project and make changes in it. It's not even a difficult project - mostly USB and OpenGL, with some JNI thrown in. The candidates struggled for weeks to even comprehend who calls who. They were asked to add some gestures using an existing gesture processor class to resize some parameters... FAIL. We tried Indians, we tried Americans - no difference. The project is on hold for lack of smart people.

    • (Score: 3, Informative) by PocketSizeSUn on Saturday August 26 2017, @04:46AM (1 child)

      by PocketSizeSUn (5340) on Saturday August 26 2017, @04:46AM (#559291)

      Usually when I see jobs like you describe come up there are short term low budget deals.
      The experience need for USB, OpenGL and JNI are each crossing boundaries that inexperienced people will have never touched.
      JNI: Means you have to know Java and C well enough to understand the bridging API and it's caveats. It's not hard, but for people who were only taught 'Java' it is a non-starter.
      OpenGL: Yet another sub-language in and of itself with several sub-variants (The original OpenGL 1 is a completely different beast from 2.0 in a lot of ways the difference from 2.0 to OpenGL ES is relatively minor. And to do anything non-trivial you almost always need to be aware of vendor specific crap.
      USB: Another wide open mess, again, if you have not done it then it's a real non-starter ... what do you need to talk to and what API exists to get there?

      So I'm not at all surprised you are having trouble finding someone.

      • (Score: 1) by tftp on Saturday August 26 2017, @08:02PM

        by tftp (806) on Saturday August 26 2017, @08:02PM (#559562) Homepage

        If it interests anyone, the project was supposed to be a GUI monitor for an industrial hardware. The machine produces some data for graphs and charts and streams it through the USB (slowly enough) into the Android device. Here is where JNI comes in - the API for the hardware is written in C and is portable. The USB stack, though, is native - LibUSB required root last time I checked, and that is a big inconvenience. Anyway, there is nothing to hack there - this part works.

        The OpenGL ES handles the 2D charts [ntu.edu.sg]. They need to be updated fast enough without reliance upon the CPU, so OpenGL is very good choice here. The projection matrix is already configured and works. The GPU renderer is programmed and works. Lots of other code exists to handle the gestures, annotations (OpenGL is weak on text,) the reticle grid, and many more. There is nothing left to invent from scratch - we always do that first. What needs to be done is just the usual maintenance - add this button here, this little function there, improve the scrolling, update the API to the latest, etc.

        I was amazed primarily with general ineptness of the candidates. I can understand if they don't quite grok the layout of the arrays of vertices, for example - I can explain that and it won't take long, OpenGL has only ten primitives [khronos.org]. But what happened is that they look at the code and fail to comprehend what they see. That cannot be explained, unless I read them the book "Android for dummies" for a year. I got a feeling that they ran the IDE before and, possibly, compiled the stock "Hello, World!" app - but had done not much more than that. Candidates came with excellent self-written resumes, but these writings appeared to be just a waste of electrons.

        We were not looking for the cheapest coders - and, in fact, these candidates were expensive, for the month that they were given to get started. This project had sufficient funding. I can suspect that Google and Apple, our neighbors, vacuumed up everyone who can [successfuly pretend to know how to] code for Android, and the rest, who know what they are doing, turned into one-man shops that sell inexpensive apps. The "free electrons" - those contractors - appear to be those who cannot get hired by the big guys and who cannot hang their own shingle. No surprise that they cannot handle a relatively simple task, even though the task is linked against a few specialized libraries. Their problem was not in specialized stuff, but in basics - one of the candidates, for the life of him, could not comprehend how the screen coordinates are translated into the world coordinates - and the code has a set of convenient classes exactly for doing that! They failed miserably - not because they had a wrong color of skin or a wrong accent (they were from different places, including locals) but simply because they are incapable of doing the work.