Live data from Hacker News

Choose Boring Technology (2015)

boringtechnology.club

261–270 of 374 posts

Re: Choose Boring Technology (2015)

#261

Earlier quoted context omitted.

I'm doing technical interviews. There is such a shortage of people that know the basics of programming, that selecting for such l33t skills is out of the question. The hiring process right now is not about selecting the best, it's about selecting those that pass some low bar.

What do you classify as the basics of programming. for loops and if statements?

Maybe I exagerated, but you can't believe that 50% of candidates have such a low capability.

"How high do you score your C++ skills out of 10?" "9/10" "OK, can you explain what a pointer is?" blank stare... "no idea"

Re: Choose Boring Technology (2015)

#262

Earlier quoted context omitted.

What do you classify as the basics of programming. for loops and if statements?

Maybe I exagerated, but you can't believe that 50% of candidates have such a low capability. "How high do you score your C++ skills out of 10?" "9/10" "OK, can you explain what a pointer is?" blank stare... "no idea"

I was genuinely curious what you classed as basic programming.

I would definitely consider pointers pretty fundamental if you're a C++ dev.

It is pretty hard to believe that 50% of candidates don't know what a pointer is. I've barely touched C/C++ and still know what pointers are and how they work.

Re: Choose Boring Technology (2015)

#263
post #25

Earlier quoted context omitted.

They are fearful and paranoid of making a bad hire because they don't know how to assess whether the engineer is destroying the company from the inside. If there was a reliable general algorithm to make good software managers would hire lousy engineers then tell them to execute the algorithm. There isn't, they can't. The fallback is to be as picky as possible about who has influence on the software.

> They are fearful and paranoid of making a bad hire because they don't know how to assess whether the engineer is destroying the company from the inside. This is the obvious conclusion. I wonder when investors will wake up to the value of having engineering-savvy management.

> I wonder when investors will wake up to the value of having engineering-savvy management.

To be fair, engineering-savviness and willingness to be management (especially the kind of management that are legible to investors) are substantially anticorrelated.

Re: Choose Boring Technology (2015)

#264

I always found it funny that companies will go to extreme Herculean lengths to hire the best programmers, and are incredibly fearful and paranoid that they could be making a "bad hire", and yet once hired they don't spend a second making sure engineers aren't completely running the software product off the rails and killing the company internally. The author mentions trying to rewrite Etsy's backend in Scala and Mong…

>counting on managers to defend against this behavior and not actively promote and drive it

Good luck...

Re: Choose Boring Technology (2015)

#265
Useless advice of the type of "choose the right tool for the task", what is boring? what is the right tool? That's always the question, not the answer. There are also so many other variables to decide success and outcome that I am not sure anyone can point their finger to the technology stack and certainly claim that it is the cause of this or that.

Re: Choose Boring Technology (2015)

#268
post #52

My internal devops group has this issue. We had a working system on teamcity and the hashicorp stack and linkerd. Now we are working on a brand new system using gitlab and openshift and istio. Highly redundant with, from my perspective, only incremental advantage. At the beginning I spoke out against this, but failed to convince anyone. Progress has been alright because of our new 10x hire who hated the old tech and…

I'm surprised one guy can bring in gitlab, openshift, and istio all by himself. They're not small things to setup and to migrate existing software to. Typically how this goes, few of the existing software migrate to the new stack (it's too much work to migrate and it doesn't work as well). After the guy is gone, you can deprecate the new stack immediately and don't bother supporting it. I've seen it happen a lot. Wha…

He is handling the integration. The maintenance of the products falls on the ops team. He is doing a great job. I just don't think he will stick around to maintain things once he is done, and we will have two stacks to migrate and maintain.

Re: Choose Boring Technology (2015)

#269

Earlier quoted context omitted.

Maybe I exagerated, but you can't believe that 50% of candidates have such a low capability. "How high do you score your C++ skills out of 10?" "9/10" "OK, can you explain what a pointer is?" blank stare... "no idea"

I was genuinely curious what you classed as basic programming. I would definitely consider pointers pretty fundamental if you're a C++ dev. It is pretty hard to believe that 50% of candidates don't know what a pointer is. I've barely touched C/C++ and still know what pointers are and how they work.

> I've barely touched C/C++ and still know what pointers are and how they work.

Congratulations you’ve successfully triggered the pedantic interviewer. You will now face six questions on pointers in C++ they just looked up each more trivia based than the last.

Re: Choose Boring Technology (2015)

#270
post #52

My internal devops group has this issue. We had a working system on teamcity and the hashicorp stack and linkerd. Now we are working on a brand new system using gitlab and openshift and istio. Highly redundant with, from my perspective, only incremental advantage. At the beginning I spoke out against this, but failed to convince anyone. Progress has been alright because of our new 10x hire who hated the old tech and…

Welcome to politics :-) My only suggestion is that one must consider both pathos as well as logos when making rhetorical appeals.

Good point. Pathos is not with the boring old tech approach :)
Post reply on HN