Live data from Hacker News

In-demand tech skills are the last thing to look for in IT hires

netsuite.com

91–100 of 116 posts

Re: In-demand tech skills are the last thing to look for in IT hires

#91

>Sure, in the ’80s, it might have been possible for one person to do it all: systems administration, database, coding, design. But in today’s world, database administrators, infrastructure engineers, coders, designers, project managers and others — whether on staff, on contract or with a vendor or service provider — must work together to execute projects quickly, securely and reliably. Tech today is a team sport. I f…

I want to preface my thoughts with that I wish the "team sport" mentality was more common in the dev world. Unfortunately, I have to agree with blueslurpee here. I frequently join a team and find there are 1 or 2 devs who "know everything" and it is near impossible to pull the information out of their heads and into mine or someone else. This might be isolated to the areas I work in, but I do find that the "10x engin…

>Unfortunately, I have to agree with blueslurpee here. I frequently join a team and find there are 1 or 2 devs who "know everything" and it is near impossible to pull the information out of their heads and into mine or someone else.

This is a classic defense mechanism for engineers trying to shore up their position.

There's a tug o' war going on between many companies and their employees wherein the companies are trying to make the employees expendable and the employees are trying to make themselves indispensable.

I found it mostly went away when I worked in companies where most people treated their current job as a stepping stone to the next rather than as their final destination but in companies in 2nd/3rd tier cities where everybody is married with kids and looking for stability....yea

The worst offender was a guy who was massively in debt, paid a shedload of child support, was not a great programmer and didn't interview well. He was sometimes openly hostile to my attempts to get information out of his head.

Re: In-demand tech skills are the last thing to look for in IT hires

#92
post #68

Earlier quoted context omitted.

I haven't read enough about GraphQL (or even used it) to debate its relative merits, but I find it very interesting from "business architecture" point of view. For instance, assume the future of IT looks like it does today, only ramped up x10. Imagine the majority of business value is driven disparate API's/Services managed by companies or organisations, with numerous and diverse clients that can "plug in" for their…

Ugh, no. The problems of just exposing your database really come out after you try living with it. We wanted to make schema changes on the back-end, but the front-end queries were tied to it. Those queries were in apps run by different groups, with different goals and timetables, but we couldn't break them. If we had a defined API, we could be free to modify any back-end implementation details that weren't directly e…

Who’s exposing their database? Why? You’re exposing a view over your data that may or may not live in a database.

None of your points apply directly to grapple, all apply to a REST based architecture. More so, I’d say.

Re: In-demand tech skills are the last thing to look for in IT hires

#93
post #15
post #11

Earlier quoted context omitted.

We didn't have APIs 10 years ago? I agree with the article. As we build more complex products we need to be more specialized and work together. Maybe not the case if one is working at a startup trying to cobble something together that looks like a working product by customers and investors.

We can build very complex products today so much more easily than 10 years ago. There are services that will give you everything, from a managed DB to distributed CDN around the world, to one-command deploys... I feel like, if I only knew a business idea that didn't totally suck, I could create a whole new product that could scale to millions of users on a weekend.

"I could create a whole new product that could scale to millions of users on a weekend." Sounds like an extremely appealing business idea.

Re: In-demand tech skills are the last thing to look for in IT hires

#94

>Sure, in the ’80s, it might have been possible for one person to do it all: systems administration, database, coding, design. But in today’s world, database administrators, infrastructure engineers, coders, designers, project managers and others — whether on staff, on contract or with a vendor or service provider — must work together to execute projects quickly, securely and reliably. Tech today is a team sport. I f…

I want to preface my thoughts with that I wish the "team sport" mentality was more common in the dev world. Unfortunately, I have to agree with blueslurpee here. I frequently join a team and find there are 1 or 2 devs who "know everything" and it is near impossible to pull the information out of their heads and into mine or someone else. This might be isolated to the areas I work in, but I do find that the "10x engin…

I have the opposite problem: colleagues who don't want to learn how to do anything new.

Re: In-demand tech skills are the last thing to look for in IT hires

#95

>Sure, in the ’80s, it might have been possible for one person to do it all: systems administration, database, coding, design. But in today’s world, database administrators, infrastructure engineers, coders, designers, project managers and others — whether on staff, on contract or with a vendor or service provider — must work together to execute projects quickly, securely and reliably. Tech today is a team sport. I f…

I want to preface my thoughts with that I wish the "team sport" mentality was more common in the dev world. Unfortunately, I have to agree with blueslurpee here. I frequently join a team and find there are 1 or 2 devs who "know everything" and it is near impossible to pull the information out of their heads and into mine or someone else. This might be isolated to the areas I work in, but I do find that the "10x engin…

Why do you feel a "10x engineer" is problematic in a team? You can have different types of players in team.

Re: In-demand tech skills are the last thing to look for in IT hires

#96
post #23

Earlier quoted context omitted.

REST? Didn't you get the memo? We've all moved on to GraphQL because Facebook use it and that means we all should use it. It also enables our UI components to easily fetch data themselves . Because that's a great architectural pattern that we've discovered.

I haven't read enough about GraphQL (or even used it) to debate its relative merits, but I find it very interesting from "business architecture" point of view. For instance, assume the future of IT looks like it does today, only ramped up x10. Imagine the majority of business value is driven disparate API's/Services managed by companies or organisations, with numerous and diverse clients that can "plug in" for their…

We don't need to imagine, that was the scenario being sold for CORBA/DCOM, then it was sold for SOAP/XML-RPC webservers,...

We even got stuff like Bizztalk and BPEL to orchestrate API calls with graphical workflows.

The circle of IT fashion.

Re: In-demand tech skills are the last thing to look for in IT hires

#97
post #79
post #77

Earlier quoted context omitted.

> I still don't think GraphQL as state management is a good idea for anything surpassing moderate complexity This statement is a bit hard to break down. What is "moderate complexity"? For example, I have implemented layers where GraphQL queries feed into mobx to manage some additional application state that never persists. I didn't even use apollo client for this, I just fired off a REST query. Apollo client, on the…

> For example, I have implemented layers where GraphQL queries feed into mobx to manage some additional application state that never persists. Not sure what you want to say with this because it sounds like you used Mobx for state management in that case. Or do I misunderstand you? > I additionally think that it's a very light layer in terms of managing state According to bundlephobia: React + DOM = ~42KB Gzipped @apo…

> > For example, I have implemented layers where GraphQL queries feed into mobx to manage some additional application state that never persists.

> Not sure what you want to say with this because it sounds like you used Mobx for state management in that case. Or do I misunderstand you?

Yes, I kind of botched it, but it's my point - GraphQL as state management can mean a lot of things. It can mean Apollo, client-side cache invalidation, use of subscriptions, etc.. I think that I found your statement of GraphQL breaking down above moderate complexity confusing because it was unclear to me what way you meant this in.

RE: apollo client, it's interesting to see that it's large, I agree that contrasted to XState or Mobx or especially Redux it is quite large, I would be happy to see that number come down, but I also am not so scared of 40KB I can serve from cache given I'm rendering "dataflow editors" of some complexity

Finally, I agree I barely use Apollo, I find its graceful property to primarily be cache management but greatly prefer mobx for true application state management because it is blazing fast / the most efficient rendering strategy

Re: In-demand tech skills are the last thing to look for in IT hires

#98

Earlier quoted context omitted.

I want to preface my thoughts with that I wish the "team sport" mentality was more common in the dev world. Unfortunately, I have to agree with blueslurpee here. I frequently join a team and find there are 1 or 2 devs who "know everything" and it is near impossible to pull the information out of their heads and into mine or someone else. This might be isolated to the areas I work in, but I do find that the "10x engin…

How much of that is because those people aren’t being team players vs them learning things differently? In my experience the people who “know everything” either wrote the code from scratch (thus understanding it at a deeper level than the quick summaries people would use to describe it) or just read.the.damn.code. This is a problem I also deal with working with junior team members who would rather ask a question abou…

I share my screen and do an initial source code walkthrough of the overall structure of the project / component, and make sure they can build and run the code, before asking a junior team member to read the code themselves and figure the rest out on their own. It's worked really well, in my experience.

Re: In-demand tech skills are the last thing to look for in IT hires

#99
post #47

Our interviews for tech hires have gradually evolved into an interrogation regarding a person's attitude towards work/peers more so than their knowledge about how to do specific tech things. Teaching a willing participant how to do virtually anything with a computer is feasible in 2021. We need people who are willing to engage difficult, fast-changing things substantially more than smart-asses who think they know eve…

>We need people who are willing to engage difficult, fast-changing things substantially more than smart-asses who think they know everything coming in the door.

Iny my world it means:

We want full stack developer (backend+frontend) which also knows "cloud/devops", databases, UI/UX?

Re: In-demand tech skills are the last thing to look for in IT hires

#100

Earlier quoted context omitted.

I want to preface my thoughts with that I wish the "team sport" mentality was more common in the dev world. Unfortunately, I have to agree with blueslurpee here. I frequently join a team and find there are 1 or 2 devs who "know everything" and it is near impossible to pull the information out of their heads and into mine or someone else. This might be isolated to the areas I work in, but I do find that the "10x engin…

How much of that is because those people aren’t being team players vs them learning things differently? In my experience the people who “know everything” either wrote the code from scratch (thus understanding it at a deeper level than the quick summaries people would use to describe it) or just read.the.damn.code. This is a problem I also deal with working with junior team members who would rather ask a question abou…

> In my experience the people who “know everything” either wrote the code from scratch (thus understanding it at a deeper level than the quick summaries people would use to describe it) or just read.the.damn.code. This is a problem I also deal with working with junior team members who would rather ask a question about how something works rather than read the source. Even if I do try to explain it, I can’t explain it to the fidelity and nuance encapsulated in the actual code. Nor can I explain the context as well as clicking “find references” does.

Depends on the shop.

The trend is toward people trying to standardize and automate as much of the development process as possible (so that they can get rid of domestic employees who cost to much and fetch it all over to people in exploitable-countries with less valuable currencies).

People who ask questions, push less ambitious changes, push buggy stuff that barely squeaks past the unit tests and then go back and improve it later if someone complains.. all of that leaves activity metrics that check boxes on the reports of people who don't care whether devs read and understand the existing code or not.

Post reply on HN