Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Today’s Top Tech Skills

hiringlab.org

Post reply on HN
Print view View original

111–120 of 373 posts

Re: Today’s Top Tech Skills

#111

Post by scarejunba »

brightball wrote: post #42
dathinab wrote: post #25

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…

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 code at all".

Re: Today’s Top Tech Skills

#112

Post by skrebbel »

_bxg1 wrote: post #47
moltar wrote: post #45

Earlier quoted context omitted.

You can say smithing like, “weird to see Linux admin, instead of OS admin”. But doesn’t make sense in a business context, if you want a Linux admin.

The difference is that Linux isn't owned by a single company. It runs on virtually every platform, including all of these hosting providers.

So if it's owned by a single company you can't list it as a skill? Huh?

Re: Today’s Top Tech Skills

#113

Post by vageli »

vsareto wrote: post #85
jackcodes wrote: post #78

Earlier quoted context omitted.

The vast majority of work on web apps is probably writing CRUD controller methods, proxies to upstream services, or React components. It’s like saying CSS transitions are vital; they aren’t, but probably affect the user experience for the average Joe just as much if not more than a phantom read. At that level of depth you just hand it over to the CSS champ or the DB champ.

>At that level of depth you just hand it over to the CSS champ or the DB champ. Developers are blaming other developers for not knowing everything they do because businesses forced them to learn everything (Fullstack), but that's actually a bad arrangement and somehow the solution is to just punish the developers more rather than hiring DBAs.

> >At that level of depth you just hand it over to the CSS champ or the DB champ.

> Developers are blaming other developers for not knowing everything they do because businesses forced them to learn everything (Fullstack), but that's actually a bad arrangement and somehow the solution is to just punish the developers more rather than hiring DBAs.

If the organization views developers as cogs or something like a software assembly line, the desire for interchangeable, unspecialized workers seems like a natural consequence.

Re: Today’s Top Tech Skills

#114

Post by dudul »

rongenre wrote: post #89

Good applications tend to get the database right first - since you can always re-write the mid-tier code relatively easily. It's pretty much essential to any developer. Further it's a ridiculous superpower if you're not a developer - it's so empowering for anyone on the business side with questions to just go look in the db.

I actually fully disagree. I find it much easier to "fake" the DB in the first stages (like just store shit in memory) where you explore and understand what your system must do, the questions it should answer with data from the DB, etc. Then, just replace your fake repo with an actual DB and you're done.

And it goes with what you're saying: changing a schema is not as easy as changing the code. So start by really understanding what you need to do, and then build the schema at the end.

Re: Today’s Top Tech Skills

#115

Post by yowlingcat »

jackcodes wrote: post #100
yowlingcat wrote: post #86

Earlier quoted context omitted.

It's not arbitrary because screwing up your data integrity is far and away one of the most painful and business critical mistakes you can make as an engineer. Your product isn't finished if it looks like it works, but is either storing data improperly at rest or doing the wrong thing with it.

I think the point to be made was that if you screw up your browser rending to the point of it being unusable on old devices, that could be just as business critical as the data integrity issue. Making either of those your line in the sand for what a developer should and shouldn’t know is arbitrary. I don’t know a ‘Scala’ full-stack developer that could do advanced optimisation on React render times, or a ‘React’ deve…

The difference is that if you screw up your browser rendering, you're not messing up your data integrity at rest and creating compound technical and potential business debt. If anything in the critical path from pricing to payments that talks to your data store makes a mistake, you can risk anything from not recording your transactions properly to charging the wrong amount or not enough at all.

It's very expensive to acquire customers. It gets even more expensive when you have dirty data from incomplete domain modeling.

Re: Today’s Top Tech Skills

#116

Post by jackschultz »

dathinab wrote: post #25

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…

Tons of replies to your comment already, but for point #1, this was absolutely the case for me. ActiveRecord is incredibly, incredibly good for pretty much all basic use cases. However, it comes with drawbacks like you said. It took me too long to realize I was behind on knowing sql to get to the next level.

To the point where I'm working today to fix slowness in a client's app where it relies way too heavily on the ORM and plain ruby code instead of going more in depth with sql.

Knowing sql more in further depth is the number one skill I'd want to tell backend devs to learn.

Also, I'm mainly a python guy, and if we're talking about ORMs, I will say that SQLAlchemy doesn't live up to ActiveRecord, to the point where I built my own db connection code for queries in some of the other flask / general python apps I'm working on.

Re: Today’s Top Tech Skills

#117

Post by Redoubts »

pm90 wrote: post #11
ravenstine wrote: post #3

I don't really understand the desire for skills to be in high demand. Obviously, you want your skills to be in demand in some capacity . But putting so much emphasis on whether some tech skill is a winner on a scoreboard can give people the wrong impression about other languages and technologies that appear to either be unpopular or dying. It's reassuring that Java and SQL are still in high demand after all these yea…

This sounds horrible but maybe the people who would take these lists seriously are precisely the kinds of people who are careerist programmers. And they really just want the maximum value from their “investment” in learning programming. In college I didn’t learn Java at all because it didn’t seem very fun. Python did and I learned that. Then Go came along which was easy to pick up. But once you know a general purpose…

Ok, well what if you picked up VBasic and Pascal instead of python and go? I would say your choices are particularly convenient.

Re: Today’s Top Tech Skills

#118

Post by kradroy »

rockinghigh wrote: post #70
brightball wrote: post #42

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…

How would you know it’s a good filter? What position are you interviewing for?

It's about as good a filter as asking a candidate what a "gyascutus" is.

Re: Today’s Top Tech Skills

#119

Post by NikolaNovak »

Aperocky wrote: post #105
dathinab wrote: post #25

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…

TBF, sql queries is something you _don't_ want to have in your code stack. It should be abstracted away in some kind of DAO, and no one should be worrying about SQL queries when they're developing new features.

Fascinating statement which I feel is probably agreed upon by many. I can see how that can be true; but once again,I feel, demonstrates that HN has a specific subset of "developers"/"techies"/"enthusiasts".

In any "Enterprise" environment I've ever been in - core back-office enterprise resource planning apps or similar - SQL is right there front and center. "Should" it be? I don't know, I'm not a theoretician; but all developers around me for 20 years have had near-DBA level of SQL skills. Their core skills really are a) Understanding business requirements and b) Understanding SQL. For any complex business requirement, by time, we find in transactions code takes 1-10% and database activity takes 90%. So skillset in optimizing database performance of your code vastly outbenefits the skillset of optimizing your code. As much as possible, we push everything to database - queries, looping, even business logic if we can - because it's a robust, mature, optimized product and we don't have to invent optimizations from scratch...

Edit: If it may prove illuminating, even team leads & management on any of the 30+ projects I've been on, understands runstats, index reorg, transaction isolation, database maintenance basics, and a few basic optimizer dos and don'ts. They just wouldn't be able to survive without that knowledge - it's 90%+ of both good stuff we develop, and bad stuff that goes Bang in the night (e.g. a process which worked for 10 minutes for 2 years but suddenly decided to asymptotically explode and not finish before heat-death of the universe :P)

Re: Today’s Top Tech Skills

#120

Post by VectorLock »

StriverGuy wrote: post #43
dathinab wrote: post #25

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…

Regarding your 2nd point: commercial grade NoSQL db's can do all of these things now. I think the notion that they cannot is from the v1-2 era of Mongo about 7 years ago. You should read the Dynamo white paper and subsequent documentation on write consistency, transactions etc. and also look at the feature set available on Mongo V4.2.

We all still get a good laugh at the "MongoDB is webscale" video.
Post reply on HN