|
NovemberMike posted:Honestly, I just wanted you to give a lay definition of stochastic process and try to explain how hiring is one. Hmm, that was an inexplicably hostile way of "just asking" for a definition.
|
#
?
Jun 19, 2018 17:34
|
|
|
|
| # ? May 10, 2024 18:14 |
|
|
prisoner of waffles posted:Hmm, that was an inexplicably hostile way of "just asking" for a definition. It's just loving annoying when people try to use big words to seem smart and they're wrong. He's basically trying to say that when you filter on a population you have to worry about both the false positive and false negative rate, and the false negative rate is important to consider when you're looking at discrimination. That's a bit unsupported, but it's not obviously wrong. The problem is that he just used a bunch of other random words. A stochastic process is a random variable plotted onto a line (usually a time series). Think a stock history, or your blood pressure. Hiring isn't typically a time series, so calling it a stochastic process is very confusing and you don't typically filter on a stochastic process so you don't really talk about selectivity or specificity. Using words like that forces me to sit down and actually think through the a stupid comment rather than just laugh at it and move on.
|
|
#
?
Jun 19, 2018 17:53
|
|
|
Keetron posted:I wasn't kidding, just send me a PM and I will ship you a bunch of stroopwafels and other local foods. Thanks, vriend.  So I don't post too much about non-development stuff, I'm currently trying to break up a 300-line function so I can get some test coverage on it. It's taking the XML response from an API call (well, several that are made in one request) and parsing the data out into stuff our frontend can display. Parts of the function wisely select elements via Groovy's version of an XPath expression. Other parts just grab all elements with a certain tag, no matter where in the response they came from. Since this function mashes several API calls into the same request, I'm understandably concerned by this! Also, we just got the weekly email for ordering office supplies and it's been upgraded with a fancy background and new clip art, but now uses Courier, for some reason!
|
|
#
?
Jun 19, 2018 17:55
|
|
|
NovemberMike posted:https://www.ncbi.nlm.nih.gov/pmc/articles/PMC4557354/ You also claim that whiteboarding is basically an IQ test. If it is such a thing (I am extremely doubtful and you have given zero reason for thinking this), and there is a correlation between whiteboarding performance and job performance (your evidence here is that it's proprietary, but totally real). Let's suppose the evidence actually exists: this ignores that Facebook, Google, Microsoft, etc. all require strong whiteboarding skills to be hired, and they won't be hiring people with poor whiteboard performances in most cases. So, they aren't gathering great data anyway. This falls far from anything that validates whiteboarding as a hiring process, in any event. Maybe whiteboarding is a good process. But the evidence you've provided is pretty weak.
|
|
#
?
Jun 19, 2018 18:08
|
|
|
CPColin posted:Thanks, vriend. What's y'alls standard coverage rate? I'm curious what "normal" shops shoot for. I'm trying to re-write a front end app and it's currently hell because of a couple different factors: I'm not allowed to write any css (only allowed to use pre-built css classes from a template boss bought for $25), I have to stick with the current "design" standard of how we write out the html etc, and I'm also currently being blamed for the way our standard HTML pages look and work, even though it's 95% exactly what he wrote and approved in December. His response when I ask questions is to tell me to go read all the CSS and less files the template came with and "truly understand" what it does.
|
|
#
?
Jun 19, 2018 18:08
|
|
|
Shirec posted:What's y'alls standard coverage rate? I'm curious what "normal" shops shoot for. Depends on the language. With Python it's 100% but a bunch of the tests are weak and only confirm that the python syntax is fine. With most languages 70% should be about right. Ghost of Reagan Past posted:You claim that IQ is correlated with job performance. The article claims the evidence is murky and is full of caveats, and that there isn't a strong correlation at all. The article also urges caution in inferring from any correlation between IQ and job performance to the validity of IQ tests. I am not going to read the full meta-analysis but the authors seem skeptical that we can draw any strong conclusions from any statistical correlations that emerge. I don't support using IQ testing because of potential racial bias so I gave you a critical article. It still admitted a moderately strong correlation, it just criticizes other studies that attempt to imply a causation. NovemberMike fucked around with this message at 18:26 on Jun 19, 2018 |
|
#
?
Jun 19, 2018 18:12
|
|
|
NovemberMike posted:It's just loving annoying when people try to use big words to seem smart and they're wrong. He's basically trying to say that when you filter on a population you have to worry about both the false positive and false negative rate, and the false negative rate is important to consider when you're looking at discrimination. That's a bit unsupported, but it's not obviously wrong. so if he had more precisely said that hiring is an "inferential process with uncertainty" you wouldn't be so hostile?
|
|
#
?
Jun 19, 2018 18:20
|
|
|
Shirec posted:What's y'alls standard coverage rate? I'm curious what "normal" shops shoot for. As for test coverage, it depends on the repo. Some of our code is really untestable because people wrote bad code a few years ago, so one repo gets about 30%. Two of the repos I'm primary maintainer on are around 80% and I don't approve pull requests that don't have test coverage. One of those repos has an extensive integration test suite. That feels healthy to me, but I also wanted to make sure nobody touched one without my approval, so I aimed for high test coverage. Some smaller repos don't have any unit tests, but they do have integration tests.
|
|
#
?
Jun 19, 2018 18:21
|
|
|
Shirec posted:What's y'alls standard coverage rate? I'm curious what "normal" shops shoot for. I can't answer from the perspective of a "normal" shop because this isn't one and I failed to suss out this information while I was interviewing. I'm replacing a sole developer who has been maintaining a house of cards for the past twelve years without, as far as I can tell, writing more than half a dozen tests in all that time. I'm desperately trying to get some coverage going so I have some confidence that I'm not ruining everything. (There's no QA department or established set of functional testing standards, either.) It was so obvious that my previous job, a four-month stint last summer, was a dead-end that I didn't more aggressively try to figure out the state of the code around here before accepting the job. The first bullet point in the overly long job description says, "Develops new features and maintains existing applications as part of the information technology team. Writes full stack Java based web application software with RESTful services with SOA approach, as well as JUnit tests as part of TDD methodology." Never mind that: I'm the only developer on the team now, "Java-based" means "Grails," I haven't encountered RESTful or SOA anything, and it's painfully obvious TDD was not ever used around here. Whatever, I can put in a year or so of trying to clean this poo poo up before bailing, unlike that four-month job. This is definitely career poison if I stick around for too long, though. Possibly the only thing that could save it would be if my boss found the budget for a few student developers and I could get team lead experience, but the amount of development work is so scant, I don't think we could justify that.
|
|
#
?
Jun 19, 2018 18:23
|
|
|
prisoner of waffles posted:so if he had more precisely said that hiring is an "inferential process with uncertainty" you wouldn't be so hostile? If it didn't trigger my "I used the javascripts to hack the nsa" sense then sure.
|
|
#
?
Jun 19, 2018 18:29
|
|
|
Shirec posted:What's y'alls standard coverage rate? I'm curious what "normal" shops shoot for. Depends on the shop. My previous place (java) had an 80% target, which was dumb. We generally hovered around 75-79 (including some really dumb coverage-increasing hacks), with ~60% in some of our smaller libraries that had a lot of POJOs (small data storage classes, no functionality to test)
|
|
#
?
Jun 19, 2018 18:39
|
|
|
CPColin posted:I can't answer from the perspective of a "normal" shop because this isn't one and I failed to suss out this information while I was interviewing. I'm replacing a sole developer who has been maintaining a house of cards for the past twelve years without, as far as I can tell, writing more than half a dozen tests in all that time. I'm desperately trying to get some coverage going so I have some confidence that I'm not ruining everything. (There's no QA department or established set of functional testing standards, either.) Ah that makes more sense why you have a function mish mashing a bunch of API calls together then. Woosh, that sounds like an incredibly bad knot to untangle. I've actually only ever done stuff REST style, what does it look like when it's not?  Also interesting to the rest of y'all! We had 87% on everything (I think we're at 82% now) for a long while and had the most insanely ludicrous unit tests to try and hit some stuff (we were also required to have like two-three levels of catches on each function so bundles of fun trying to get the second layer to error but not the first).
|
|
#
?
Jun 19, 2018 18:44
|
|
|
Shirec posted:Ah that makes more sense why you have a function mish mashing a bunch of API calls together then. Woosh, that sounds like an incredibly bad knot to untangle. I've actually only ever done stuff REST style, what does it look like when it's not? I don't even know why that's in the job description at all! I haven't seen any applications around here that would need to expose an API, RESTful or otherwise. Edit: I'm trying to shoot for pretty high unit test coverage on the new stuff I write, whenever possible, with the exception of stuff like "make sure this mutator mutates the object." I also want to get good integration test coverage, since there's no QA around here, but I'm being severely hindered by the structure of the existing code and the fact that some of the third-party stuff our code touches either has no Test environment at all or one with vastly incomplete data. CPColin fucked around with this message at 18:53 on Jun 19, 2018 |
|
#
?
Jun 19, 2018 18:47
|
|
|
Our Sonar has a hairtrigger at a mandatory 93% coverage or else no deploy to prod is possible. We are a java shop that uses Lombok, something Sonar has trouble understanding. This leads to a lot of //NOSONAR comments at the end of lines. However, the automated integration tests count against test coverage, so tests that spin up Spring Boot and then use RestAssured to talk to the API's will increase test coverage. You guessed it, most of the tests are Integration tests. Which are slow, a full JUnit run takes up to 60 seconds on some repo's. These are supposed to be microservices, so it is not like we are running 1000s of unit tests or anything. Some suites have a little over 50 tests and take 40 to 50 seconds and completely use my laptop. In contrast, a friend I respect for his skills has a set of 900 unit tests that take a little under a second to run. But yeah, he works on core eBay systems. Oh, I forgot to mention the Sonar is departmental centralised, there is no way to avoid that. Yay big finance. Still, the last two weeks I have been modifying microservices and essentially rewired the data flow to enable more and faster search options. And everyone was cool with that as long as it would spit out the desired results (it does not yet but will very soon). Today was hard because it turned out that deploying to Prod also deploys to Test. The same Test that normally contains the development branch for all the microservices (each on their own instances, pretty cool). So unexpected results could be either your code not working or the Master branch overwrite of the code you expect that would behave very different. Keetron fucked around with this message at 19:00 on Jun 19, 2018 |
|
#
?
Jun 19, 2018 18:55
|
|
|
CPColin posted:I don't even know why that's in the job description at all! I haven't seen any applications around here that would need to expose an API, RESTful or otherwise. Probs put together as a wishlist and by someone who didn't actually know what was going on then, I'd say. The dev you replaced, was he forthright about what a mess it was, or was he obfuscating it? Does your boss know enough to know what stuff "should" look like? And it's just you? That sucks, I really like collaborating with others (not that I'm allowed to anymore  )Man, to your edit. Good on you for trying to go the right way going forward. I had an interview yesterday with a company, and when the guy explained how their teams worked, I was so floored by how amazing and healthy it sounded I almost couldn't handle it. Engineers/Devs are left alone and not pulled into needless meetings, they pull from product managers rather than get pushed to, and deadlines aren't set by customers. My favorite part was when he said that anyone trying to tell you they can plan out deadlines more than 6 months away is full of poo poo. 
|
|
#
?
Jun 19, 2018 18:56
|
|
|
CPColin posted:I don't even know why that's in the job description at all! I haven't seen any applications around here that would need to expose an API, RESTful or otherwise. If you want pain in your world, introduce automated integration tests relying on multiple instances of your systems. If you want to bath in the horrors of hell, introduce automated integration tests that rely on a 3rd party test system to be online and match your data set. Bonus points if you do all this through the front-end using some flavour of Selenium.
|
|
#
?
Jun 19, 2018 19:04
|
|
|
Shirec posted:What's y'alls standard coverage rate? I'm curious what "normal" shops shoot for. 
|
|
#
?
Jun 19, 2018 19:07
|
|
|
Shirec posted:What's y'alls standard coverage rate? I'm curious what "normal" shops shoot for. It can very among normal shops. Minimally, hit the main business logic for each use case. If I can just make it to Friday without having a coronary or strangling somebody before reaching the new job, it will be a miracle. Today's conversation:  : Hi, to facilitate a smooth knowledge transfer, I'm going to delete your build script and build by hand, because I can't be arsed to learn how that works.  : I showed you how to work them and explained why that's shooting yourself in the foot six times over, but whatever, I give up. Not my problem in a week. : Great! So, how do you build a jar in Eclipse? : You've been here for literal years. How have you been building jars? : I'll take the source files I changed and compare them with the decompiled classes to make sure the change is what I want, then I'll drag them in by hand. That's standard procedure. : But the repo...I keep it up to date. : Oh no, you can't trust the repo, people don't update it. You have to decompile, compare, and build by hand. Standard procedure. Also, he didn't take notes, and the client backs his standard procedure because he did it for years. Just gotta last until Friday.
|
|
#
?
Jun 19, 2018 19:24
|
|
|
Shirec posted:Probs put together as a wishlist and by someone who didn't actually know what was going on then, I'd say. The dev you replaced, was he forthright about what a mess it was, or was he obfuscating it? Does your boss know enough to know what stuff "should" look like? And it's just you? That sucks, I really like collaborating with others (not that I'm allowed to anymore When I asked the outgoing developer about the state of the backlog, he said something like, "Oh, yeah, it's got plenty of projects in it." I should have pressed him on that, because it turned out there was no formal backlog and I'm still trying to get him to write down all the poo poo our customers (other employees in the department) have asked for over the years. When I asked how the code looks, he gave what I took to be a standard, "Oh, you know, it could be better, we could have more tests. We're looking forward to you bringing your perspective." Once I started, he started making comments about how amazed he was that I wasn't sending him angry emails all the time. Lessons learned for my next interview, for sure! I've, meanwhile, been trying to be diplomatic when I talk to my boss about the state of the existing code, even though there's not really much reason for me to do so. I do try to mention often that TDD is in my job description and the existing code is not really compatible with TDD, so she doesn't start wondering why stuff has been taking a while. (Though posting on SA probably isn't helping that.) I think I work harder when I'm more answerable to fellow team members, too. Isolation will definitely be part of my reasons I give, whenever I leave. Hell, it was part of the reasons I gave in my interview when they asked why I was leaving my previous job! But it's fine. I'm working on a college campus and all the students just went home, so there's no pedestrians trying to jump out in front of my bike for the next three months. The pizza-by-the-slice place is closed for the summer, too, so maybe I'll lose some weight!
|
|
#
?
Jun 19, 2018 19:28
|
|
|
Shirec posted:Ah that makes more sense why you have a function mish mashing a bunch of API calls together then. Woosh, that sounds like an incredibly bad knot to untangle. I've actually only ever done stuff REST style, what does it look like when it's not? GraphQL and RPC would be two big non-REST API styles.
|
|
#
?
Jun 19, 2018 19:31
|
|
|
Shirec posted:What's y'alls standard coverage rate? I'm curious what "normal" shops shoot for. Code coverage is meaningless, so "shooting for" any particular number is awful, and it's doubly awful if you have a CI process that rejects PRs that don't meet certain coverage requirements. All code coverage can tell you is what isn't tested. It doesn't tell you that you're testing the right things, that the tests are good/valid, or that new (good, valid) tests are being added routinely along with new code. Knowing what isn't tested is good, but only when taken with context and analyzed for whether there's value in testing it. Keeping an eye on the delta of code coverage can be useful (going down = we may not be writing enough tests, going up = we're probably writing enough tests), but it's still not meaningful in isolation, it's only meaningful with context and some interpretation.
|
|
#
?
Jun 19, 2018 20:06
|
|
|
Yeah all that. We have CI builds that fail when coverage goes down and then application owners can make a decision to either lower the coverage threshold or go yell at the dev to write the tests for their code they should've done. Increasing the target is more difficult and relies on app owners to keep an eye on it over time. It's a good checkpoint for us, but our dev team made a conscious decision to require tests for new functionality (and bug fixes if it makes sense) and this was one way of enforcing it. Maybe it doesn't make sense for you. When we look to retrofit an app with terrible coverage, we start with whatever % the code has right now. We do a little analysis on level of effort to get the important functionality covered. That effort needs to weigh against other priorities like ongoing feature work. We also consider how vital the application is, how many bugs it's in, and how actively it's being developed. Then we figure out ways to slip test writing into new feature development or create separate work items and sprinkle them out over time.
|
|
#
?
Jun 19, 2018 20:49
|
|
|
Shirec posted:What's y'alls standard coverage rate? I'm curious what "normal" shops shoot for. 0% Well, that's not true. We have about a thousand lovely integration tests that no one ever runs or cares about, except (1) when one fails because they didn't deploy a change to the test DB soon enough and (2) when one of the tests that randomly generate test data fails (fix the underlying issue? Nah, just rerun it!). A full test run takes 10 mins or so, because the first person to write any tests apparently hadn't heard of DB transactions, so each test needs to clean up a ton of tables. Everyone just copied that pattern.
|
|
#
?
Jun 19, 2018 21:50
|
|
|
Kung-Fu Jesus posted:Then we figure out ways to slip test writing into new feature development or create separate work items and sprinkle them out over time. IMHO this is the best reason to implement TDD, even for a short time. Having test writing be simultaneous with feature development means you can't "run out of time" to test later on.
|
|
#
?
Jun 19, 2018 21:51
|
|
|
I'm reviewing a unit test right now because at some point, the rest of the team decided, without telling me, to implement extra checks on the API calls (but not all of them, haha, that would be ridiculous) so my stuff is failing in new and exciting ways. Scrolling through for this api's unit test, one test has ~200 lines of assertions. edit: Ah and to earlier, I like the organic way of handling it, that seems sensible and more what testing should be, which is what New Yorp New Yorp and Kung-fu Jesus' seemed to be Shirec fucked around with this message at 22:06 on Jun 19, 2018 |
|
#
?
Jun 19, 2018 22:03
|
|
|
I'm still breaking up that function with all the API calls and I ran into two flags that seemed pretty straightforward, but I couldn't find an API response in the database that matched the first one. Turns out, we're parsing these flags out of the XML and storing them in our frontend objects, but neither flag is ever actually read by anything. And the reason I couldn't find a response for the first flag is because we never actually request its value from the API. So I'm not covering these flags with a test and instead leaving a task in the backlog to get rid of them! Whee?
|
|
#
?
Jun 19, 2018 23:10
|
|
|
NovemberMike posted:It's just loving annoying when people try to use big words to seem smart and they're wrong. He's basically trying to say that when you filter on a population you have to worry about both the false positive and false negative rate, and the false negative rate is important to consider when you're looking at discrimination. That's a bit unsupported, but it's not obviously wrong.
|
|
#
?
Jun 19, 2018 23:33
|
|
|
Ghost of Reagan Past posted:Three fingers. There isn't a single standardized hiring process for Engineering, and we could probably debate the merits and drawbacks all day. Different fiefdoms within Engineering sometimes do their own thing, and at the time I was at the vanguard of trialling out a totally new hiring process with more extensive phone screens and HackerRank and stuff like that. When I interviewed back in the Dark Ages, I spent a lot of time writing Python longform on notepads. What were you interviewing for, out of curiosity? Hughlander posted:Do you provide that feedback upwards about the quality of the candidates making it past the recruiters to the phone screen? We have some recruiter tech screen questions which are basically absolute right / wrong answers and the recruiter is listening for things like “Are you googling it?” “Did you phone a friend?” And transcribe the answer Incase they’re not sure if it’s right or wrong and the answer is what’s sent to the person doing the tech phone screen of, “Do you want to continue with this person here’s resume and screen answers.” It takes 5-10 minutes of time but it’s better than wasting 60 minutes scheduled on someone who can’t buzz the fizz. I did pass it upward and I think the frontline recruiters started to adjust what they were doing, because the quality of the candidates got less worse after a while. It wasn't always great, but at least they'd get past fizzbuzz and then faceplant on determining if something is a valid IPv4 address. I also managed to extract an important concession, which is they stopped telling the candidates the phone screen would be 60 minutes (meaning I had to sit there and freestyle until the scheduled end no matter how useless they were) and instead started saying 30-60 minutes, so I could eject sooner if it was not going anywhere.
|
|
#
?
Jun 20, 2018 00:21
|
|
|
NovemberMike posted:If you want the whiteboard correlation, it's basically similar but the datasets are proprietary so you'd have to join a big company that does them like Facebook, Google, Microsoft etc and get onto a hiring committee. It's basically the same though, not a super strong correlation but it's there. Are these companies getting valid IQ measurements of their employees? Are they only considering the people who were hired and not those who didn't make the cut? How do they validate whiteboard interviews as an instrument?
|
|
#
?
Jun 20, 2018 00:33
|
|
|
ultrafilter posted:Are these companies getting valid IQ measurements of their employees? Are they only considering the people who were hired and not those who didn't make the cut? How do they validate whiteboard interviews as an instrument? No, these companies aren't getting IQ measurements because that's illegal.They're tracking interview performance vs on the job performance. Google stopped asking brain teasers because they didn't correlate well to on the job performance. They haven't stopped whiteboard interviews because those do correlate well.
|
|
#
?
Jun 20, 2018 01:49
|
|
|
chutwig posted:There isn't a single standardized hiring process for Engineering, and we could probably debate the merits and drawbacks all day. Different fiefdoms within Engineering sometimes do their own thing, and at the time I was at the vanguard of trialling out a totally new hiring process with more extensive phone screens and HackerRank and stuff like that. When I interviewed back in the Dark Ages, I spent a lot of time writing Python longform on notepads. 
|
|
#
?
Jun 20, 2018 01:51
|
|
|
Shirec posted:What's y'alls standard coverage rate? I'm curious what "normal" shops shoot for. Formally we basically only have a Jenkins setup that’ll yell at you if the project doesn’t build. And... yeah, that’s mostly it.
|
|
#
?
Jun 20, 2018 03:10
|
|
|
How do you count coverage of a loop with data-driven count of iterations?
|
|
#
?
Jun 20, 2018 03:23
|
|
|
JawnV6 posted:How do you count coverage of a loop with data-driven count of iterations? It literally just checks if a line of code is executed. Each line of the loop counts once.
|
|
#
?
Jun 20, 2018 03:41
|
|
|
JawnV6 posted:How do you count coverage of a loop with data-driven count of iterations? that's a matter for assertions, code coverage is just "did we execute this line of code or not?"
|
|
#
?
Jun 20, 2018 04:03
|
|
|
Though the true hotness is branch coverage. Or just Sqlite in general.
|
|
#
?
Jun 20, 2018 06:41
|
|
|
Shirec posted:I'm reviewing a unit test right now because at some point, the rest of the team decided, without telling me, to implement extra checks on the API calls (but not all of them, haha, that would be ridiculous) so my stuff is failing in new and exciting ways. Scrolling through for this api's unit test, one test has ~200 lines of assertions. Over/under on Shirec's manager telling the rest of the team to add extra checks to Shirec's code because it is "clearly poor quality and Shirec just doesn't understand development and should be an analyst doing people person girl stuff and faaaaaaaaaaart."
|
|
#
?
Jun 20, 2018 07:20
|
|
|
Shirec posted:one test has ~200 lines of assertions.  Also, wtf, if they wrote unit tests isn't it their job to make sure those unit tests pass? And if they're not unit tests for your stuff itself, how are those client API unit tests causing your stuff to fail? Are they actually some kind of integration test or... I don't even know what's going on over there. Zaphod42 fucked around with this message at 07:32 on Jun 20, 2018 |
|
#
?
Jun 20, 2018 07:29
|
|
|
Our current coverage is ~97%, and we have our CI set to reject commits that would either decrease the coverage by more than 1%, or commits that are less than 90% tested.
|
|
#
?
Jun 20, 2018 09:45
|
|
|
|
| # ? May 10, 2024 18:14 |
|
|
Xarn posted:Our current coverage is ~97%, and we have our CI set to reject commits that would either decrease the coverage by more than 1%, or commits that are less than 90% tested. Why? I assume you're building something more interesting than a dtandard web app with thousands of lines of DTO mapping.
|
|
#
?
Jun 20, 2018 10:53
|
|