|
Jesus... I have worked at two large corporations and everybody sends me blank one-on-one meetings. The time I got laid off was on Big Layoff Day and they just swooped by first thing in the morning. That being said, I have had to tell managers not to do that because the first five minutes of that kind of meeting is lost on an employee recovering from the sudden cardiac arrest.
|
#
?
Dec 9, 2017 17:20
|
|
|
|
| # ? May 9, 2024 23:30 |
|
|
Yeah, I don't get what's so hard about crafting email subject lines. For years, when we would get an email that was just an employee's name, it meant that employee quit or got fired. Then we started occasionally getting some that were announcements of promotions. Or "Org update" to announce people were shuffling around, but sometimes to announce that four people just got laid off. It's like, just make the email subject say, "Congratulate X on her promotion!" How hard is that?
|
|
#
?
Dec 9, 2017 17:26
|
|
|
People feel the need to dance around major decisions they’ve made, yet they do that with literally clickbait titles and the implication puts people on edge. It’s dumb.
|
|
#
?
Dec 9, 2017 21:36
|
|
|
I had my first taste of coding/algo challenges being part of the interview process and boy it did not go well. 
|
|
#
?
Dec 10, 2017 02:55
|
|
|
HardDiskD posted:I had my first taste of coding/algo challenges being part of the interview process and boy it did not go well. What were you asked? I've always been asked one of: reverse a string, sort a list, traverse a tree. Basic stuff.
|
|
#
?
Dec 10, 2017 03:14
|
|
|
Clanpot Shake posted:What were you asked? I've always been asked one of: reverse a string, sort a list, traverse a tree. Basic stuff. I saw the palindrome and biggest drop problems a lot.
|
|
#
?
Dec 10, 2017 03:56
|
|
|
Nah it wasn't like that, it was bullshit in the vein of this (not the exact same exercise). Granted, that level of exercise it's probably not hard on the grand scheme of things, especially if you are used to doing these. But coming from the last interview coding exercise I had (divide up a huge text into tweets) I wasn't prepared at all. Also my idea of coding at home is doing fun side projects solving problems (ok, let's be real, "problems"), and resulting in more tangible (for a lack of a better word) software, rather than doing seemingly pointless exercises that don't *do* anything. (except helping get me a new job, apparently  )
Space Kablooey fucked around with this message at 04:30 on Dec 10, 2017 |
|
#
?
Dec 10, 2017 04:11
|
|
|
Don't worry about it too much, it's very arbitrary and everyone has a tough time dealing with it in the beginning. Best thing to do IMO is to identify which problem was covered in the interview and practice it a couple times - maybe there's a similar one you can find on Google? But yeah, don't get too hung up on those cause they really don't reflect your day-to-day work. It sucks to feel like you hosed up an interview because an algo question blindsided you though
|
|
#
?
Dec 10, 2017 05:54
|
|
|
Ither posted:When a fixing a bug, when do you band aid and when do you burn everything down and start from scratch? Depends on how much time and testing is allocated for it, how much of the product is impacted by it, how self-contained the code in question is, how much you really need to do to fix the bug, and how well you understand the feature in question as well as its history. Burning it all down introduces risk - since you're rewriting the whole thing, there's plenty of opportunities to write whole new bugs that didn't exist before. You really have to look at the context. I tend to save rewrites for when I'm working on new feature development - during bugfixing time, I try to minimize the impact of our fixes, especially since our processes are kind of lackluster (ancient source control program, no branches, manual deployments and patches and testing)
|
|
#
?
Dec 10, 2017 08:18
|
|
|
HardDiskD posted:Nah it wasn't like that, it was bullshit in the vein of this (not the exact same exercise). That’s a pretty simple algos question to see if you can write a simple parser? There are some BS questions that get asked around, but most of them rely on the user to have some special math knowledge (special here meaning a maths undergrad probably won’t have heard of it) that usually somehow relates to the master/PhD thesis of the asker. The posted question only requires being able to find numbers that are bigger than the numbers around them, doing a prime factorization, and walking the list of combinations of those prime factors. Hardest mathy thing there is a prime factorization, which is taught in high school? There’s definitely jobs where those aren’t necessary, but I’ve also had jobs where those things were fundamental. You probably even get a pass at factoring the primes in O(bad) by making a joke about encryption. If the interviewer expects you to independently discover fermat’s factorization method on the fly then they’re a bad interviewer. I agree that working on tangible problems is more fun, but if that’s the level of problem you’re hung up on you’ll probably have issues in a lot of interviews.
|
|
#
?
Dec 10, 2017 10:46
|
|
|
leper khan posted:That’s a pretty simple algos question to see if you can write a simple parser? I disagree, that's a pretty terrible question to ask. Even disregarding that most coding problems discriminate against certain groups of applicants, a problem that needs more than a DIN A4 sheet of paper to be asked is a bad problem to use in an interview.
|
|
#
?
Dec 10, 2017 12:04
|
|
|
BabyFur Denny posted:I disagree, that's a pretty terrible question to ask. Even disregarding that most coding problems discriminate against certain groups of applicants, a problem that needs more than a DIN A4 sheet of paper to be asked is a bad problem to use in an interview. If they rewrote the array horizontally it would fit nicely on an 8.5x11” sheet.
|
|
#
?
Dec 10, 2017 13:26
|
|
|
leper khan posted:That’s a pretty simple algos question to see if you can write a simple parser? I don't disagree with your conclusion but that is not the exact question that I was asked.
|
|
#
?
Dec 10, 2017 14:02
|
|
|
leper khan posted:That’s a pretty simple algos question to see if you can write a simple parser? The trick there is realising you have to do some sort of prime number bullshit. How many people can honestly say they have had to deal with prime numbers in their day to day work?
|
|
#
?
Dec 10, 2017 21:12
|
|
|
redleader posted:The trick there is realising you have to do some sort of prime number bullshit. How many people can honestly say they have had to deal with prime numbers in their day to day work? you don't have to do any prime factorization at all. 1. calculate something like "nearest peak at or to the right of this idx" as an array (O(n)) and track the # of peaks in the input (O(n)) 2. iterate from i=1 to the # of peaks in the input (every other number could be a peak so up to n/2 searches) 3. for any i that doesn't evenly divide the input, skip (so ex. for a prime length array do a constant amount of work n-2 times -> O(n)). 4. for any i that does divide the input, use your precalculated nearest peak to check the start of each bucket and make sure the nearest peak to the right is in that bucket.
|
|
#
?
Dec 10, 2017 23:29
|
|
|
These questions suck but they are usually designed to see how you react to complicated problems and pressure and to see how you solve them. Do you ask for help/collaborate with the people in the room (good), do you rattle it out quickly on your own (this person interviews a lot, maybe good), or do you stammer and say "um..." and give up (bad)?
|
|
#
?
Dec 11, 2017 15:10
|
|
|
Considering that it was an over the internet test and I never really had looked for a job in ages, well.
|
|
#
?
Dec 11, 2017 16:28
|
|
|
Hey, so, I started a new feature branch for the stuff you’re working on and brought another engineer to work on changes that need to be done before you can do your stuff which I never told you about. I know the blog post I pointed you to says we do all our work in ticket-specific branches, but we want to deploy this, so we’re all gonna work off the same feature branch now. You’re gonna have to abandon your
|
|
#
?
Dec 11, 2017 17:14
|
|
|
Pollyanna posted:Hey, so, I started a new feature branch for the stuff you’re working on and brought another engineer to work on changes that need to be done before you can do your stuff which I never told you about. I know the blog post I pointed you to says we do all our work in ticket-specific branches, but we want to deploy this, so we’re all gonna work off the same feature branch now. You’re gonna have to abandon your The good news is that your feature branch apparently became the master.
|
|
#
?
Dec 11, 2017 17:27
|
|
|
Rocko Bonaparte posted:The good news is that your feature branch apparently became the master. No kidding. With this process, I’m just kind of counting up the time until I accidentally obliterate a massive chunk of work somehow.
|
|
#
?
Dec 11, 2017 17:30
|
|
|
So wait, how often do multiple people work on a single feature branch, and how do people coordinate pushes/pulls/merging? Apparently this is not as uncommon as I thought, or is at least some sort of workflow? Am I just too used to the Github-like model of pull requests?
|
|
#
?
Dec 11, 2017 19:24
|
|
|
Pollyanna posted:So wait, how often do multiple people work on a single feature branch, and how do people coordinate pushes/pulls/merging? Apparently this is not as uncommon as I thought, or is at least some sort of workflow? Am I just too used to the Github-like model of pull requests? I've done this; it's painless as long as everyone is working on different parts of the code base. Helpful when it's a scenario where, say, I'm modifying backend web services and the other person is working on the front-end code that calls those services (yes these are projects with both layers in one solution, let's not go down that rabbit hole). If people are stepping all over each other and touching the same code at once, it's a nightmare. Though to be fair if that's happening with the pull request model it also tends to be a nightmare. As with many things in this industry, the technical minutiae are less relevant than the people. If people aren't communicating, you're hosed and the technology isn't going to save you.
|
|
#
?
Dec 11, 2017 19:56
|
|
|
Pollyanna posted:So wait, how often do multiple people work on a single feature branch, and how do people coordinate pushes/pulls/merging? Apparently this is not as uncommon as I thought, or is at least some sort of workflow? Am I just too used to the Github-like model of pull requests? I'm coming out of an era where we did this a lot. We didn't merge stuff into master until the whole feature was done. Then, mid way through the latest feature we wanted to start chunking out the deployments. So I took it as an opportunity to learn how to generate git patches and apply them. That worked pretty well, but then it's important to merge the patched master branch into your feature branch and resolve the conflicts. Then, when your feature branch finally makes it out to the wild the conflicts are solved. We aren't going to do this so much anymore, no more feature branches living for 1 or 2 quarters while we build all the functionality. These are big features btw, huge. Instead, we are gonna try to Lean it and Pheonix Project it and deploy small chunks once a week or every two weeks, whatever makes sense.
|
|
#
?
Dec 11, 2017 20:04
|
|
|
Pollyanna posted:So wait, how often do multiple people work on a single feature branch, and how do people coordinate pushes/pulls/merging? Apparently this is not as uncommon as I thought, or is at least some sort of workflow? Am I just too used to the Github-like model of pull requests? Why can't you make sub branches of your feature branch?
|
|
#
?
Dec 11, 2017 20:18
|
|
|
Pollyanna posted:So wait, how often do multiple people work on a single feature branch, and how do people coordinate pushes/pulls/merging? Apparently this is not as uncommon as I thought, or is at least some sort of workflow? Am I just too used to the Github-like model of pull requests? So, my office has a similar workflow that works nicely with bitbucket PRs (which I assume are similar to github PRs) Because we do two releases a week to SIT, we try and release features complete rather than trickling them into the trunk. We'll create a feature branch named after the feature, and then branch off/PR to that branch instead of the trunk. Individual stories still get reviewed and QA'd, then when we release the feature we submit a big fuckoff PR to the trunk that should already be fairly competent and not require a ton of extra review. It works nicely enough for us and keeps merges pretty manageable e: this also has the added benefit of pre-SIT testers being able to grab snapshot builds from the feature branch
|
|
#
?
Dec 11, 2017 20:22
|
|
|
Pollyanna posted:So wait, how often do multiple people work on a single feature branch, and how do people coordinate pushes/pulls/merging? Apparently this is not as uncommon as I thought, or is at least some sort of workflow? Am I just too used to the Github-like model of pull requests?
|
|
#
?
Dec 11, 2017 21:29
|
|
|
Anyone else doing https://adventofcode.com/ ?
|
|
#
?
Dec 11, 2017 23:36
|
|
|
Skandranon posted:Why can't you make sub branches of your feature branch? Yeah, seriously. Just call that feature branch a a feature integration branch or something, have everyone create branches off of that, merge their branches into the integration branch, merge the integration branch into whatever branch it diverged from.
|
|
#
?
Dec 11, 2017 23:43
|
|
|
ChickenWing posted:Anyone else doing https://adventofcode.com/ ? I am now 
|
|
#
?
Dec 12, 2017 00:26
|
|
|
Pollyanna posted:So wait, how often do multiple people work on a single feature branch, and how do people coordinate pushes/pulls/merging? Apparently this is not as uncommon as I thought, or is at least some sort of workflow? Am I just too used to the Github-like model of pull requests? You are too used to github model. Find out now though if the preferred method is a merge commit or a rebase. My personal pereference is that you rebase master onto your branch and then merge the branch to master when done.
|
|
#
?
Dec 12, 2017 01:59
|
|
|
Many people don't realize you can open Github PRs to any branch, including other open PRs. You can change the base branch any time.
|
|
#
?
Dec 12, 2017 03:35
|
|
|
ChickenWing posted:Anyone else doing https://adventofcode.com/ ? Me! Its really fun, and since I'm doing it in ruby, I'm being reminded of the cool things I forgot you can do with it. I haven't done today's challenge yet because i'm coded out for the day.
|
|
#
?
Dec 12, 2017 03:40
|
|
|
Sedro posted:Many people don't realize you can open Github PRs to any branch, including other open PRs. You can change the base branch any time. I think this is the crucial thing. People don't understand how branching works, or how flexible branches are.
|
|
#
?
Dec 12, 2017 03:50
|
|
|
ChickenWing posted:So, my office has a similar workflow that works nicely with bitbucket PRs (which I assume are similar to github PRs) Where do you compile, deploy and run the feature branch builds for testing purposes?
|
|
#
?
Dec 12, 2017 08:51
|
|
|
a foolish pianist posted:I think this is the crucial thing. People don't understand how branching works, or how flexible branches are. Many people don't understand how Git works in general. Another thing I encountered recently is a teamlead mandating a new workflow and many team members having no idea what he wants (so I set up a Git basics workshop).
|
|
#
?
Dec 12, 2017 08:53
|
|
|
Keetron posted:Where do you compile, deploy and run the feature branch builds for testing purposes? For our local testing, we have automatic per-commit Jenkins builds, then Jenkins jobs that deploy to our QA AWS instances. For clientside pre-SIT testing, we have a Jenkins job that runs every 15 mins and mirrors our repo to their side so that they can do local builds (something about not wanting to be FUBAR if they decide to drop us, I don't remember the exact explanation, but regardless we can't just give them our nexus artifacts for testing). For SIT, we just do full releases twice a week.
|
|
#
?
Dec 12, 2017 15:17
|
|
|
I stand corrected. Everything I’ve heard about non-PR/feature-ticket branch workflows has made them out to be utter nightmares. I mean, if it works it works, but it feels less...reliable, I guess? That and I’m not used to it. Edit: and the ultimate issue is the poorly communicated constant switching between ticket branches and feature branches anyway, so the point is kinda moot. Pollyanna fucked around with this message at 16:16 on Dec 12, 2017 |
|
#
?
Dec 12, 2017 16:12
|
|
|
Got a ticket to replace one piece of UI with two other indicators and I get dinged and a talking to from the team lead for not completely ripping out every bit of the now unused internal functionality from the codebase.  Am I just missing some sort of intuition that all other developers have or something?To clarify, the ticket just says “remove Old Thing icon” and doesn’t make mention of removing the entire functionality. Pollyanna fucked around with this message at 20:12 on Dec 12, 2017 |
|
#
?
Dec 12, 2017 20:09
|
|
|
Pollyanna posted:Got a ticket to replace one piece of UI with two other indicators and I get dinged and a talking to from the team lead for not completely ripping out every bit of the now unused internal functionality from the codebase. Possibly? How did the conversation go? If the lead is trying to instill in you that intuition, how would you rather have been talked to? It's not necessarily a bad thing.
|
|
#
?
Dec 12, 2017 20:11
|
|
|
|
| # ? May 9, 2024 23:30 |
|
|
Yeah, if they have certain expectations and didn't tell the newbie about them, that's probably on them. On the other hand, it can be a good instinct to see if the backend functionality can be ripped out when the frontend functionality that used it is ripped out. At my last job, I tried to get the rest of the team on board with at least writing down a reminder to file a clean-up ticket later and would gently remind people of that philosophy during code reviews. Of course, if the structure of the code is such that you can't easily tell when backend stuff is unused, that puts it back on the veterans to educate the newbie.
|
|
#
?
Dec 12, 2017 20:26
|
|