|
Like Carbon Dioxide said, you already are devops. If you don't believe us, check out this free book by Google and see if the work sounds familiar. https://landing.google.com/sre/books/
|
#
?
Sep 30, 2019 13:49
|
|
|
|
| # ? May 17, 2024 10:15 |
|
|
Turambar posted:I've become a fan of PlantUML. Layout is mostly out of your control, so you can focus on getting the work done instead of making sure every line is straight and cursing when you need to find room for a new object. Holy crap that's neat and will be very useful, thanks for sharing that.
|
|
#
?
Sep 30, 2019 15:39
|
|
|
My Rhythmic Crotch posted:Holy crap that's neat and will be very useful, thanks for sharing that. Echoing this sentiment, I'm a nerd and like diagramming, and this seems amazing.
|
|
#
?
Sep 30, 2019 16:36
|
|
|
Turambar posted:I've become a fan of PlantUML. Layout is mostly out of your control, so you can focus on getting the work done instead of making sure every line is straight and cursing when you need to find room for a new object. I use dot which is a bit simpler and also what plantuml seems to be running in the background. Plantuml adds some stuff that I don't really want and is not as straightforward as dot
|
|
#
?
Sep 30, 2019 16:51
|
|
|
Keetron posted:Yeah, I am just worried as I am unfamiliar with it. Looking up some other people's solutions will sooth my worries. Main thing for me is that I like to work test driven and the fact the tests are hidden rubs me the wrong way. Update, it turned out to be a stupid algorithm test and I bombed it hard. This is either a way to filter people like me out or to be able to lowball me but it feels like a bruise to my self confidence. And no, I have no idea why I should be able to vomit up a piece of code that will tell a frog in how many seconds he can jump the pond. Or why it matters how unique characters are in all possible substrings of a given string.
|
|
#
?
Sep 30, 2019 18:21
|
|
|
This seems to be a common thing with interview tests like that. Everything that would actually have value costs time (yours and theirs), while things that are generic are fairly useless as screening. Best case, these things don't get rid of the people you actually need/want; worst case, you end up with people who have practised or learned how to do these tests, but can't do the actual work. It's laziness and/or bad management when it comes to recruiting. Hollow Talk fucked around with this message at 18:44 on Sep 30, 2019 |
|
#
?
Sep 30, 2019 18:42
|
|
|
Candidates will be (rightly) annoyed if I ask them to spend a day writing something, especially if they already supposedly have good chops. They'll also be annoyed if they just get a Scantron test. The interviewer might get bamboozled by just asking questions about the subject matter instead of having the candidate actually solve a problem (I find this to be a huge problem with interviewing for Mobile; the breadth of possible topics means it's possible for someone with surface level knowledge to pretend they're clueful for a short amount of time) lovely algorithm problems are usually the least worst thing we have to determine job effectiveness, as a proxy for the ability to apply technical knowledge to an actual problem (instead of just memorization), talk to an actual human about problems, and demonstrate that the technical knowledge exists in the first place. If you can think of a better solution that doesn't run the risk of me hiring you because of the performance of your friend pretending to be you, then wasting a month or two (to say nothing of recruiter fees) to figure that out, the entire tech industry is all ears. You've probably seen it already, but the FizzBuzz article strikes a little too close for comfort. I disagree with the "specializations are actually weaknesses beep boop" argument but the idea that most candidates can't actually code is the unfortunate state of the industry.
|
|
#
?
Oct 1, 2019 01:04
|
|
|
Judge Schnoopy posted:Our firewalls are split between two teams. Devices are owned by network, ACLs / security config is owned by security. We have a fairly in depth microsegmentation deployment as well. My role as security engineer is maintaining these configs, auditing them, and providing access for new apps as appropriate. Lmao. We got into a huge argument when I said SDNs and automation in general were the future. Just start applying for devops or SRE roles at this point. A passing knowledge of any of this and a pulse is enough to get in at most places. FAANG might be out of reach, mainly because they have absolutely want folks with the right majors, and thus spend a lot of time reinventing the wheel.
|
|
#
?
Oct 1, 2019 04:11
|
|
|
Sure process automation is going to wipe out lots of jobs but when you see the stuff happening under the lid for a lot of RPA (robotic process automation) tools, you’re going to lol
|
|
#
?
Oct 1, 2019 04:29
|
|
|
shrike82 posted:Sure process automation is going to wipe out lots of jobs but when you see the stuff happening under the lid for a lot of RPA (robotic process automation) tools, you’re going to lol This is relevant to something I’ve done recently and... I agree.
|
|
#
?
Oct 1, 2019 04:32
|
|
|
Volmarias posted:Candidates will be (rightly) annoyed if I ask them to spend a day writing something, especially if they already supposedly have good chops. They'll also be annoyed if they just get a Scantron test. The interviewer might get bamboozled by just asking questions about the subject matter instead of having the candidate actually solve a problem (I find this to be a huge problem with interviewing for Mobile; the breadth of possible topics means it's possible for someone with surface level knowledge to pretend they're clueful for a short amount of time) I think that a more effective approach is to sit down with a candidate and go over their github. If they don't have a github send them a technical challenge that will result in a thing they can put on their github. Building a small two hour project shouldn't be a big ask, and you can tweak the nature of it to the seniority of the candidate. These are great because if they faked it, you'll know as soon as you asked why they did one approach over another, or start talking about edge cases. I might be unfairly biased though, I feel like i've definitely missed out on jobs by being asked to implement merge sort using only javascript or whatever.
|
|
#
?
Oct 1, 2019 05:48
|
|
|
Hollow Talk posted:you end up with people who have practised or learned how to do these tests, but can't do the actual work. This is basically what it taught me, learn to dance the dance and get hired. Cognitive dissonance from management will get you not fired. TheCog posted:Having to learn the tricks for a bunch of these problems is exhausting and a poor metric. I've never once in real life had to implement a two pointer solution, or had to roll my own sorting algorithm, making me do it in a timed environment, in an unfamiliar IDE, without the ability to google the already solved question in no way reflects my ability to solve problems. Keetron fucked around with this message at 05:53 on Oct 1, 2019 |
|
#
?
Oct 1, 2019 05:51
|
|
|
"You can't have a plan and stick to it." May be my new favorite corporate meeting quotation.
|
|
#
?
Oct 1, 2019 06:37
|
|
|
Volmarias posted:Candidates will be (rightly) annoyed if I ask them to spend a day writing something, especially if they already supposedly have good chops. They'll also be annoyed if they just get a Scantron test. The interviewer might get bamboozled by just asking questions about the subject matter instead of having the candidate actually solve a problem (I find this to be a huge problem with interviewing for Mobile; the breadth of possible topics means it's possible for someone with surface level knowledge to pretend they're clueful for a short amount of time) I'm aware this is a problem, and that it isn't easy to solve. The last two people we hired weren't very good, so I'm still trying to get better at this. I strongly tend towards sitting down with the applicant the next time and do code reading of an actual project, maybe even a suboptimal legacy project, because that will hopefully a) show me if they understand other people's code b) can reason about said code c) can communicate and d) are willing to work together like this. It also means we can discuss alternatives, approaches etc. It's not perfect, but I feel it tells me more about what it will be like working with that person, rather than having them regurgitate fizzbuzz. I feel like short of outright having them do something for a longer time, anything they can solve within a very short timeframe can either be prepared/learned by heart, or it is trivial enough that even a lovely programmer can solve it. On the other hand, generic CS algorithm questions might filter out the wrong people based on not being applicable to real work.
|
|
#
?
Oct 1, 2019 07:17
|
|
|
Hollow Talk posted:I'm aware this is a problem, and that it isn't easy to solve. The last two people we hired weren't very good, so I'm still trying to get better at this. This is a good idea, really. That would be something that they would actually be doing.
|
|
#
?
Oct 1, 2019 08:21
|
|
|
Mr Shiny Pants posted:This is a good idea, really. That would be something that they would actually be doing. Previously I was asked to do a take home assignment to write a simple but functional backend application, something that can be done in Spring Boot in 2 to 4 hours. After the code was checked, we talked about why I did some things this way instead of the other way. It got me hired every time. Code assessments using codility not so much...
|
|
#
?
Oct 1, 2019 08:52
|
|
|
Cuntpunch posted:"You can't have a plan and stick to it." May be my new favorite corporate meeting quotation. Real time user generated uptime metrics is the best I've heard recently
|
|
#
?
Oct 1, 2019 08:54
|
|
|
The best interview process I’ve gone through involved a technical phone screen, a remote programming test (6 hour deadline and “academic”) followed by an on-site 1-day work-related coding project. The funny thing about that is the hiring manager mentioned after I accepted the offer that he had already more or less made up his mind at the phone screen step (we both were alum from the same CS program). For all people talk about technical rigor, people don’t hire on that basis in practice shrike82 fucked around with this message at 10:14 on Oct 1, 2019 |
|
#
?
Oct 1, 2019 10:12
|
|
|
shrike82 posted:For all people talk about technical rigor, people don’t hire on that basis in practice This is the real problem. Interview techniques aren't standardized and there's a lot of stereotyping, nepotism, and social engineering that influences the decision makers. The companies I've worked for don't keep records of how candidates interview so there's little to no correlation between their interviews and their job performance. Or, worse, a candidate has a negative technical result and "Well we can train them, we need devs, hire hire hire!" and then acts surprised when we need to let them go 90 days later. Weirdly, technical people seem to be the absolute worst at this. I've never sat through worse interviews than when I was on an interview committee with a bunch of other engineers. If the other engineers liked someone (AKA the candidate had the same Warby Parker glasses and beard), they would let them sail through with a few easy questions. If they didn't like someone, they would blast them with increasingly technical "brainteaser" type questions. It kind of reminds me of the debate around estimates. "Estimates are impossible!", according to an engineer who has never actually measured the time spent on anything, broken down a feature into component pieces, compared them with prior work of a similar type, added uncertainty multipliers, and sanity-checked with another engineer.
|
|
#
?
Oct 1, 2019 13:21
|
|
|
Been working at my new job for a month, which is working on a piece of software that has been in continuous development for 17 years now. I've started picking up progressively more complicated work. A couple days ago I picked up a story that was essentially "We need this API endpoint to include this piece of data that we return in this other API endpoint." Ok, they have lots of similar data, the one in the story was just missing a couple pieces of data and then I can easily retrieve that data and put it in the returned object. Took a couple of days to figure out how the methods to actually get this data worked(as I said, the code base is 17 years old so it has some issues weird workarounds and spaghetti code here and there), but I finally got it working! Then, at today's standup, people were like "Oh, we should probably discuss these things that are going to need to go into this story that we didn't spell out". Things like the fact that in addition to adding that data to the API endpoint, all of the data in the endpoint is now supposed to come from a different source than it does right now. They apparently didn't actually put this in the story, it seems it was just kind of "understood" that would be part of the story, and no one bothered to tell me until I had already worked on the bloody thing for 2-3 days. This results in basically all the work I've done in that time on this story getting scrapped. Whee.
|
|
#
?
Oct 1, 2019 17:43
|
|
|
Khisanth Magus posted:Been working at my new job for a month, which is working on a piece of software that has been in continuous development for 17 years now. I've started picking up progressively more complicated work. A couple days ago I picked up a story that was essentially "We need this API endpoint to include this piece of data that we return in this other API endpoint." Ok, they have lots of similar data, the one in the story was just missing a couple pieces of data and then I can easily retrieve that data and put it in the returned object. Took a couple of days to figure out how the methods to actually get this data worked(as I said, the code base is 17 years old so it has some issues weird workarounds and spaghetti code here and there), but I finally got it working!
I hope they pay well? Keetron fucked around with this message at 18:33 on Oct 1, 2019 |
|
#
?
Oct 1, 2019 18:30
|
|
|
i don't see exploratory plumbing like you did to be a total waste, there is inevitably something you learned in that time/effort that will come in later useful or trained you on how to work with the repo nor do i think a 17yo code base that's continuously earning a profit is a walk-away-dumpster-fire situation because of a single ticket misfire wasting <20h of the most junior dev's time but you could perhaps push for some of the "understood" items to be written up explicitly to avoid this in the future
|
|
#
?
Oct 1, 2019 20:15
|
|
|
JawnV6 posted:i don't see exploratory plumbing like you did to be a total waste, there is inevitably something you learned in that time/effort that will come in later useful or trained you on how to work with the repo You know, I think these points are very good and while I will leave my post up, you (Kishanth) should take it with a grain of salt.
|
|
#
?
Oct 1, 2019 20:39
|
|
|
Khisanth Magus posted:Been working at my new job for a month, which is working on a piece of software that has been in continuous development for 17 years now. I've started picking up progressively more complicated work. A couple days ago I picked up a story that was essentially "We need this API endpoint to include this piece of data that we return in this other API endpoint." Ok, they have lots of similar data, the one in the story was just missing a couple pieces of data and then I can easily retrieve that data and put it in the returned object. Took a couple of days to figure out how the methods to actually get this data worked(as I said, the code base is 17 years old so it has some issues weird workarounds and spaghetti code here and there), but I finally got it working! Ask to pair program with an experienced team member. You will never get devs to capture all of their assumptions in the stories, because experienced devs often don't realize that everyone else doesn't know the same things they know. and vice versa. I'm guilty of this too.
|
|
#
?
Oct 2, 2019 05:04
|
|
|
Meanwhile, I have to keep reminding our customers to start at the beginning when they send me a feature request. I don't work on the Freeblegarble module 40 hours a week like you all do, people! Give me some dang context!
|
|
#
?
Oct 2, 2019 05:36
|
|
|
Lord Of Texas posted:Ask to pair program with an experienced team member. Everyone is guilty of this. We use pair programming as a teaching tool, it works really well for us.
|
|
#
?
Oct 2, 2019 07:44
|
|
|
Got a ticket to add some functionality to match a piece of info to a record in our database. Turns out some entirely separate service is connecting to our DB read-only slave and running queries on it without our knowledge, instead of going through an API endpoint that we’ve sanctioned. I’m torn between telling their current solution to gently caress itself and adding a real API call, and just adding onto the pile of  so I can move on.
|
|
#
?
Oct 3, 2019 18:41
|
|
|
necrobobsledder posted:Sadly, that’s how we got Atlassian products. My team just switched to Jira. Not liking it so far.
|
|
#
?
Oct 3, 2019 19:15
|
|
|
Ither posted:My team just switched to Jira. Not liking it so far. If you do find someone who likes it, let us know.
|
|
#
?
Oct 3, 2019 20:12
|
|
|
I had a 6-year gap in between using Jira for anything. When, specifically, did the UI turn into such a spectacularly awful shitheap?
|
|
#
?
Oct 3, 2019 21:40
|
|
|
Bit by bit, every couple of months, of course. Every tweak they release is obviously worse, but gotta keep paying the frontend team!
|
|
#
?
Oct 3, 2019 21:42
|
|
|
The worst changes were over the past year. Specifically the whole "new jira" that removed the ability to link directly to issue comments or type into a comment box without rendering falling behind
|
|
#
?
Oct 3, 2019 21:54
|
|
|
Need different issue types for different groups/organisations in Jira Service Desk? Tough. Hope you enjoy creating new projects. 
|
|
#
?
Oct 3, 2019 22:29
|
|
|
I've been using Jira for so long I don't believe that anything else exists.
|
|
#
?
Oct 3, 2019 22:43
|
|
|
Pollyanna posted:Got a ticket to add some functionality to match a piece of info to a record in our database. Turns out some entirely separate service is connecting to our DB read-only slave and running queries on it without our knowledge, instead of going through an API endpoint that we’ve sanctioned. Change the schema.
|
|
#
?
Oct 4, 2019 00:09
|
|
|
Change the password
|
|
#
?
Oct 4, 2019 00:27
|
|
|
We use pivotal tracker where I work. Everyone on my extended team hates it and misses Jira. I have more experience with Pivotal Tracker and kind of like it. It might be a comfort thing.
|
|
#
?
Oct 4, 2019 00:56
|
|
|
arbybaconator posted:We use pivotal tracker where I work. Everyone on my extended team hates it and misses Jira. I have more experience with Pivotal Tracker and kind of like it. It might be a comfort thing. All of it is equally dumb.
|
|
#
?
Oct 4, 2019 01:28
|
|
|
The jira thing that really grinds my gears is multiple markup syntaxes for the same boxes depending on what dialog you’re viewing them from. Some UI views use the old curly brace stuff while others use markdown loving pick one
|
|
#
?
Oct 4, 2019 01:30
|
|
|
|
| # ? May 17, 2024 10:15 |
|
|
Markdown supremacy
|
|
#
?
Oct 4, 2019 05:15
|
|