Slashdot Mirror
US Law Allows Low H-1B Wages; Just Look At Apple (networkworld.com)
An anonymous reader writes: If you work at Apple's One Infinite Loop headquarters in Cupertino as a computer programmer on an H-1B visa, you can can be paid as little as $52,229. That's peanuts in Silicon Valley. Average wages for a programmer in Santa Clara County are more than $93,000 a year, according to the U.S. Bureau of Labor Statistics. However, the U.S. government will approve visa applications for Silicon Valley programmers at $52,229 -- and, in fact, did so for hundreds of potential visa holders at Apple alone. To be clear, this doesn't mean there are hundreds of programmers at Apple working for that paltry sum. Apple submitted a form to the U.S. saying it was planning on hiring 150 computer programmers beginning June 14 at this wage. But it's not doing that. Instead, this is a paperwork exercise by immigration attorneys to give an employer -- in this case, Apple -- maximum latitude with the H-1B laws. The forms-submittal process doesn't always reflect actual hiring goals or wage levels. Apple didn't want to comment for the story, but it did confirm some things. It says it hires on the basis on qualifications and that all employees -- visa holders and U.S. workers alike -- are paid equitably and it conducts internal studies to back this up. There are bonuses on top of base pay. Apple may not be paying low wages to H-1B workers, but it can pay low wages to visa workers if it wanted. This fact is at the heart of the H-1B battle.
L visas let the employer pay the foreign employee's home town wage for up to a year while in the US. When I lived in China for a couple of years I interviewed with the local IBM office about database consulting. They wanted to fly me to the US on an L visa while paying the local wage of about $1K USD which would be OK there in town but not in L.A. The hiring manager assured me on the 3rd level interview that they did it all the time and it was no problem. Then I mentioned that as a US citizen I couldn't be sent on any kind of visa and I couldn't work in the US for sub-minimum wage. He hung up and I couldn't get him to answer when I called back. Since they wanted to hire and send me immediately but an L visa requires a prior year of employment, minimum, they were obviously quite handy at lying on the paperwork. Think about this the next time big blue sends in a consultant from another country.
How about we just allow these H1B candidates to immigrate? Then they can be citizens and pay taxes on whatever salary they accept. They might even buy some foreclosed houses.
That is the most practical solution ending the problem of visa-based slavery, but I doubt the Americans will ever do it. They idolize Saudi Arabia and the UAE for their greater materialism, and wish to inculcate the same mistreatment of workers - especially "foreign" workers. That allows their politicians to wag the dog and blame the other for the systemic economic problems they fail to address.
If H-1B visas really are used to hire the best, brightest, and most rare talents - then a minimum wage of $150k/year should be no problem.
This would solve the problem instantly.
However, I suspect that instead of asking for larger H-1B visa caps, most H-1B visas would go unused.
You fuckers want free, unfettered immigration.. here you go. Perhaps these people are only doing the jobs Americans won't do. Or perhaps, they'll do the job for a lot cheaper than what American's are willing to work for. Sounds a lot like what has already happened to the farm jobs, landscaping jobs, and most of the construction and painting jobs here in the southwest. They pay so little now that you don't see a non-hispanic doing a damn one of them and most who are doing the jobs haven't bothered to even learn the language of the "customers" they are serving; except perhaps the foreman. Interesting that "so many" Americans want open borders and non-protectionist policies until they begin to nibble at your cheese. Well, which is it.. are we an open, international nation who accepts anyone with a "dream" and a desire (or a sob story) or do we at least serve to ensure that those who were born here or spent the time and effort to become citizens or permanent residents see some sort of benefit from being such?
"but it can pay low wages to visa workers if it wanted. This fact is at the heart of the H-1B battle."
No. This battle is not just about the wages paid the H-1B workers, it is allowing allowing there to be any H-1B workers if there are US workers who could perform the task at any price or do so with reasonable training (in high tech environments new employees generally need up to 12 months to get up to full speed).
H1B workers should not be allowed in to keep current wage levels, to reduce leverage skilled employees have in the local free market, and certainly not to replace/displace local workers. H1B workers are for when local talent does not exist. Period. The same is also true of the back door using accelerated degrees from foreign nations to get student student visas for US grad schools. US schools might be willing to sell out since these students pay max tuition and US companies having programs which then pay for/reimburse the education costs might make this feasible but it isn't in the overall interest of the United States.
15 years ago, Apple hired me on an H1B, and my starting salary was $140k, then they paid everything to convert my H1B to a green card. None of this includes joining and yearly bonus stock options (at the time, RSU's these days) or yearly cash bonuses. They also paid relocation and first few months of rent in a pre-arranged location.
I'm not special. There were several dozen of us in the (weekly) new-employee orientation meeting, most of whom were s/w engineers.
Oh, and I (or rather, my small company, that Apple bought) wrote ILM's digital asset management system for films like Star Wars (ep1), James Bond films, digital commercials etc. mostly in PHP. That sold for $40k/pop... Indeed, just like any language, it's possible to write crap code in PHP, but used properly it's a powerful tool.
Physicists get Hadrons!
TL;DR: Not really.
I'm guessing that's more of an "asset management system". Ours was orientated around the video. As cameras roll, we digitised the footage by tapping into the tape deck monitor output, we had RFID tags on each tape, and we had LTC/VITC timecode from the deck. We therefore had a unique reference for every frame laid down, as it was laid down (ie: there was zero ingest time, which was - and still is to a large extent - an issue with asset management systems).
The system then sent each frame to a centralised database server that had a webserver on it, and I wrote a streaming (ok, this part was in C :) server and a streaming player for Linux, Mac, and Windows that understood our custom streaming format. There wasn't anything complicated about the format, it was basically motion-JPEG data served from an HTTP interface, so the player would send the URL "http://asset-server/tape-rdid/timecode-from/timecode-to" and get an application/octet-stream back which was each file (common headers stripped), where a file was an individual frame in JPEG form.
What this let people do was record out in the desert, and have their digital dailies sent back via a satellite upload to home base via rsync, and the team at home base could "see" (we only supported quarter-res images at the time, the internet wasn't as fast as it is now) the footage, reliably locate frames on tapes, and discuss/annotate/create EDL (edit display-list, basically a set of timecode-timecode ranges) sequences and play around with it as if they had the tapes right there, even if it was at a low resolution.
On a more prosaic all-in-house system, the act of using a Discreet Inferno or Flame system (which controlled the tape decks in a post-production suite) would automatically log footage into our system, so the non-artist types could use our "virtual VTR" system to review and create play-lists which could then be sent to the machine room with the certainty that what they'd composed in their web-browser would be what ended up on the tape that would later be delivered to clients. This freed up a lot of the tape-deck use which could then be put to more profitable use by the post-house.
There was at least one time when I got a angry phone call from a client who claimed our system was screwing things up. They'd created their EDL for the client using our system and then sent the job to the tape room to be generated, and of course creating that new tape would automatically log the new footage into the system (because it was writing to a tape in a monitored tape deck). They looked at the output footage of the generated tape in their browser, and it wasn't right. After a bit of tracking things down, it turned out the tape room had inserted the wrong master tape, so we saved them the indignity/embarrassment of sending footage from a *competing* client out the door. That alone, in the eyes of the director, was worth the cost of the system.
We had similar procedures for rendered footage from 3D systems (Shake etc. at the time). Again, everything was collated into shots/scenes etc. on the database server. We had rules that would be applied to directories full of frames that would parse out sequences from arbitrary filenames that were differentiated only by a frame number in the filename. That's actually harder than it looks - there is *no* standard naming convention across post-houses :) I separated out the code into a library, wrote a small commandline utility called 'seqls' which was *very* popular for parsing out a directory of 10,000 files into a string like 'shot-id.capture.1-10000.tiff' ...
All of this is (I'm sure, I haven't kept up to date) commonplace today, but it was pretty revolutionary at the time. I'd say about 90% of the code was PHP, there were various system daemons in C, there were video players for the major platforms in C/C++ and there was a kernel driver for the linux box in C that handled the incoming video, digitised the audio, and digitised the LTC
Physicists get Hadrons!