Hacker News Reader

> The result? No response. No company cared what skills I have gained during my studies. They see courses like hardware security as non-practical and a course on multithreading as mostly theoretical.

I wouldn't take that personally, or even as a strong indication of a problem with your hard skills.

Sometimes recruiters mainly look for real-world experience because that makes a hiring a candidate easier to justify. People without work experience or a portfolio are a crapshoot. Also, resume embellishment is indeed a common problem, thus great but unverifiable CVs might raise a red flag. Furthermore, if a company is looking for someone to tighten nuts but they get a CV from a highly trained engineer, they might prefer to pass on him. After all, if he's being underemployed then he might not be planning on sticking around for long.

And finally, but not less importantly, soft skills matter. Sometimes they matter far more than hard skills. A recruiter can tolerate a competent candidate that is eager to learn, but they will be less inclined to tolerate an outstanding developer who is unbearable, insufferable, or unwilling to learn from (and work with) team members.

In the end it's all a crapshoot anyway. There is a lot of confirmation bias, and a lot of lottery winners offering advise on how to win lotteries, but we would do well to acknowledge that the stars need to be aligned for good things to happen, and often they aren't.

I have a similar experience, also European. While I'm not nearly as unlucky as you are regarding job interviews and getting a job, I can attest that the majority of corps I met do not respect transferrable theoretical skills (e.g. the ability to work in any language of the same paradigm, distilling overly corporate buzzword lingo back to basic programming concepts). Instead, they would rather have someone who learned enough trivia to pass a basic test filled with code samples you'd never* see in real life, or which a compiler would quickly correct for you and teach you not to do within a week.

Additionally, they will have you stuck doing mostly low-tier work spawning from bad decisions in the past instead of biting the bullet and having someone fix the foundation, and often perceive fixing that foundation as a skill only seniors / architects possess. I've met my fair share of seniors who believe design patterns are some of the highest order knowledge, despite having to learn them during my bachelor over a longer span of time than they get taught in-house, let alone having to actually use them.

NB: this is not a jab towards seniority. But I do believe most corporates do not value educated juniors correctly, often equating them to uneducated juniors, as well as underestimating what makes a senior a senior. Basic CS fundamentals shouldn't be a skill exclusive to seniors.

Not saying this is you or GP, but I've dealt with enough juniors who just thought they're really smart and awesome but lacked any sense of what it's like to develop software for actual, normal people. They couldn't grasp that you don't just break your software for 20% of your userbase because it results in a cleaner database layout or nicer abstraction layer for something internal. "No I know what I'm doing, look I have this github project with 500 stars and none of the super techy people who use it ever complained when a new release broke something"

Yeah, no.

Usually these people come in two flavors: Those actually smart and developing an understanding for what it means to sell software and have customers with demands, and those who live in their little bubble where they're the most awesome person on the planet, and everybody else is just retarded. Halting all development for a year and refactoring everything according to what they think would be way superior after spending 5 minutes with the codebase is obviously a sane thing to demand.

And I usually try to let them fall into this trap in a controlled manner, like when it's a relatively unimportant component/feature, or just one customer where I can more or less directly relay the expected complaints to the junior dev. Usually playing the "this guy is responsible for your paycheck" card makes something click after a while.

>Halting all development for a year and refactoring everything according to what they think would be way superior after spending 5 minutes with the codebase is obviously a sane thing to demand.

Sure, but this only paints one extreme. It's fair to expect adults to realize money has to come from somewhere, and halting any development and even bugfixes won't keep customers. On the other extreme, we have sales and management pushing insane demands, which get tacked onto already poor code, degrading further, causing bugs in the future, increasing the risk factor, on top of already taking more than 5x as long as it reasonably should with no difference in features whatsoever. Which further escalates into high turnover rates, worse code quality, dissatisfied employees, no seniority willing to come in unless they get paid big time, and more. It's a fine line no matter how you slice it. Both extremes can run a company into giant losses or even bankruptcy.

Additionally, demands on juniors to prove a business case are often far higher than their seniors or managers, despite giving juniors less resources to do so. With such a simple mechanism in place, it is fair to assume the juniors who do go through the trouble of speaking up care about the quality of the product and their responsibility in the matter. Likewise, I've seen plenty of seniors fall into the same trap you described, either halting all progress or spending (read: wasting) months developing a strategy out of analysis paralysis only to not even have a business case. If anything, they tend to be able to do this even easier, since they are met with much less resistance thanks to their reputation and/or authority.

My companies fired 2 PhD’s. They were super smart, understood all the leading research results etc. but had no clue how to turn theory into practice. Theory is not practice.

> This is a European perspective. I doubt that things would’ve gone this badly if I was American. My way of thinking seems to fit better there (though I could be wrong).

You are wrong, unfortunately. There's a reason for the saying: "The A students work for the B students, the C students run the business, and the D students get the buildings named after them."

A less cynical take is that in school, marketing skills (e.g. self-promotion and self-inflating) are irrelevant. In industry, they are at least on par with technical skills, and in most roles I've encountered, even more important. Look at the people you know who were fired (directly or made miserable enough to leave voluntarily): People are more likely to get fired for not understanding and exploiting social dynamics than for being poor in the technical arena.

Also, in school, they care about objective evaluation, and usually your performance is not dependent on others. At work, your work is heavily dependent on others, and almost no one tries to objectively evaluate your work (unless you're in sales or something).

But if you've done research or tried to get a recommendation letter, you know self-promotion and self-inflating also matters in academia. Especially if you go to a large public school.

> objectively evaluate your work

I suppose if you're talking about code quality et. al, yes, but you definitely do get evaluated on its impact on the business. If you are part of a successful product launch and you engineered major features (even if other people could've written those features) you get rewarded.

I wasn't referring to academic jobs, but being a student. I don't need recommendation letters to get an A or to learn.

> I suppose if you're talking about code quality et. al, yes, but you definitely do get evaluated on its impact on the business. If you are part of a successful product launch and you engineered major features (even if other people could've written those features) you get rewarded.

A few remarks:

If you do something fairly major, then probably yes.

If you do something fairly major, there will often be people around you who will attempt (and often succeed) to take a fair amount of that credit without having contributed much. So yes, you get rewarded, but so will others who shouldn't. This is very common where I've worked. I think it's generally the case in large companies.

We should not focus on major product launches where you did major work. Say there is an existing product and most of the work is bug fixing and adding features. This category is where most of the work in industry is, and is where my comment mostly applies. This is also the category where innovation is highly touted but rarely rewarded. I've certainly been in jobs where innovation is needed, but the one who steps up to solve those problems is often the one who gets poor reviews, because everyone in the team becomes more productive because of him, and the manager sees less output from him because he spent a big chunk of his time solving infrastructure issues.

When I speak of objectively measuring performance, people often compare how it's done between jobs. This is not the point. Compare with how it's done when you were a student. In most technical courses, it's highly unlikely that someone who barely understands the material gets an A grade while simultaneously the one who understood the material well gets a B or a C. In industry, this scenario is quite common.

Would you mind sharing your blog(if you have one) I'm a student and have only recently begun to appreciate the art of meta-learning and i would be grateful to learn a thing or two from people wiser than me? thanks!

Those skills seem like a perfect fit for the video game industry, did you try there?

I am scared of that industry unfortunately. Also, The Netherlands is not a good place for it I think.