|
quote:If they are weak on the skills they need for the job, then find a topic they know a lot about instead, and get them to talk about it, if necessary explaining it to you. You are looking for grasp of complex topics and the ability to clearly communicate about them, which are the two jobs of the working engineer. Ex-actly. This is how we picked our most recent candidate who started two weeks ago. He talked through some code he had previously written in Go (which we don't and won't use), and even though he didn't have the specific technology experience we need, he's picked it up extremely quickly and is kicking rear end.
|
#
?
Jun 12, 2019 21:56
|
|
|
|
| # ? May 11, 2024 22:52 |
|
|
Keetron posted:I am just going to leave this here I've gotten hired for every category of "Don't" so this is probably solid advice.
|
|
#
?
Jun 12, 2019 22:55
|
|
|
Sometimes you need someone that will be productive at helping some specific problems and do need someone that knows a specific technology, sometimes you need more horizontal skills and general smarts to be able to adapt and roll with the punched . Make it clear to the candidates what you are looking for, how you measure, and you should get better results. Also, if your candidate gives a response you don’t like, always give an opportunity to clarify the thought process and where they stand. I oftentimes get the “it’s an ops problem!” answer and the reasoning has ranged from “not what I’m hired to do” to “I don’t feel confident I can contribute much” which I can lead to the real attitude question of “if we had a need for a developer to help with an outage at 1 am when we need a code fix after trying other approaches for 2 hours, how would you contribute?” (making it clear that it’s a hypothetical rather than “this happens a lot” situation).
|
|
#
?
Jun 12, 2019 23:29
|
|
|
Is it common for you guys to encounter hires that passed the technical interview process and turned out to be problematic from a technical proficiency standpoint? I personally can't think of many cases like that - most problem hires tend to be duds from a cultural fit, soft skills standpoint.
|
|
#
?
Jun 13, 2019 00:18
|
|
|
I'd call "culture fit" and "soft skills" two different things. If you can deal with people effectively, you've got good soft skills no matter what the cultural habits are at a particular company. If the internal culture is lovely, it probably got to be that way by hiring lots of people with poor soft skills (or lovely management that drove away the people with any self esteem).
|
|
#
?
Jun 13, 2019 00:45
|
|
|
Blinkz0rz posted:Yeah terminating 1000 instances to tweak thread pools or rotate db credentials is probably a bad idea do you do in place code upgrades too? what's it like working in 2009?
|
|
#
?
Jun 13, 2019 02:33
|
|
|
It's very easy to sneer at that stuff but it's still well over 80% of organisations who don't follow the true-devops-immutable-server-canary-rollout way. My team in a company of 30 teams are one of only a few who use containers, canaries, and immutable infrastructure. The rest are along a wide spectrum of "everything is lambda & dynamoDB with terraform" to "hand-deploying config changes on a running instance because my brain can't work without remote desktop". So these problems exist in a very real way and it's hard to move hundreds of people at once to the one true way(tm) which may or may not be a good fit depending on how value should be delivered to the customer, the existing legacies, and all other kinds of organisational fuckery.
|
|
#
?
Jun 13, 2019 09:01
|
|
|
necrobobsledder posted:sometimes you need more horizontal skills hosed up thing to say in the me too era.
|
|
#
?
Jun 13, 2019 14:39
|
|
|
Cancelbot posted:It's very easy to sneer at that stuff but it's still well over 80% of organisations who don't follow the true-devops-immutable-server-canary-rollout way. Lol if you think 20% of organizations 'follow the true-devops-immutable-server-canary-rollout way.' Less than 20% of organizations will have a documented deployment pipeline.
|
|
#
?
Jun 13, 2019 17:02
|
|
|
Hughlander posted:Less than 20% of organizations will have anything documented
|
|
#
?
Jun 13, 2019 18:21
|
|
|
Nah, organizations usually have a lot of documentation. There is one set of documentation in the confluence, one in the dokuwiki, one in the repository and the last one of them was updated years ago 
|
|
#
?
Jun 13, 2019 18:43
|
|
|
Xarn posted:Nah, organizations usually have a lot of documentation. As long as each of those three claim completely different things, everything is fine. And I'm feeling good about setting up a documented Documentation deployment pipeline
|
|
#
?
Jun 13, 2019 18:48
|
|
|
Hughlander posted:Lol if you think 20% of organizations 'follow the true-devops-immutable-server-canary-rollout way.' Oh that's why I qualified it with well over 80%. It's definitely closer to 99.9% but I don't have any data to back that statistic up, it's pure guesswork but with a little latitude you could probably optimise a bit at a time within the constraints of the organisation. Cancelbot fucked around with this message at 19:37 on Jun 13, 2019 |
|
#
?
Jun 13, 2019 19:34
|
|
|
On another subject: code reviews.quote:The type of people who write bad code are the type of people who want code reviews.
|
|
#
?
Jun 13, 2019 20:34
|
|
|
What a doozy of a badwrong opinion. Code reviews are a great tool to improve code quality and team knowledge of the system.
|
|
#
?
Jun 13, 2019 20:43
|
|
|
Clanpot Shake posted:What a doozy of a badwrong opinion. Code reviews are a great tool to improve code quality and team knowledge of the system. If done well - at my old job they were just another checkbox required for some middle manager to feel good about some stats. It was very common that if you actually ready the code you'd get pinged and asked to complete it. I figured out who those people were trying to push poo poo through and got real nitpicky, though.
|
|
#
?
Jun 13, 2019 20:56
|
|
|
If you don't have a code review system in TYOOL 2019 you need to find a different employer
|
|
#
?
Jun 13, 2019 21:11
|
|
|
Volmarias posted:If you don't have a code review system in TYOOL 2019 you need to find a different employer Not empty quoting this.
|
|
#
?
Jun 13, 2019 21:12
|
|
|
I sent a couple pull requests to my predecessor (who stayed on as the only other developer, but with very limited hours) and they just shrugged and said, "Seems fine." every time, so I stopped trying. So not only does my company not have a formal code review process, it doesn't even have an informal process. 
|
|
#
?
Jun 13, 2019 21:21
|
|
|
Rocko Bonaparte posted:On another subject: code reviews. The scary part is anyone who thinks they write good code. Everything I write is garbage, has always been garbage, and will always be garbage.
|
|
#
?
Jun 13, 2019 21:26
|
|
|
Volmarias posted:If you don't have a code review system in TYOOL 2019 you need to find a different employer I'm finally about to start a new job at a place that has real code review processes (and tests!!!). I'm so excited, I've been desperately searching for a place that actually tries to make something of quality after working at a bunch of terrible "we have to ship fast, no time for reviews or tests" startups.
|
|
#
?
Jun 13, 2019 21:34
|
|
|
New Yorp New Yorp posted:The scary part is anyone who thinks they write good code. Everything I write is garbage, has always been garbage, and will always be garbage. My hot take: There is no good code that hasn't been reviewed.
|
|
#
?
Jun 13, 2019 21:47
|
|
|
You know how authors/bands/directors turn to poo poo once they're too famous for an editor? Well....
|
|
#
?
Jun 13, 2019 21:52
|
|
|
New Yorp New Yorp posted:The scary part is anyone who thinks they write good code. Everything I write is garbage, has always been garbage, and will always be garbage. I'm not even joking, the only other dev I'd evaluate as semi-competent at my (small) office unfortunately fits this paradigm. We were having a discussion about best practices a few months back - and during the exchange, we got onto the topic of OO best practices. His take is 'OO is garbage, unit testing is a waste of time, etc'. I suggested that the reason I spend a lot of time reading up on stuff is because I think there's a lot to be learned from people who have been writing software for longer than I've been alive. They aren't always right, but there are lessons to be learned from their experiences and ideas. I don't feel like I'm at a point in my knowledge and skillset where I'm in a position to somehow redefine software development paradigms. He said emphatically and sincerely that he felt like he had - in something like 5 years as a developer - reached that point and was ready to really ignore all the rules in order to make something better. I had to hold back a full body shudder. Related: In discussing how he's solved the problem of shared state in his personal project - some game - he proudly tried to explain the plan was basically to dump all global state into, well, a big fat global object and just make sure nothing touched things they weren't supposed to. 
|
|
#
?
Jun 13, 2019 22:10
|
|
|
Cuntpunch posted:Related: In discussing how he's solved the problem of shared state in his personal project - some game - he proudly tried to explain the plan was basically to dump all global state into, well, a big fat global object and just make sure nothing touched things they weren't supposed to. lol I'm doing exactly that in a personal project. But at least I know enough to know that I'm doing a terrible bad thing that should never see the light of day. e: it's a toy react app and I had no desire to hook up redux
|
|
#
?
Jun 13, 2019 22:12
|
|
|
Taffer posted:I'm finally about to start a new job at a place that has real code review processes (and tests!!!). I'm so excited, I've been desperately searching for a place that actually tries to make something of quality after working at a bunch of terrible "we have to ship fast, no time for reviews or tests" startups.  I'm working for one of those "ship fast, no time for reviews or tests" things, which leads me to this: Volmarias posted:If you don't have a code review system in TYOOL 2019 you need to find a different employer I rather wonder how one goes and establishes a code review system if there didn't exist one before, without massively stepping on people's toes. The way I see it, people at my work would feel like its an odd control and power move, rather than something that should help all of us to produce slightly less lovely code.
|
|
#
?
Jun 13, 2019 22:48
|
|
|
shrike82 posted:Is it common for you guys to encounter hires that passed the technical interview process and turned out to be problematic from a technical proficiency standpoint? I personally can't think of many cases like that - most problem hires tend to be duds from a cultural fit, soft skills standpoint. And we wonder why junior engineers always want to replace things with a new hotness. Edit: Phone post, fill in the gaps and don't make silly assumptions. PhantomOfTheCopier fucked around with this message at 23:30 on Jun 13, 2019 |
|
#
?
Jun 13, 2019 23:27
|
|
|
Hollow Talk posted:
Code review needs to have buy-in from the leadership. If they aren't going to support you when you say you need engineers to take time to review other engineers' stuff, you're basically dead in the water, because the alternative is to do it in secret and people just aren't going to be willing to do that for any length of time (besides which it's ridiculous). I see you're making a guess at how people would react. Do you mean devs? Because I think you'll find that most devs welcome a second set of eyes on potentially dangerous code. If you mean management, you can just bill it as quality assurance, that releasing good code that works the first time makes all the customers happy. If a large part of either of those groups takes it the way you fear, that's ridiculous and you should put all your give-a-poo poo into cold storage until you find a company to work for that's staffed by adults.
|
|
#
?
Jun 13, 2019 23:34
|
|
|
Given how many things break with code reviews, I can't imagine having customers at all (that would stick around for the hourly outages) without them.
|
|
#
?
Jun 13, 2019 23:41
|
|
|
You'd be surprised at the ingenuity of humans managing to work around broken processes. Something something capitalism
|
|
#
?
Jun 13, 2019 23:56
|
|
|
PhantomOfTheCopier posted:Yes because the soft skills drive true technical proficiencies: Understanding systems, generating ideas to solve intricate technical problems, modeling a system with code, turning ideas into code. Coding adaptability is a combination of experience, raw knowledge, and creativity. I've seen candidates with reasonable technical interview outcomes that crash when they discovered that production programming lacks all the structure of college classes. "Here's 50k lines of mess, fix this bug that is a confluence of five years of bad decisions and cutting corners". Don't hire that insufferable nerd, no matter how many types of tree they can put on a whiteboard!
|
|
#
?
Jun 14, 2019 00:49
|
|
|
the talent deficit posted:do you do in place code upgrades too? what's it like working in 2009? just to be clear, releasing a new version of a service is the pretty standard "bake ami, spin up new asg as canary, verify, then terminate old version's asg". however the product in question is a data pipeline that ingests an unbounded amount of data from customers and if one of them fucks up a configuration in just the right way they can degrade performance for other customers. so instead of having to redeploy the same version with that customer as part of a blacklist property, we have a system that on changing a property in a github repo, updates the property in the running application. i was under the impression that this kind of system is pretty standard once you hit a certain scale. is this not the case?
|
|
#
?
Jun 14, 2019 02:30
|
|
|
Rocko Bonaparte posted:On another subject: code reviews. Drawing from a small sample size of my current company, senior more often seems to mean "stuck around for a while" and rarely has anything to do with expertise.
|
|
#
?
Jun 14, 2019 03:23
|
|
|
Blinkz0rz posted:
Nah that's pretty hosed up and going to bite you sooner or later
|
|
#
?
Jun 14, 2019 03:25
|
|
|
Blinkz0rz posted:i was under the impression that this kind of system is pretty standard once you hit a certain scale. is this not the case? The only standard is there is no standard. This was a nice read. Maybe this will finally change managements mind... https://martinfowler.com/articles/is-quality-worth-cost.html
|
|
#
?
Jun 14, 2019 03:31
|
|
|
Hollow Talk posted:I rather wonder how one goes and establishes a code review system if there didn't exist one before, without massively stepping on people's toes. The way I see it, people at my work would feel like its an odd control and power move, rather than something that should help all of us to produce slightly less lovely code.
|
|
#
?
Jun 14, 2019 03:35
|
|
|
Hollow Talk posted:I rather wonder how one goes and establishes a code review system if there didn't exist one before, without massively stepping on people's toes. The way I see it, people at my work would feel like its an odd control and power move, rather than something that should help all of us to produce slightly less lovely code. You get people talking about it, get a consensus then say you're going to do it. I've introduced it to two places and I think next week I'll be doing it to a third...
|
|
#
?
Jun 14, 2019 03:44
|
|
|
tak posted:Nah that's pretty hosed up and going to bite you sooner or later sincerely curious why you think so
|
|
#
?
Jun 14, 2019 03:46
|
|
|
I thought a pull request implies a code review? If you didn't do a PR you'd just commit it right into trunk I figure. If you want to use something like Gerrit or Phabricator's Differential instead of Github or Bitbucket methods that's fine. If you mean the cultural practice of a code review I treat it like test coverage - start with new work instead of trying to go through the accumulated technical debt mountain. Depending upon the churn rate of the codebase this could mean it will never amount to anything materially helpful or at least newly written code should be better understood by the team. Maybe I've had an oddball career but I've never been anywhere where people would challenge the need to review code in some way. Maybe people could question the value or when it's appropriate to do so but nobody's said it's worthless either. All I know is that my team has mandated PRs less than 1k lines because our attention spans are only so long, and if you need a lot of lines use multiple PRs and use feature flags / toggles somehow to avoid breaking any codepath. We hold each other accountable and we're rapidly adding code quality tooling including linters, formatters, and analyzers where possible (seriously, how the gently caress does anyone do testing of a Jenkinsfile? The answer is... you don't, or you wind up writing a goddamn library)
|
|
#
?
Jun 14, 2019 04:58
|
|
|
|
| # ? May 11, 2024 22:52 |
|
|
Blinkz0rz posted:just to be clear, releasing a new version of a service is the pretty standard "bake ami, spin up new asg as canary, verify, then terminate old version's asg". If you've specifically engineered a part of your system to be configured without a restart, then sure, it can be okay to configure your running instances instead of starting new ones. That's only if you've specifically designed this part of your system to handle that, and hopefully you've comprehensively tested that it handles it correctly. It's not applicable for general properties that you haven't actually designed around being changed during execution. Having it automagically happen based on a change in the repo seems problematic too. If I were designing the system, I probably wouldn't do it that way.
|
|
#
?
Jun 14, 2019 05:25
|
|
