|
Iverron posted:It is ALWAYS best to ask a question or two about this at some point in the interview process. Probably the most important thing to remember is that you're interviewing them as much as they're interviewing you. It's incredible how many red flags you can get just by asking a few questions. If the answer to "when did you last take a vacation?" is "oh like >7 months ago" from every single person you talk to there that's a problem. Granted that's also a culture thing; some people are totally happy writing code 60 hours a week with no days off, ever.
|
#
?
May 20, 2017 03:06
|
|
|
|
| # ? May 15, 2024 05:51 |
|
|
Also, when talking about PTO/sick days, many states have laws that require employers to pay out any unused PTO when an employee quits. Of course, if you have unlimited (or rather zero defined) PTO, they don't have to pay you anything when you leave. It wouldn't surprise me if that combined with no defined PTO makes it easy to pressure people into not taking vacations was the real reason unlimited PTO took off in SV.
|
|
#
?
May 20, 2017 05:01
|
|
|
ToxicSlurpee posted:Granted that's also a culture thing; some people are totally happy writing code 60 hours a week with no days off, ever. I have a coworker that submitted 15 changes for review over the last weekend. I mentioned they had a busy weekend and they said "Yeah! I love it when I'm able to get so much stuff done!" Fortunately they're the exception rather than the rule.
|
|
#
?
May 20, 2017 05:57
|
|
|
Greatbacon posted:Also, when talking about PTO/sick days, many states have laws that require employers to pay out any unused PTO when an employee quits. At the place I worked it was the former -- they had 4 weeks, no pressure about vacation usage, and switched to unlimited after I told them they had to pay out my unused vacation a week or so before my last day. Which they didn't know!
|
|
#
?
May 20, 2017 18:43
|
|
|
Unlimited vacation is fine if you aren't working for tremendous assholes (in which case unhealthy PTO culture shouldn't be the first or only indication of that (and also you should not take that job/get a different job)). I've had unlimited vacation for past 2 jobs, I average about 3 weeks of real sustained vacations and 2 weeks worth of random days off. Protip: don't work for assholes
|
|
#
?
May 20, 2017 20:19
|
|
|
ultrafilter posted:I've seen at least one company with a minimum vacation policy, but that seems to be pretty rare. I've heard that BB will ask you questions if you don't use your vacation and basically tell you that you need to take them before you burn out completely. For the record, BB does 20 days per year (prorated if you start after the 1st of January) and you can roll over 5 into the next year. Sick days are unlimited within reason. We don't get a lot of standard holidays (no week between Christmas and NYE for example), we generally just close when the NYSE is closed.
|
|
#
?
May 21, 2017 03:21
|
|
|
I thought PTO = vacation + holidays? But it seems like some people are just using it as a synonym for vacation. Which is confusing.
|
|
#
?
May 22, 2017 12:31
|
|
|
In my mind, PTO refers specifically to time allotted to individual employees to choose when to take off, and it does not include company wide holidays. Not saying that's the definitive meaning, just that it is what I've always thought it meant.
|
|
#
?
May 22, 2017 14:44
|
|
|
I could use some advice. I've been at this job for about a month and hate it. It's super unorganized and the people that have been here for a while have, in my opinion, crazy views about software development in general. Nearly every file is 2,000+ lines of code, dependency injection is banned, nothing is unit tested, branching in source control is banned... I could go on. The people here are very adamant in not changing any of this either for existing or future development, since their stuff does work. I've already started sending my resume out to other places, but I'm wondering what the best way to approach discussing this place during interviews is, especially given the short amount of time I've been working here. Is it good enough to say it just wasn't a mutual fit? Should I go into any detail on any of this if asked about why I think that?
|
|
#
?
May 22, 2017 15:07
|
|
|
Culture fit works both ways. If they prod further you can maybe go into engineering practices, but it's usually bad form to muck rake into an applicants previous companies.
|
|
#
?
May 22, 2017 15:14
|
|
|
actionfiasco posted:I could use some advice. I've been at this job for about a month and hate it. It's super unorganized and the people that have been here for a while have, in my opinion, crazy views about software development in general. Nearly every file is 2,000+ lines of code, dependency injection is banned, nothing is unit tested, branching in source control is banned... I could go on. The people here are very adamant in not changing any of this either for existing or future development, since their stuff does work. I've already started sending my resume out to other places, but I'm wondering what the best way to approach discussing this place during interviews is, especially given the short amount of time I've been working here. Is it good enough to say it just wasn't a mutual fit? Should I go into any detail on any of this if asked about why I think that? Most shops will be fine with it as long as it's not a clear pattern on your resume.
|
|
#
?
May 22, 2017 15:52
|
|
|
Even my hyper paranoid employer just wants to know that you aren't planning on hopping again. As long as you're assertive about what you're looking for and that lines up with whatever X or Y company is offering, you should be able to cover that concern without much effort.
|
|
#
?
May 22, 2017 15:54
|
|
|
smackfu posted:I thought PTO = vacation + holidays? But it seems like some people are just using it as a synonym for vacation. Which is confusing. There isn't a consistent definition. Some places include holiday and sick time. Some don't.
|
|
#
?
May 22, 2017 16:07
|
|
|
actionfiasco posted:I've already started sending my resume out to other places, but I'm wondering what the best way to approach discussing this place during interviews is, especially given the short amount of time I've been working here. Is it good enough to say it just wasn't a mutual fit? Should I go into any detail on any of this if asked about why I think that? Badmouthing former jobs is a red flag for employers because they have no way to know if it's true or if you're just an rear end in a top hat. In this instance, I would use your "mutual fit" line and if pressed, follow up with something like "I didn't see any opportunity for growth at Acme, Inc" and then you can talk about how you're so excited for New Company because they are using technologies X and Y or something. The main idea is to keep anything negative short, objective, and vague. If the interviewer is smart, they can read between the lines.
|
|
#
?
May 22, 2017 17:09
|
|
|
actionfiasco posted:I could use some advice. I've been at this job for about a month and hate it. It's super unorganized and the people that have been here for a while have, in my opinion, crazy views about software development in general. Nearly every file is 2,000+ lines of code, dependency injection is banned, nothing is unit tested, branching in source control is banned... I could go on. The people here are very adamant in not changing any of this either for existing or future development, since their stuff does work. I've already started sending my resume out to other places, but I'm wondering what the best way to approach discussing this place during interviews is, especially given the short amount of time I've been working here. Is it good enough to say it just wasn't a mutual fit? Should I go into any detail on any of this if asked about why I think that? Aside from everything else, next time ask questions so that you find this poo poo out before you accept the job offer.
|
|
#
?
May 22, 2017 22:03
|
|
|
actionfiasco posted:I could use some advice. I've been at this job for about a month and hate it. It's super unorganized and the people that have been here for a while have, in my opinion, crazy views about software development in general. Nearly every file is 2,000+ lines of code, dependency injection is banned, nothing is unit tested, branching in source control is banned... I could go on. The people here are very adamant in not changing any of this either for existing or future development, since their stuff does work. I've already started sending my resume out to other places, but I'm wondering what the best way to approach discussing this place during interviews is, especially given the short amount of time I've been working here. Is it good enough to say it just wasn't a mutual fit? Should I go into any detail on any of this if asked about why I think that? This sounds hilarious and I want to hear more stories. And yeah, "mutual fit" is ok for HR, and mention of 2000 line files is fine for technical interviews if either of them even ask.
|
|
#
?
May 22, 2017 22:23
|
|
|
That's a troll right? "DI is banned" is incredible. Well done, sir.
|
|
#
?
May 22, 2017 22:35
|
|
|
actionfiasco posted:... the people that have been here for a while have, in my opinion, crazy views about software development in general. Nearly every file is 2,000+ lines of code, dependency injection is banned, nothing is unit tested, branching in source control is banned... I could go on. The people here are very adamant in not changing any of this either for existing or future development, since their stuff does work. There were also very few comments, which I found frustrating. But I heard the opinion many times that your code shouldn't need comments; if the code is readable, and everything is named well, then they are redundant and can be an impediment when they go out of date. The reality was different though, because what's well-named to some may be impenetrable to others.
|
|
#
?
May 22, 2017 23:50
|
|
|
I don't care if I have to commit all my code to a single file if the manner in which I work and the software I'm shipping is easy enough to work with others on and ship. People go really overboard with bikeshedding over lots of arbitrary standards, but going the other direction to reject almost all modern practices is impressive in its own way. Some of the best developers I've worked with never, ever used syntax highlighting in their editors because these folks believed that it encourages you to be sloppy and lazy. Doesn't mean I'm going to stop it, but I'm always interested in justifications for "standards" and whether the result is any good or not. Good engineering standards, like good managers, tend to make their value evident not so much on a day-to-day basis but when it's silently kept things from turning ugly. Anyone that's worked with Spring AOP for enough years will understand why DI could be banned at some shops. I don't care if things get autowired now, if I see more annotations than actual statements I know I'm in for a bad time.
|
|
#
?
May 23, 2017 01:17
|
|
|
minato posted:There were also very few comments, which I found frustrating. But I heard the opinion many times that your code shouldn't need comments; if the code is readable, and everything is named well, then they are redundant and can be an impediment when they go out of date. The reality was different though, because what's well-named to some may be impenetrable to others. Certain programmers claim that they don't need comments. It's a guarantee that they when they try to explain their own code they will get lost and won't know how things work.
|
|
#
?
May 23, 2017 01:57
|
|
|
lifg posted:Certain programmers claim that they don't need comments. It's a guarantee that they when they try to explain their own code they will get lost and won't know how things work. Comments are pretty bad, and you should strive to not need them. Document functions, interfaces, packages, objects, stuff like that (especially if your language generates docs out of these). Documenting lines or even blocks is almost always bad. 90% of the time comments either 1) explain your too clever code (bad, rewrite it less clever) 2) add nothing of value ('create a FooBar', 'here we check each Baz') 3) document something more complex ('why') that belongs somewhere more visible, and less likely to become obsolete/incorrect. (Just reviewed a job applicant's code who commented literally every single line of code  )
|
|
#
?
May 23, 2017 02:14
|
|
|
Comments are good and important, if your code is doing anything remotely complicated. A comment on getFoo() that says "returns foo" is doing nothing. A comment on generateBar() that says "retrieves a complete Bar from the database, recursively following links to get the complete relationship graph" is helpful. I shouldn't have to read the entire function to understand what it's doing and the major implications of calling it.
|
|
#
?
May 23, 2017 02:32
|
|
|
minato posted:This is how it works at Facebook, basically. Speed is valued over software quality. Which is fine when you're delivering cat pictures, not so much when you're writing medical / financial software. They didn't go so far as to ban DI, but it was discouraged. They don't do long-lived branches either (i.e. continuous integration) which I think is actually a good thing. The opposite is bad as well. I've worked with people who insist that everything must be done "The One True Way" with whatever design pattern they deem necessary. You spend two days writing code and 2 weeks refactoring it until they are satisfied so that some future theoretical enhancement that will never come is negligibly easier. As with all things there is a balance. Clean "perfect" code is nice, but not when it slows everything down to a crawl. Jose Valasquez fucked around with this message at 03:03 on May 23, 2017 |
|
#
?
May 23, 2017 03:01
|
|
|
VOTE YES ON 69 posted:Comments are pretty bad, and you should strive to not need them. We're going to disagree on this. It might be a function of different working environments (I've had bad ones), language expertise (Perl), or background (a lot of maintenance on contract-built applications, in Perl). These days I comment on blocks all the time. It functions as an abbreviation, explanation, and a parity check all in one. If I spend more than a second trying to understand a piece or block of code, I add a comment to make it faster for the next person.
|
|
#
?
May 23, 2017 04:04
|
|
|
VOTE YES ON 69 posted:Comments are pretty bad, and you should strive to not need them. What language do you write most of your code in?
|
|
#
?
May 23, 2017 04:10
|
|
|
Steve French posted:What language do you write most of your code in? At the moment go. But holds in any language I've seriously worked in: erlang, c#, python. Is your argument going to be that when you're bittwiddling poo poo at a low level comments are important? That's fine. Similarly, if I was writing APL, I would comment it heavily, because it's hard to read. There's absolutely reasons to write comments, it's just that the majority of comments are useless or even harmful. lifg posted:If I spend more than a second trying to understand a piece or block of code, I add a comment to make it faster for the next person. The problem with this is that comments are uncompiled, and deemphasized by everyone's editor (italics, greyed out, whatever). Comments become lies *so* quickly, unless you work with extremely disciplined people. What starts as a stronghold of sanity (document why it does it that way!) just turns into a misleading lie later, after whatever gets refactored and actually doesn't or doesn't need to work that way anymore. Entropy always wins, at least the compiler can check lots of it.
|
|
#
?
May 23, 2017 04:30
|
|
|
VOTE YES ON 69 posted:(Just reviewed a job applicant's code who commented literally every single line of code Like, hey, don't do this, obviously, but saying all comments are useless is just... bad. Reasons comments are cool and good: * They help me organize my thoughts and slow down to think about complicated sections. I've lost count of the number of times were I've gotten halfway through a comment and realized either my code is wrong, or it's too complicated and should be thought about again. * They break up a block of code, providing 'headers' for discrete sub-sections that don't necessarily deserve their own functions. It also helps someone reading your code after you skim and get a good high level summary of the steps or algorithm being implemented. This can help them fix your bugs faster, or prevent new ones by not implementing $NEW_WIDGET in the wrong place. * They explain weird choices or subtleties that aren't immediately obvious. If you've thought long and hard about it and there's really no choice but to build a sharp metal spike charged with 10,000 volts, at least be decent and warn the next adventurer of the clever trap you've laid. * Even if your code is, really, truly, a beautiful and perfect creation given to humans by divine inspiration, and needs no comments or explanation... the next person probably won't have your amazing skills as a legendary programming god. So be a good citizen and document it. Really, comments should be informative and useful metadata about your code you're communicating to a future engineer (either yourself or someone you'll never meet). Getting the right balance is as much a matter of skill and experience as not writing lovely code.
|
|
#
?
May 23, 2017 04:34
|
|
|
VOTE YES ON 69 posted:There's absolutely reasons to write comments, it's just that the majority of comments are useless or even harmful. This says more about the people and code you work with than it does about the validity of comments. Most code I've worked with has had accurate, helpful comments. In the rare situations where comments were misleading, out-of-date, or inadequate, I took steps to rectify the problem and hey-ho, now we have good useful comments again. And it took like fifteen extra seconds beyond the time I spent understanding the code in the first place.
|
|
#
?
May 23, 2017 04:52
|
|
|
VOTE YES ON 69 posted:At the moment go. But holds in any language I've seriously worked in: erlang, c#, python. Is your argument going to be that when you're bittwiddling poo poo at a low level comments are important? That's fine. Similarly, if I was writing APL, I would comment it heavily, because it's hard to read. There's absolutely reasons to write comments, it's just that the majority of comments are useless or even harmful. Comments are even more useful under "entropy." If you're reading a file, or a pull request or whatever, and all the comments still match all the code, you have a good measure of "entropy". You know you can trust what's going on, and the last author, and so on. On the other hand if you start to notice that comments aren't matching the code, then you've still gained useful intel. You know that whoever's been modifying this file cannot be trusted. You have to dig in. Someone who isn't updating the comments also wasn't reading the comments, which casts doubt on their ability to read other things. I use comments not just to know what's going on in the code, but also to give me a clue of how much I can trust the edits to the file. And in work environments with subpar-to-no code reviews, those clues let me hone in on problems quicker and work faster.
|
|
#
?
May 23, 2017 04:53
|
|
|
minato posted:This is how it works at Facebook, basically. Speed is valued over software quality. Which is fine when you're delivering cat pictures, not so much when you're writing medical / financial software. They didn't go so far as to ban DI, but it was discouraged. They don't do long-lived branches either (i.e. continuous integration) which I think is actually a good thing. Ehhhhhh that is something that I think might vary between teams. Whenever I wrote code that was intended for consumption (i.e. framework or library code, instead of app logic), I wrote comments. In once instance I even wrote a wiki page with diagrams, and ascii art of the architecture to go in the main implementation header!
|
|
#
?
May 23, 2017 05:25
|
|
|
Each function get's @brief:, @param:, @returns: at the top of it. The code in the function shouldn't need to be commented unless it's doing something tricky, and in that case, it should probably be rewritten.
|
|
#
?
May 23, 2017 10:29
|
|
|
VOTE YES ON 69 posted:Comments are pretty bad, and you should strive to not need them. I think if you're in this kind of situation it's an indication that it's time to start working on harder problems.
|
|
#
?
May 23, 2017 14:40
|
|
|
Had a phone interview with a recruiter yesterday, and the topic of work history came up, specifically time spent at a job. My last two jobs have been 10 months and 1.5 years, in order. The recruiter said they wanted engineers to stick around for 3+ years, which is sensible, but...well, that's not what I'm used to. I like being able to work on many different things and grow in many different ways, but I also recognize that jumping around jobs can look bad on my resume/history. If I want to stay at a place for 2~3 years, I want to make sure it doesn't, like...go bad eventually. In the past, I either didn't get the opportunities to do new and interesting things, or there just wasn't much happening at all. Those aren't necessarily why I left or am leaving, but they're a major factor. Maybe it's my millennial nature expressing itself, but I get really nervous when I think of tying several years of my life to the whims of a single company. I can't even stay in a single apartment for a year, staying at a company for that long is like  So much can go wrong.
|
|
#
?
May 23, 2017 15:39
|
|
|
minato posted:They didn't go so far as to ban DI, but it was discouraged. They don't do long-lived branches either (i.e. continuous integration) which I think is actually a good thing. These two sentences are a bit confusing to me. First, let's be clear that there's a different between DI, and using DI frameworks. Discouraging banning DI as a pattern is extremely odd to me, do you just mean use of DI frameworks was banned? Your second sentence is just worded strangely, do you mean they did continuous integration, and therefore there were no long-lived branches? (agreed that that's a good thing, if so) VOTE YES ON 69 posted:At the moment go. But holds in any language I've seriously worked in: erlang, c#, python. Is your argument going to be that when you're bittwiddling poo poo at a low level comments are important? That's fine. Similarly, if I was writing APL, I would comment it heavily, because it's hard to read. There's absolutely reasons to write comments, it's just that the majority of comments are useless or even harmful. VOTE YES ON 69 posted:The problem with this is that comments are uncompiled, and deemphasized by everyone's editor (italics, greyed out, whatever). Comments become lies *so* quickly, unless you work with extremely disciplined people. What starts as a stronghold of sanity (document why it does it that way!) just turns into a misleading lie later, after whatever gets refactored and actually doesn't or doesn't need to work that way anymore. Entropy always wins, at least the compiler can check lots of it. I won't disagree with this, it's a legitimate problem. I just think that on balance, there are many solid uses for comments; I'd maybe go so far as to say that it's the same rule as with code: generally speaking, the less of it, the better, but hey, sometimes it has to be written. So write what is necessary and prudent. Most often I find commenting necessary to describe intent, not to describe behavior: there are many times when code has to be written in a counter-intuitive way: perhaps you had to write some particular thing in a non-idiomatic pattern for performance reasons, and want to ensure that someone doesn't "clean it up" (yes, ideally performance regression tests would catch that as well). Sometimes you pass some value for an argument to a third party library call that's necessary for correctness, but it's not clear why, or you have to call one function instead of another because the other has a bug in it. Certainly these things don't apply to all or anywhere near most function implementations, so comments can be sparse, but they do happen. ratbert90 posted:Each function get's @brief:, @param:, @returns: at the top of it. IMO, function header comments fall into the category of "ideally, not necessary" to me. I don't fully buy the "code should be self documenting" argument, but it is most true there. Perhaps a necessary evil when working in PHP, Ruby, Python, etc, but those are classic examples of comments that can get harmfully out of date and often don't add much value (at least when you have a nice type system available to you as an alternative). The code in most functions shouldn't need to be commented, but it sometimes does, and the "if it does, it should probably be rewritten" argument is similarly missing the point, in my view: if there is a reasonable way to rewrite the code and still meet whatever constraints/objectives exist in a way where a comment is no longer appropriate, the comment was probably describing behavior of code, which I'd generally agree isn't needed to begin with. But in the sorts of scenarios I've described above, rewriting is either not an option or won't help.
|
|
#
?
May 23, 2017 15:41
|
|
|
Good Will Hrunting posted:That's a troll right? "DI is banned" is incredible. Well done, sir. Not a troll, unless it's a troll on me.  Here's the banned tech list:quote:BANNED TECHNOLOGY LIST There's also this line in their developer culture document that you guys might find interesting. It looks bad out of context, but it looks bad in context too as it's just one bullet point in a list of their overall guidelines. quote:• Copy paste > abstraction. I did know that some of this poo poo was going on when I took the job - I was told my job was going to be to help lead them in the transition to some more modern practices + platforms. I was okay with that idea, but the job ended up being completely different.
|
|
#
?
May 23, 2017 16:13
|
|
|
I'm losing my poo poo. I'd quit that job on the spot, tbh. That's some dictatorship level bullshit and sounds like your management is more absurd than mine. I always ask about DI fwiw though in my interviews.
|
|
#
?
May 23, 2017 16:15
|
|
|
Pollyanna posted:Had a phone interview with a recruiter yesterday, and the topic of work history came up, specifically time spent at a job. My last two jobs have been 10 months and 1.5 years, in order. The recruiter said they wanted engineers to stick around for 3+ years, which is sensible, but...well, that's not what I'm used to. There are people who change every 18-24 months for money, some for continuous meaningless title upgrades because they feel entitled to recognition. The latter are usually the ones I don't want to deal with and usually never make it past the phone screen if we decided to call them (sometimes it's skill, but it's usually attitude that kills their chances). The latter are also usually the ones I run into who collect every new frame work (doing little more than "hello world") to make themselves more marketable. However, if someone is interviewing because they really want to do X that we are doing and they haven't had the opportunity to work with it at scale, those are the more interesting (and prepared) candidates. (none of these traits are mutually exclusive of course and sometimes the candidate is an amalgamation of all of them, and that's fine usually) I think it comes down to: Do you have an actual plan for growth (both career and technology development) or are you just winging it and waiting to see what is new and interesting next? I had really good and supportive mentors / managers very early on in my career who helped set a healthy pace for growth without getting burned out. I also prefer stability and building something long term - could I have gotten a bit further, more money if I had been shrewder and jumped a couple more jobs? Perhaps. I'm not saying I don't look for other jobs from time-to-time, but when it comes down to the offer, I haven't been enticed enough to leave.
|
|
#
?
May 23, 2017 16:27
|
|
|
I think copy paste > abstraction can be pretty true & I like this blog post talking about why(tef also has a blog post on this). https://www.sandimetz.com/blog/2016/1/20/the-wrong-abstraction Obviously the rest of the stuff looks pretty weird though
|
|
#
?
May 23, 2017 16:50
|
|
|
Good Will Hrunting posted:I'm losing my poo poo. I'd quit that job on the spot, tbh. That's some dictatorship level bullshit and sounds like your management is more absurd than mine. I always ask about DI fwiw though in my interviews. If there are no unit tests, DI is probably pointless, so banning it in that case makes sense.
|
|
#
?
May 23, 2017 16:54
|
|
|
|
| # ? May 15, 2024 05:51 |
|
|
Steve French posted:First, let's be clear that there's a different between DI, and using DI frameworks. Discouraging banning DI as a pattern is extremely odd to me, do you just mean use of DI frameworks was banned? Edit: I will say that DI is extremely useful when used to mock out external/expensive deps like database connections. But there are downsides and costs too, so I can understand why people wouldn't want it by default. 90% of the decisions made while programming seem to be deciding on some position between two extremes: performance vs readability, short vs testable, etc. Experience gives you a feel for roughly the best position, but there's never a right answer because it's always context-dependent. quote:Your second sentence is just worded strangely, do you mean they did continuous integration, and therefore there were no long-lived branches? (agreed that that's a good thing, if so) minato fucked around with this message at 17:23 on May 23, 2017 |
|
#
?
May 23, 2017 17:07
|
|