Most office job coding work these days is filling out templated layers of indirection via frameworks and APIs.
Google doesn’t have an information advantage. It has a capital advantage. It’s the same old math belying all those algorithms.
They’re trying to sell the idea they possess an information advantage over less developed nations as Americans/westerners don’t buy their story anymore. They’re bored and gonna charge more to fill in the new templates of indirection.
A smart graduate from EPFL, Polytechnique or ETH Zurich who interned at CERN and has contributed to the Linux kernel for a software engineering job at a unicorn startup
A grad from a second tier "technical college" in India with a visa refusal rate of ~90% for a job doing manual UI testing and QA for a body shop
my only path forward is H1. They'll both be listed as "computer related occupations" and apply for the same visa in the same quota. Does that makes any sense to anyone?
Part of me wonders whether this is also because of their expectations for a reasonable salary/conditions. If you come from a country where wages are much lower than in the US, even a terrible wage from a tech company must seem like an amazing one.
This then makes the comparison even more stacked towards the H1 worker. Of course they'll 'work harder' for that wage, it seems like a decent one for them and (as mentioned), there's a risk of being sent back. Meanwhile any US based employee you can get for similar money will probably be far below average in terms of skills/mindset, since no one with any real expertise will work for these wages.
> this definitely creates unhealthy expectations in the labor market in general.
I have always assumed this was the goal; a way to skirt labor laws/protections and overtime normalize overworking and manager worship because American workers are "lazy".
In a similar flavor I never liked it when I worked at $BIGCO and people treated you differently if you were an employee v a contractor. It wasn't a privacy or trust-level thing - it was just social status stupidity.
No, I don’t think H-1B is abusive, it’s an opportunity for hardworking people to prove themselves just as, or more capable than the locals. I don’t think you’re truly concerned about my wellbeing, I think you’d just rather have my job.
I think that complaints of abuse are thinly veiled xenophobia. You pretend to be helping us, but you just want to protect your own overly inflated salaries from market forces.
What you think is "best for you" changes for a lot of people over time. Meanwhile, using my iphone analogy again, you are merely raising the cost of a phone for those who "just want a phone". ie, you are raising the expectations for employers who will expect more people to work for 40+ hours, while getting paid for 40.
If you are from a country with a long waiting time for a US green card, you should really look at a moving to another developed country, or marrying a local.
However, I'm not in favor of the common practice where employers make no attempt to hire a US citizen and instead hire an H1-B employee who is willing to work for peanuts.
That doesn't mean I'm a xenophobe.
Yes, 80% of the recent grads we interview are unhirable. By unhirable I mean can't answer things like:
-how to reverse a string
-how to remove an element from a linked list
-time complexity of hashsets vs linear searching.
But we do have applicants who do those things (the other 20%). And we have plenty of them. So many that we end up filtering many out for other reasons.
These prestigious companies try to put out an aura that they only hire the top 1%, but then claim there's a skill gap... Seems contradictory to me.
Google has a culture that reportedly claims that they would rather not hire 10 good candidates than hire 1 bad one... So how can you claim there is a skill gap when you're rejecting so many qualified people who almost passed your test?
This is what sucks about software, you can have many years of experience and fail a question about a linked list, if you have not utilized it in a while. I solve business problems, read documentation that is my age to work with legacy systems, etc. I keep up to date with the web dev area I'm working in but this is much different than college data structure and algo knowledge.
And that's OK, but in order for companies to make progress, they use questions like these to make sure they are hiring people that are knowledgeable and capable of solving certain kinds of problems. The other thing is, people that can answer these simpler kinds of programming problems correct are more likely to write clean code, make better decisions, and be an asset to a team. It is just an easy way to weed out bad candidates. That doesn't mean all candidates who can't answer the question are bad, but likely that all bad candidates cannot answer the question; there's a big distinction there.
Unfortunately a lot of people with good experience get left behind. But the other problem is just because somebody has good experience doesn't mean they are the right fit for the position. And that's just life.
I think the point of these questions for entry level devs is that they should be able to figure out how to remove an element from a linked list even if they have never used one. It's pretty trivial if you think about it and have some basic understanding of objects and references.
Also these types of questions are not usually asked for experienced devs.
Not disagreeing with you but I see the opposite problem. People who trust hashsets way more than they reasonably should. You need to reach economies of scale before they make sense. A lot of performance is lost building these expensive structures.
FizzBuzz became a thing for a reason. Would you consider FizzBuzz leetcode? Would you consider a 5 minute discussion about how a linked list works leetcode, or whiteboarding pseudocode for a node structure and Add/Remove methods? (and for what it's worth, I almost never find a need to go even that far)
Parlay that 5 min theoretical discussion into 10 minutes of conversational discussion on application in practice and for anything less than a lead position I already know if you're "qualified" to be a potential hire or not.
I work at a small company with very low turnover so it's not like I've hired bunches of people, but in 10 years I've never hired a bad developer. Doubt I've passed on many good ones, either, though they might get passed on for other reasons.
How would you even know? Do you do any follow up with candidates you rejected?
There is a skill's gap, but it's not the skill's gap that the article thinks it is. This article confuses different things. This article incorrectly equates computer science graduates as people able to fill open positions at tech companies in IT positions.
For example, when I graduated college, I had an academic background in Java. So when I graduated, I started looking for Java developer positions. To my surprise, in the job market at that time, there were about 30 senior level positions per entry level position that companies were hiring for.
At that time I would have said the skills gap was that people wanted senior level engineers but weren't wiling to train their mid levels and hire entry level or junior engineers to back-fill internally promoted employees. And of course my academic work did not include enterprise java stuff either. Or more succinctly, there gap was between what experience level was available in the market vs what experience level companies wanted.
Now later in my career, as a .Net developer, the skills gap I see is a different one.
I see a skills gap between academic computer science and what actual software engineers use. And not just the programming languages people use more commonly in the industry like C++ vs C# etc.
Never in my college was there any Full-Stack development approach to anything. Everything was done in isolation. Here's a few courses how front-end web development works. Here's a few courses how a back-end language works. Here's a few courses on how a database works. Never in academia did we put it all together. And let's not talk about useful discreet math turned out to be.
Bottom line is neither academia nor companies that hire you seem very willing to train you in real-world skills. Universities would prefer to maintain academic purity and hiring companies would prefer someone who already knows whatever language or frameworks or development approach they are already using.
So I wouldn't say the skill gap is non-existent like the article suggests. And I wouldn't say that more computer science graduates would fix the skill gap. I also wouldn't say more H1B visas would provide a permanent solution for the skill gap. None of these address the underlying problem. Something else needs to happen to fix this kind of skill gap.
I'm updating this to reflect something I agree with in other comments. There is also is a gap in practical coding skills.
Imo there are a lot of overlapping problems, but none of them are a conspiracy alluded to by the title. A big one is that companies are bad at segmenting work between engineers and technicians (or whatever term you want to apply there) and if they don't make the distinction they'll have the same hiring requirements, or worse - treat the segmentation as a division of seniority and not skill set.
I'd like to see us start investing more in associates degrees for CS and value the graduates like we do other tradesmen.
That said, sometimes they're basic skills. In one job a few back, I did a lot of resume-reading and phone screening. I used basic questions. A solid 50% of screenees failed FizzBuzz.
Now, it's absolutely possible that many of these were just nerves. Not everyone handled interview tension well! But it strains credulity for me to accept that being nervous makes half of software engineers forget how to do a loop, conditional, and modulo.
That said, it continues to strain credulity that 50% of interviewees for engineering jobs suffer from forgetting the most fundamental of tools in the face of an interview.
So I am led inescapably to the conclusion that there are indeed many people out there who only have skills on paper.
that in 50% of interviews for engineering jobs, the interviewees...
Fixed to be more precise.
Which is more improbable, that programmers who tend to be socially awkward and work alone in front of a computer and are not stage performers get "stage fright" during interviews, or that people with many years of experience getting paid as a programmer can't do anything? To me, the latter strains credulity.
And when you're told that your career rests on how perfectly you do in this interview and that any deviations from perfection will make you fail, is it any wonder people get anxious?
I once almost failed the most common leetcode easy problem because my mind blanked and I implemented the wrong solution at first. Interviewer probably labeled me as someone with fake credentials as I didn't have time for their second problem as a result.
I was part of the hiring process durring a period of rapid growth. I noticed that difficulties in hiring had more to do with our own ineptitude in hiring people rather than short comings of the candidates. Simply put: engineers suck at interviewing other engineers. Often times, engineers would ask unreasonable questions or questions that had nothing to do with the job, etc. And it's not just engineers, even engineering managers and engineering leads often don't know what they're doing in interviewing until they get some experience with it. And even then, some of them insist on passing on highly talented people just so they can build up their own ego.
My advice to any company who thinks there's a "skills gap" is take a look at those so called skills and make sure you're asking the right questions. For each tech question you ask, first ask yourself whether that skill/knowledge is used on the job, if so it's a fair question. It's amazing to me how many times engineers will pass on candidates who have over 5-10 years of experience doing essentially the job for which their applying for, just because they don't remember some esoteric thing like linked lists which has little to do with modern software engineering, etc.
Of course if they struggled with that one, there was likely no way the would get the question where we asked them to write a function that takes an integer and return an integer that is the result of each of it's digits being squared.
Honestly this one is really to help us look at a person's thought process because there are multiple approaches to solve it. Usually people either go some variation of math route or a string manipulation route.
Examples of Programming Riddles I have seen first hand:
How to invert a binary tree.
Implement a binary search algorithm.
Design an app that generates all possible phone numbers that a knight chess piece could create by moving across the dial-pad.
Those are riddles. This is not.
In real work there is a whiteboard, but everyone in the room is part of the discussion. You're set in the context of the work being done. You are aware of the end goals. You look up things on the internet. You experiment and write tiny programs at a repl. You think about the work being done both actively and while sleeping subconsciously maybe even during your commute. You have conversations with coworkers - stress free. When people say "it took me only 15 minutes to solve this at work" they forget the prior 2 years of context setting.
Your question is on par with a math problem. If they don't immediately think about string manipulation. I would rather see a candidate walk through some of their code on Github as better example of their skillset or having a candidate do a PR review over existing code shows much more insight. Reading code is harder than writing code, especially without context. Both activities highlight communication.
One of the best interviews I ever had was doing pair programming on a real computer. The interviewer was driving (removing typing gitters, editor issues) TDD style. Write a test. How do we get that test to pass? Is there a chance to refactor? Everything that appeared on that screen had to be communicated. That was by far the most fun I've ever had in an interview.
We've done some of the same pairing type activities during our interviews. And I could tell within 2 minutes if the person was used to pairing. When a negative review would come back a lot of the time it was because "their communication could be better". Vibe is a thing and pairing is a skill.
At the end of the day interviewing is about playing games and the employer makes the rules.
[(d%10**(n+1) - d%10**n) / 10**n for n in reversed(xrange(int(log10(d)+1)))]
Technically, you need to do
from math import log10
[ [(d%10**(n+1) - d%10**n) / 10**n for n in reversed(xrange(int(log10(d)+1)))] for log10 in [__import__("math", fromlist=["log10"]).log10]]
Just to carry this a little further, if we interpret "a new integer that's the result of each of the original integer's digits squared" as doing something like this:
129 -> 1481
int(''.join([str(x**2) for x in [(d%10**(n+1) - d%10**n) / 10**n for n in reversed(xrange(int(log10(d)+1)))]]))
For example, take 999 (N). Using only math, how can I determine the value of each digit?
(be sure to take abs(N) and record value of N/abs(N) for later)
res = N - (N - 1). Digit = res + 1; If Digit == 10, Digit = 0.
So, given that function to find each digit, you can build a loop using 10^i to detect each digit (subtracting the sum of all preceding digits and dividing by 10^i to trim the lower order digits you've already resolved).
We'll need a place to store each digit, such as an array.
Of course, this assumes integers in base 10. If they are another base (8, 16), replace the 10^i above with the base.
It's also ambiguous as to if the function should just return a concatenated version of the results or some possibly a sum.
In any case, using a cast to string would be way easier.
I've also seen incrementing an exponent. And I hear from more math oriented people that there are other ways.
FAANGS strongly compete for software engineer talent and if one of them (ex company X) would start offering lower salaries the others would likely poach as many employees as they can from company X.
I do suspect though that outside of competitive technology driven companies like FAANGS there is plenty of companies that indeed don't care much about technology and innovation and just want to cut the budget. This is especially true for consulting.
The USA will loose its edge with the loss of the influx of young talented skilled professionals.
Many jobs require an IQ > 1SD above the mean. This means there are about 16% of pop (if I recall my stats correct) who could possibly do the job, and everyone else could not even if we gave them a free education on the job training or any other benefit.
I believe STEM+Medical as a whole is suffering from this issue. One benefit is low/nocode solutions are pushing some of these challenges into the mainstream audiences.
I've seen it clearly in both directions from me - code I've written that I could easily pick out 10 peers I've worked with and be certain that they would not be able to solve the problem within the constraints, period - and I've also seen work others have done and be certain that I could not have independently done similar, certainly not within any span of time that's worth considering.
I've also seen companies crumble and fail from only having "average" developers where no one could tackle the difficult problems that inevitably come up.
Or alternatively, why hire a local when you can get someone with a master's degree for the same price?
News reporters seem not to be very good about following up on that detail, and the person will usually not volunteer or wish to draw attention to the $ they want to pay. Because they want cheap labor.
Now, the price at which you believe the market should be allowed to settle at before resorting to foreign talent/immigration is for companies to weigh in on, and Congress / policy makers to decide.
But maybe that process is broken at the moment, so we resort to simplistic 1 line summaries to get what party <x> wants. And aside from any of that, educating more people in what we want supply of is a good choice, any time.