Live data from Hacker News

Today’s Top Tech Skills

hiringlab.org

211–220 of 373 posts

Re: Today’s Top Tech Skills

#211
post #5

What about most compensated tech skill. Highly doubt SQL and Java rank highly there.

Matters what you're using the language for more than which language is being used I would imagine.

Scala users make more than .NET users, but that isn't because Scala is more in-demand, it's because that's the language of choice for a lot of Machine Learning / Big Data folks using spark who are highly sought after. I would bet that average Scala and Java compensation is very different, with Scala being much higher, due to the Java average compensations getting watered down by salaries of Java developers that just make CRUD applications but at the top of the scale they're likely similar and they both map back to Spark developers that are Machine Learning / Data Scientist / Big Data engineers.

Same with SQL- in general it isn't highly compensated because "everyone" knows/uses SQL (rarely well, though)- however there are also tons of Data Engineers whose core competency is SQL and they make great money.

Re: Today’s Top Tech Skills

#212

Earlier quoted context omitted.

What would you say is the special thing about this particular bit of knowledge that made you point it out? To be perfectly honest, it seems quite arbitrary to me. I could say I'm surprised to see how many people don't know anything about the browser rendering pipeline and consequently produce badly performing interfaces. Someone else would complain about people's inability to do even the most basic Linux administrati…

>> many people don't know anything about the browser rendering pipeline if you can recommend a good source for learning the browser rendering pipeline please post it here, everyone I have asked just shrugs it off and says that no one really knows.

I'd be interested in other resources for this too. The best I can think of is Udacity's Web Performance Optimization class[0]. It's by Ilya Grigorik, chair of the W3C Web Performance working group.

Other than that there are some older docs for the Blink engine which drives Chromium. It's much more low level and hard to follow though[1][2].

The Navigation Timing spec is good for building an understanding of the major events that go into a page loading and creating HTML elements[3]. It's not the whole picture but gives the timings for navigation and DOM element events.

[0] https://www.udacity.com/course/website-performance-optimizat...

[1] https://www.chromium.org/developers/the-rendering-critical-p...

[2] https://docs.google.com/document/d/1wYNK2q_8vQuhVSWyUHZMVPGE...

[3] https://www.w3.org/TR/navigation-timing/#processing-model

Re: Today’s Top Tech Skills

#213

Earlier quoted context omitted.

My go to interview question to test basic SQL knowledge is use of “HAVING”. It’s a surprisingly good filter. EDIT: To clarify since this got more attention than I expected...I don’t disqualify any candidate based on the answer to a single question. I just use that question to assess their actual SQL experience. If you’ve spent any amount time writing raw queries by hand for reports or just to pass through to a web se…

My experience with interviewers is that they all believe that their pet question is "a surprisingly good filter". Considering that there is rarely a data-driven approach to recruiting, usually this statement has a heavy confirmation bias. Usually when you add data to the mix, you'll find that most questions are not significantly correlated with candidate success/failure once you condition on "ability to write any cod…

Completely agree. Early in my career I had what I thought was "a suprisingly good filter" question I would ask candidates. For a couple years I did this. We hired one guy who had failed my question and then fired him a couple months later, which heavily reinforced my belief in the value of this question.

A couple years later I found the stack of resumes, some we hired, some we didn't. I realized that some of our best engineers had failed my question, and I had subsequently voted "no" (I was outvoted, fortunately, by my fellow panelists. Another reason I strongly advocate panel interviews but that's a separate discussion).

I soon realized that my question was good at filtering out people who didn't think like me, not at filtering out people who would make good engineers.

My takeaway was that everyone, especially me, could use a healthy dose of humility and self-skepticism. Not advocating swinging the pendulum into Impostor Syndrome (which I now struggle with sometimes), but somewhere in the middle is good and healthy IMHO.

Re: Today’s Top Tech Skills

#214

I've always been frustrated by the promotion of this kind of list. Yes, it matters what the demand for a given skill is but that knowledge is virtually meaningless without also having information about the supply side! If 1,000,000 companies desire talent $foo which 2,000,000 workers have, it's not going to lead to as many opportunities or as much leverage as talent $bar that 300,000 companies desire but only 50,000…

There's also a question of skill liquidity: if there's a very low supply and a low demand - even though the demand might be multiples of the supply - it puts everyone in a tough place. The employee doesn't have the leverage they might hope for because finding a compatible employer is very hard.

Re: Today’s Top Tech Skills

#215

Earlier quoted context omitted.

I believe for many years, that kind of supply/demand relative comparison typically determined that COBOL was the skill to have :) I've been on projects with COBOL (yay!:), and there's always a complete dearth of skilled people...

That would suggest that a better metric would be to look at the supply demand imbalance and also look at the growth rates for future demand. For anyone looking at this list it’s probably the places where demand is growing fastest that you want to target. From those you could split things into stuff that’s mainstream and upcoming. Mainstream would be Python, AWS and JavaScript as per this list. The fastest growing are…

> ...and also look at the growth rates for future demand.

I would say that looking at the growth rate of future demand is a poor way to go about it unless you're also looking at the growth rate of future supply, for the same reasons mentioned in my original comment.

Re: Today’s Top Tech Skills

#216
post #16

Java is still undisputed in the enterprise. Node.js was a contender but lost steam. May be .net once it becomes truly platform neutral have a chance to take on Java. Until then most probably it will remain widely popular.

I figured that was mostly due to legacy code at this point; is it undisputed for new code too?

If your systems are Java, you'll hire people who can work in Java, and if the only thing your devs have in common is experience with Java, your new code will be in Java too.

Re: Today’s Top Tech Skills

#217

Earlier quoted context omitted.

Not when you’re corrupting only a handful of sales, but losing all of them. It still feels arbitrary to say one is more important for developers to be aware of than the other here. As long as you have both covered to a reasonable degree within your company/team it’s a waste of time arguing who’s got the most important info in their brains.

One is more important because presumably one is harder and thus more expensive to recover from. Typically the deeper the rot in the foundation, the more expensive the repair.

A data corruption might be also impossible to recover from. You could even only notice it after months of it happening, e.g. if your users spend months collecting data which is only analysed at the end of the year.

Re: Today’s Top Tech Skills

#218
post #207

Earlier quoted context omitted.

This one is quite good. I posted it to Hn 6 years or so ago but it didn’t get upvotes: https://www.html5rocks.com/en/tutorials/internals/howbrowser...

How much of it is relevant 8 years later?

Nearly all of it

Re: Today’s Top Tech Skills

#219

In the recent two or so years I was surprised to see how many people don't _really_ know about SQL. Sure they can write a simple insert and update query and maybe a join, assuming they can just ignore that there actually are different types of joins. But if you ask them about other _still fundamental_ knowledge like a _rough_ idea about what the different transaction isolation level are/mean/imply for you, they fail…

My go to interview question to test basic SQL knowledge is use of “HAVING”. It’s a surprisingly good filter. EDIT: To clarify since this got more attention than I expected...I don’t disqualify any candidate based on the answer to a single question. I just use that question to assess their actual SQL experience. If you’ve spent any amount time writing raw queries by hand for reports or just to pass through to a web se…

I’ve hand written thousands of sql queries, including a year spent writing nothing but PL/SQL stored procedures. I’d fail your test, not because I’ve never used it but because I’ve not had to use it in years and, importantly, I rely on Google to remind me of syntax trivia when moving back to a language I haven’t actively worked in in a while.

I HATE trivia questions and I’m convinced they are a sign of a lazy interviewer. If you want to test someone’s knowledge of sql, give them a sample schema, an internet connected computer and five minutes to write an appropriate sql query for your use case.

Re: Today’s Top Tech Skills

#220

Earlier quoted context omitted.

My go to interview question to test basic SQL knowledge is use of “HAVING”. It’s a surprisingly good filter. EDIT: To clarify since this got more attention than I expected...I don’t disqualify any candidate based on the answer to a single question. I just use that question to assess their actual SQL experience. If you’ve spent any amount time writing raw queries by hand for reports or just to pass through to a web se…

My experience with interviewers is that they all believe that their pet question is "a surprisingly good filter". Considering that there is rarely a data-driven approach to recruiting, usually this statement has a heavy confirmation bias. Usually when you add data to the mix, you'll find that most questions are not significantly correlated with candidate success/failure once you condition on "ability to write any cod…

I knew a guy, a really good engineer, who used to ask people about a specific thing you would see in a log file from a particular open source server. The SQL "having" question isn't quite as bad, but neither question is good at assessing one's ability to solve problems.
Post reply on HN