It's not "mediocre." I defy you to walk into a store and actually play around with a WP7 device, to get some real experience with it, rather than just living in the Slashdot echo chamber. Yeah yeah, I expect cracks about "I can't even find them." But seriously -- judge the product on its merits. The interface is actually pretty damn good.

There are two problems with Windows Phone. 1) The apps market is tiny, compared to iPhone. 2) The poor perception / reputation. But the product *itself* is pretty good. I use a WP7.5 device (Samsung Focus), and I'm very happy with it. Disclaimer: I am a Microsoft employee. However, I have a choice, and I choose Windows Phone. And I plan on buying a Lumia 920 when they're out.

https://careers.microsoft.com/jobdetails.aspx?ss=&pg=0&so=&rw=7&jid=89023&jlang=EN
https://careers.microsoft.com/jobdetails.aspx?ss=&pg=0&so=&rw=8&jid=86473&jlang=EN
https://careers.microsoft.com/jobdetails.aspx?ss=&pg=0&so=&rw=5&jid=77083&jlang=EN
https://careers.microsoft.com/jobdetails.aspx?ss=&pg=0&so=&rw=3&jid=85919&jlang=EN

Some of those positions are more specialized than others. For example, for working on compiler technology, there is a requirement for deep experience in compilers. The others are more flexible.

I'm glad your experience has been a positive one.

> But, in general, the potential for such abuse is inherent in the system, and there has been plenty of evidence of other companies abusing it that way.

Agreed. Personally, if I had control over things, I would eliminate all H1B limits, and allow American companies to hire as many immigrants as they wanted, while requiring these companies to pay up for INS fees and domestic training and education. Skilled immigrants increase the competitiveness of American companies, and they often become naturalized citizens, anyway. I would drop the requirement that the visa terminate, as well. I'm more than happy to have skilled immigrants come to America, permanently, as full citizens with all rights. The more the merrier.

I completely agree. And that's what my team does. We hire bright people who are willing to learn. Existing knowledge about a specialized field is a benefit, but it's not the most important thing.

Sometimes specialized knowledge is a requirement, but that's the exception, not the rule.

> But you won't be hearing from me. No degree, you see. I need not apply as I'm not "qualified."

I interview candidates that don't have degrees. *I* don't have a degree, and Microsoft has hired me, trained me, and promoted me. It's not a barrier.

If you actually read what I wrote, I never said a degree was required. Degree programs are the most common path, but hardly the only path.

Trust me, I'm all too aware of the reputation Microsoft has, and I'm sure that's part of the problem. I spend a lot of time fighting the poor perception of the company. Some of it is earned, some of it is outdated, and some of it is undeserved.

We offer plenty of money. As I said elsewhere in this thread, the problem I see is the poor quality of candidates. Generally, if my group offers someone a position, they usually accept it. The specific work we are doing is quite compelling.

Oh, also, we usually have anywhere from 3 to 5 interns rotating through, and their ages are usually early 20s. Many of our interns like the position so much they come back for another internship, or they join us full-time after they finish their degree. Note that I'm talking about my particular group -- I'm not talking about the entire company.

Thanks for the laughs. I haven't read such a bizarre thing since Time Cube Guy.

So you worked at one group, for a year. I've worked in four different groups, for over fifteen years. I don't dispute your own experience, but generalizing to the entire company is irrational.

Yes, the programs suck. Or to be a little more precise about it, the CS programs are a confusing mixture of things. When you graduate, what are your goals? Do you want to be technology-focused, in the sense that you're involved in machine architecture? For example, working on parallel processing, power efficiency, networking protocols, etc. Or do you want to work at a higher level, where you are mainly applying existing technology to solving real-world problems (business, society, etc.)? These are both worthy pursuits, but many CS programs confuse the two.

I mainly look for CS students who also have a strong EE background. Someone who has been through a VLSI design course is very often a much better programmer (for my particular workplace) than someone who has spent a lot of time working on web sites.

Also, performance analysis is *always* a great way to learn more. Start with any good profiler, and let the data tell you where to go. You'll be amazed what you find. It really doesn't matter that much what particular profiler you use. The important part is to focus on measurement, rather than guessing. The real performance problems are rarely where you think they are. For example, in a lot of programs, basic string manipulation is often the bottleneck. It's tempting to think you can guess where the perf problems are, but after doing perf analysis for many years, I can't exaggerate how humbling perf work is. Even the most experienced engineers rarely guess correctly. To become a great engineer, simply accept some humility -- you don't know, until you measure. Measure, measure, measure. I like to think of this as the difference between "programming" and "engineering". You're not doing engineering until you're guiding your work based on measurement.

1. Willingness to work at any level required in a system. All the way from high-level languages and environments (HTML/JS, UI toolkits, SQL) down through middle-level languages (Java, C#, C/C++), down through assembly language (understanding machine architecture, compilers, assembly-level debugging). You don't have to *start* with those skills, but you need to be willing to *learn* them and be comfortable working at any level.

2. Willingness to learn any new problem. We usually look at your background, and ask you one programming question that is solidly in your "comfort zone," and then ask programming questions that are outside your comfort zone. The first question is designed to see how much you can talk about something that is comfortable and familiar to you (and also frankly to make you feel comfortable -- after all, hiring is *not* adversarial for us, we're trying to see if you can work with us to solve problems). Can you explain a solution well? Can you teach something to someone else? The programming problems that are outside of your comfort zone are all about seeing whether you are able and willing to apply yourself to something new. For example, if your background is in networking, I might ask you a graphics programming problem. Or vice-versa. The goal is not to be a jerk, the goal is to see whether you can apply yourself to something new.

3. Ability to identify the problem, its exceptional cases ("corner cases"), and to identify engineering trade-offs (memory vs. speed, etc.). Just being able to identify what an interviewer is asking, in a programming problem, is an important skill. Very often, candidates will focus on the wrong aspect of a problem. Or they will rush into a problem without understanding it, and will miss the forest for the trees. This is a really basic skill that anyone can develop, and it helps in all job interviews (and in all real-world problem-solving situations).

4. Ability to choose the right tool for the job. If I ask you a question about vector programming for high-performance graphics rendering and you start answering in JavaScript, you've already failed. Conversely, if I ask you to solve a database problem such as "How would you store and search the data for a geo mapping web site?" and you start answering by focusing on low-level concerns like STL templates vs. linked lists, then you obviously are not focused on the core of the problem, which is how to structure the data on disk and how to organize it for efficient queries. (I've had candidates do both of these things.)

5. Ability to communicate your thought processes. If you're working on a programming problem during an interview, then at least half of the interview is about *how* you approach (and maybe solve) a problem. Are you breaking a complex problem into smaller problems? (divide and conquer) Are you making something more complex than it actually needs to be? Can you identify an algorithm that you don't understand, but you understand how to use it? For example, I don't think I could invent the fast Fourier transform, but I think I could identify when to use it, during an interview. If I say to an interviewer, "Here is where I would convert this data from the time domain to the frequency domain, using an FFT library, and then I would use the frequency domain data in such-and-such a way to solve this problem," then that's good. You don't need to invent the FFT in order to apply it.

Unfortunately I'm not allowed to give any info on pay ranges. (I could be fired for doing so.) I will say this, though. The salary is decent, but not overwhelming (as tech jobs go), because the bonuses are huge. The bonuses and stock are where the real money comes from. If you perform well, your bonus could be as much as one third of your base salary. Your stock grant could be worth as much as your entire yearly salary. It's structured so that you are compensated for performance, rather than seniority.

Now, someone is going to attack me for saying that. "OMG, you're paying people to attack each other!!1!1!!" Well, would you rather reward people for seniority, or for results? Also, keep in mind that rewards are spent on successful *teams*, not just successful individuals. Yes, high-performing individuals get more rewards than their under-performing peers. But, all of that comes out of a team's budget for rewards. If your team blows it, then even the high-performing people will get crap reviews. Conversely, if your team nails it, even the middle-of-the-road performers will get a pretty fat review.

The age distribution in my team is probably something close to this: Ages 25-30: 5, 30-35: 20, 35-40: 30, 40-45: 35, 45-50: 18, 50-60: 4.

So, pretty close to a Gaussian distribution. I'd say of the people I interview, one third are over 40. And they usually do better than the younger candidates.

> From my perspective, it is obvious that employers like you don't WANT good quality

I really don't understand how you managed to distort what I said into this statement. You don't know anything about my team, my hiring qualifications, etc. You're really just doing your best to attack me, without knowing anything about what we do. Your statement that we don't want good quality is simply factually wrong.

I have interviewed over a hundred people in the last few years. And let me tell you, the issue is the quality, not the price. We have *plenty* of money to offer, and we do offer it. But most of the candidates I interview simply do not meet the requirements on intelligence, skills, and problem-solving abilities.

I'm a fairly high-level architect at Microsoft. I have interviewed a metric F-load of people, many of which are international candidates. If we could hire all domestic, we would, because the paperwork is way easier. But the most important thing is, the actual salary that we pay people (and all the paperwork and such) actually rarely figures into the hire / no-hire decision. For us, it's all about that person's skills and what they bring to the team.

I would be very, very happy to see the cost of H1Bs go way up, in order to fund tech education. Companies WILL pay the money. And the best part about that is, it doesn't give any company a competitive advantage over any other company -- it's a level playing-field. Often when I hear companies gripe about some change in laws, I use that to judge whether the griping is legitimate or not -- does a change in law favor one company (or one kind of company) more than other? But in this case, no, it doesn't. All tech companies that need to hire will face the same labor market.

H1B is not slavery. The majority of H1B workers are young and single, usually a few years out of college. H1B gives them an opportunity to come to the states and 1) gain really valuable experience, 2) make a decent amount of money. Most of the H1B workers I meet are Indian, Chinese, or Russian. They make very good money. Good money in US terms, and *fantastic* money by the cost-of-living of where they came from. If they don't like their work conditions, they can leave. Just like any other job on the planet. If they do, they still made a ton of money, and still have a gig with American Mega-Awesome Corp or whatever on their resume. That's hardly slavery.

I would seriously love to see more American candidates. But where *are* they?? Most of the candidates from domestic CS programs are, frankly, very weak candidates. There are exceptions, but they are exceptions. (For example, the Brown CS program is excellent, and produces a steady stream of first-class CS students.) Most of the American candidates I interview know a little web programming, and maybe some Java, but are extremely weak on machine architecture, assembly programming, networking, performance analysis, and problem-solving abilities.