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

We will never have enough software developers (2020)

whoisnnamdi.com

Post reply on HN
Print view View original

261–270 of 553 posts

Re: We will never have enough software developers (2020)

#261

Post by Aeolun »

whimsicalism wrote: post #210
rootusrootus wrote: post #124

Earlier quoted context omitted.

I definitely think "we do not do leetcode interviews" and maybe "we only have three interviews total" would be selling points on a job posting. People who are experienced in the field don't want to go through the same hoops that newbies do just to prove they know how to write basic algorithms.

Personally I do because I enjoy working with very smart people. The backlash against leetcode is the same as backlash against other types of tests: most people are going to fail and most people don't like failing, so they blame the test.

The backlash is the same as the one against standardized testing methods in school. People that don’t fit the mold of the testing method will fail regardless of how competent they are at their actual job.

It’s good you like that I suppose, but it sounds absolutely bonkers to me.

Re: We will never have enough software developers (2020)

#263

Post by onion2k »

dt3ft wrote: post #24
cabraca wrote: post #7

Earlier quoted context omitted.

its not just the best ones. If you remove people from the grind for 1-2 days a week, give them a small budget and enough autonomy to do what they want, most people will fix shit that bugged them for a long time. The main problem is how micromanage-y the current development processes are. Everything has to be a ticket/user story and has to be planned and approved by some people that never even wrote a single line of c…

We can’t even push to a git repo unless it has a linked work item/story/task/bug. So, in order to say, upgrade packages or refactor difficult to read code, the work item needs to be approved by a non-tech PO. Guess how much gets done outside of planned/micromanaged? Answer: next to nothing.

Guess how much would get done if you learned to explain why that work is important to a non-technical colleague? Lots. People don't always understand code, but they do understand problems, and why those problems are important to keep on top of.

If your PO is sensible then a couple of paragraphs explaining why refactoring is important with a closing line that says spending a week catching up on refactoring now will save 4 sprints of work in a year's time will get you the time. People aren't stupid. Once they understand why something is necessary they've very receptive.

Also, add refactoring time in to your estimates in the future and you won't end up in this situation, plus the code that's committed will be better.

Re: We will never have enough software developers (2020)

#264

Post by mysterydip »

cabraca wrote: post #7
JackMorgan wrote: post #5

A fascinating premise, and matches what I saw as an engineering director. The best just get bored and move on. I think many teams are unaware how much extra value is possible by retaining existing employees vs hiring new ones. Each year I'd try to make sure I was "making them an offer they couldn't refuse" with new interesting challenges, new tech, plenty of personal research time, as much pay increase as I could pos…

its not just the best ones. If you remove people from the grind for 1-2 days a week, give them a small budget and enough autonomy to do what they want, most people will fix shit that bugged them for a long time. The main problem is how micromanage-y the current development processes are. Everything has to be a ticket/user story and has to be planned and approved by some people that never even wrote a single line of c…

> give them a small budget and enough autonomy to do what they want, most people will fix shit that bugged them for a long time.

This has been huge for me at my current job. I saw some unused equipment in a lab and started asking questions why. Turns out the thing worked, but not great, so no one used it. What started as just fixing bugs and adding features became my own line item in the budget and requests for the (new and improved) equipment from other departments. It's something I look forward to working on.

Re: We will never have enough software developers (2020)

#265

Post by hilbertseries »

Guid_NewGuid wrote: post #181
rootusrootus wrote: post #67

Earlier quoted context omitted.

That definitely sounds broken. I have a hard rule with my PO: 30% of the sprint is mine (read: the team's). He only gets to schedule 70% of the stories according to his priorities. I use that 30% for tech debt, primarily, but sometimes for spike projects and other things that interest us.

It sounds like SOC2 compliance requirements unfortunately. Plus process overhead on who can raise tickets. I've found compliance makes it harder to write good code. If you get a PR approval with optional suggestions you're heavily disincentivised from actually addressing those comments since if you push those changes you now need to wait for review again. Like everything process and compliance it's designed by low-co…

My company is soc2 compliant and we don’t need work items to push code. Certain changes need to be approved, but they can be approved by a software engineer on one of the approving teams for the repository.

Re: We will never have enough software developers (2020)

#266

Post by finnh »

sirsinsalot wrote: post #246
dt3ft wrote: post #24

Earlier quoted context omitted.

We can’t even push to a git repo unless it has a linked work item/story/task/bug. So, in order to say, upgrade packages or refactor difficult to read code, the work item needs to be approved by a non-tech PO. Guess how much gets done outside of planned/micromanaged? Answer: next to nothing.

I get why bureaucracy is a total pain, getting work approved by stakeholders constantly ... But the actual ticketing/PR system? Change requires control. The actual issue is not _using_ that control tool to get the right things done. If basic technical debt issues are not an easy sell in your org, that's the real problem and one that should be handled by senior/dev manager. A big red flag for me is any org that doesn'…

Requiring a "non-tech PO" to upgrade a package is just broken, though. PMs are good at some things, but giving them power over every minute of an engineer's day is a recipe for badness.

Re: We will never have enough software developers (2020)

#267

Post by whimsicalism »

Aeolun wrote: post #261
whimsicalism wrote: post #210

Earlier quoted context omitted.

Personally I do because I enjoy working with very smart people. The backlash against leetcode is the same as backlash against other types of tests: most people are going to fail and most people don't like failing, so they blame the test.

The backlash is the same as the one against standardized testing methods in school. People that don’t fit the mold of the testing method will fail regardless of how competent they are at their actual job. It’s good you like that I suppose, but it sounds absolutely bonkers to me.

> don’t fit the mold of the testing method will fail regardless of how competent they are at their actual job.

The mold being answering questions about their supposed area of expertise.

I think people really like to claim that they are misunderstood geniuses who just don't fit the mold of being able to answer questions about the things they know. I have no doubt that such people exist, but I would not want to scrap an evaluation system simply because it doesn't catch every possible person, more important to me is keeping bad people out.

Re: We will never have enough software developers (2020)

#268

Post by onion2k »

wes-k wrote: post #90
cabraca wrote: post #7

Earlier quoted context omitted.

its not just the best ones. If you remove people from the grind for 1-2 days a week, give them a small budget and enough autonomy to do what they want, most people will fix shit that bugged them for a long time. The main problem is how micromanage-y the current development processes are. Everything has to be a ticket/user story and has to be planned and approved by some people that never even wrote a single line of c…

I've dreamed about a 20% policy like google had, except it's where you can work on anything, including code debt. I've tried to stress to managers in the past that developers feel the pain of code debt. It makes us slower! Enable us to spend time sharpening our tools and managing our codebase. One problem of course is, not all SWE can do this well. I wouldn't necessarily trust a junior hire to recognize and execute a…

I've dreamed about a 20% policy like google had, except it's where you can work on anything, including code debt.

Where I work we have 1 'maintenance day' each sprint where the devs choose what to work on. That can be fixing annoying issues, improving the code, learning something, trying something out, etc. It works well when other things aren't taking priority (which is far too often tbh).

Re: We will never have enough software developers (2020)

#269

Post by Patrol8394 »

whimsicalism wrote: post #253
Patrol8394 wrote: post #235

Earlier quoted context omitted.

leetcode == smart ? oO that's new I interview many candidates at FAANG, I can easily tell the ones that have prep by just doing leetcode and the ones that knows the shit. I couldn't care less if you can solve all kinds of complex dynamic programming challenges. I ask coding questions that you won't find in leetcode and requires problem solving skill and good craft. And this is because I do like working with smart peo…

I consider solving technical challenges in interview the "LC style" interview as compared with talking about your past experience or language trivia grab bag. I am not saying literally ask questions found on leetcode.com I think it is easier to know the shit to do LC interviews than somehow memorizing the question bank. I haven't seen many people succeed who were unskilled but managed to just memorize the questions.

so how come that I find a good chunk of swe at FAANG are not that smart, and barely get anything done. Plus the quality of their work (generally speaking) is very low compared to what one would expect. And this is true across the board, it is a recurring theme when talking with peers.

I think LC style interview have ruined the interview process in the tech industry.

Note: I do ask candidates to code during the interview, but I ask things that are related to real problem, some of which, I had to solve in my day-to-day.

In addition, I put a lot of emphasis on how well they articulate their thought process, and the quality of their craft.

Also, I would not discount `past experience talk` that easily. Actually I use that to drill down in their resume to better understand their real contribution. More often than not, people just lie. They are very easy to spot. At that point is game over. I don't care if you nailed the coding. If you lie and oversell yourself you are done.

Another thing that I find very annoying is that very often interview are conducted by junior engineer, and they don't have imo the maturity and experience to properly assess candidate skills and potential. You either do well according to what their expected solution is, or you are out.

Interviewing is not just a binary process coding well yes/not. It is a little more involved.

I passed candidates that did not do well on coding, but I was convinced they had potential. Whereas I did not pass candidate that did very well on coding, but did not show any interest or passion at all.

Re: We will never have enough software developers (2020)

#270

Post by bradlys »

hellohowareu wrote: post #158
t_mann wrote: post #73

Some really good points on the ultra-fast depreciation of SE tech skills. A relative of mine is a mechanical engineer, well past retirement age and still going strong in his 2-man consulting shop because that's what he loves doing. He works with precision manufacturers, automotive suppliers,... all very cutting-edge stuff, helping them develop new product lines, manufacturing processes,... He says the core skills tha…

I think the skill depreciation concept is a bit exaggerated. Especially in the context of the newness of computers relative to the engineering field in general, the latter which has been around, arguably, for thousands of years. For example, SQL & Unix have been around since the 1970s. Linux since late 1991. Javascript: The end of 1995. NodeJS: 2009. Sure, there's a ton of churn in the JS Ecosystem, but all it takes…

The issue is that every job I’ve had requires learning a bunch of new shit. Rarely am I just transferring over to the same languages or frameworks. Add on that each company decides different design patterns that they want to utilize and has a different interpretation of what REST is and what HTTP status codes are… it’s a pain in the ass to be an expert in any good amount of time. Expert being one that can dive into the true weeds like cryptic memory leaks that require special profiling tools that aren’t documented anywhere - etc. (and able to do this at a moments notice with ease)

Especially if you’re a full stack eng who is constantly swimming over the entire stack and they keep pushing new DBs, new logging tools, etc.

There are commonalities but it is a lot of learning as you go. I used to know Angular pretty well but now I don’t remember it at all. I haven’t even gotten to really ramp on React as much because my company uses it in such a terrible way that it’s clearly not fit for.

Post reply on HN