|
Good Will Hrunting posted:I went to a (basically) no-name school and first company and in a week of looking I've got 6+ phone screens set up. I've turned 3 places down after phone screens. It's loving ridiculous how many are trying to talk to me about "Senior" positions. Since when is 3 years of experience "Senior" and why are you contacting me about jobs that say "7+ years of experience"? I'm fully confident in my ability to pass medium-difficulty algo interviews at this point, but I just don't have the combination of depth and breadth that it seems like these places want and I have a feeling when I talk to an actual dev and not a recruiter they'll see that. I have no CS degree and have been programming for two or three years and a few months ago pursued one of these senior positions and got it. So I guess what I'm saying is maybe give it a shot.
|
#
?
Aug 21, 2016 11:03
|
|
|
|
| # ? Apr 19, 2024 22:08 |
|
|
RICHUNCLEPENNYBAGS posted:I have no CS degree and have been programming for two or three years and a few months ago pursued one of these senior positions and got it. So I guess what I'm saying is maybe give it a shot. Yeah I currently am. I've had had calls with all of them and in the process with four places that I'd say I'm "highly" interested in. Should I not do well at Google, I'm hoping for either the awesome fin-tech place that I'm in waiting to meet in person or the startup where I could sling some Go for a nice change of scenery .
|
|
#
?
Aug 21, 2016 15:08
|
|
|
RICHUNCLEPENNYBAGS posted:I have no CS degree and have been programming for two or three years and a few months ago pursued one of these senior positions and got it. So I guess what I'm saying is maybe give it a shot. I legitimately do not understand how you could be capable of mentoring junior and mid level engineers, but congrats I guess. Or maybe your org is relatively small and doesn't to the I-II-III-IV-Senior I-Senior II-... thing? I wish I understood title inflation so I could use it to my advantage. 
|
|
#
?
Aug 21, 2016 15:10
|
|
|
leper khan posted:I legitimately do not understand how you could be capable of mentoring junior and mid level engineers, but congrats I guess. Or maybe your org is relatively small and doesn't to the I-II-III-IV-Senior I-Senior II-... thing? It's entirely arbitrary.
|
|
#
?
Aug 21, 2016 15:15
|
|
|
Blinkz0rz posted:It's entirely arbitrary. Yeah at my last job the ladder was basically "Jr Developer -> Developer -> Senior Developer -> Lead". Then one year some manager goon got it in his head we all needed to have more bank-y titles, so we all became some variation on "Vice President". Now where I am it's all completely different again. You basically cannot compare job titles across orgs.
|
|
#
?
Aug 21, 2016 15:20
|
|
|
RICHUNCLEPENNYBAGS posted:I have no CS degree and have been programming for two or three years and a few months ago pursued one of these senior positions and got it. So I guess what I'm saying is maybe give it a shot. Not knowing anything about you, this terrifies me, because I expect a senior developer to be very broad and very deep, and that's hard to do in that period of time. I was once interviewing a prospective intern or junior dev with one of my past coworkers (not at my current company), the other iOS team member (who thought they were lead on the project). They'd been self-taught for four or five years. During this interview, they say something along the lines of "Oh, you don't need to understand Big-O stuff. It's not important, I never learned it." Well, it turns out this developer was a nightmare to work with, and regressed performance, thread safety, product quality, and code quality. But hey, the got features done on time! Oh, and I spent a ton of time constantly fixing stuff because the features would be broken. So I guess what I'm saying is don't be a hated developer because you had the time and the chops to grow into a role but rose to your level of incompetence instead. EDIT for clarification, because I might have been unclear: The developer, who fancied themselves lead, was the senior member on the team, had a poor grasp on algorithmic performance, and was negative on morale and efficiency. The interviewee failed. Doctor w-rw-rw- fucked around with this message at 20:08 on Aug 21, 2016 |
|
#
?
Aug 21, 2016 17:19
|
|
|
Doctor w-rw-rw- posted:Not knowing anything about you, this terrifies me, because I expect a senior developer to be very broad and very deep, and that's hard to do in that period of time. If you have a hated developer and you're a senior or lead then you're failing at your job. You should be improving the quality of code that your juniors produce and developing them. Also, I never learned Big-O but can still understand algorithmic performance implications. It's just the notation that never made it in.
|
|
#
?
Aug 21, 2016 18:47
|
|
|
Blinkz0rz posted:If you have a hated developer and you're a senior or lead then you're failing at your job. You should be improving the quality of code that your juniors produce and developing them. Does this mean that all junior devs are capable of being coaxed into being good-enough-not-to-hate?
|
|
#
?
Aug 21, 2016 20:05
|
|
|
Blinkz0rz posted:If you have a hated developer and you're a senior or lead then you're failing at your job. You should be improving the quality of code that your juniors produce and developing them. I know you're trying to invoke the "no bad child" idea, but at age 23-25 and being in a professional environment, they should at least meet the rest of the team in the middle and realize when their code is just causing trouble for everyone else. Or should college professors be blamed for every failing student?
|
|
#
?
Aug 21, 2016 20:19
|
|
|
MeruFM posted:I know you're trying to invoke the "no bad child" idea, but at age 23-25 and being in a professional environment, they should at least meet the rest of the team in the middle and realize when their code is just causing trouble for everyone else. Or should college professors be blamed for every failing student? If you can't see the value in pointing out to a junior developer why their code is causing trouble then I'm not sure what to say. Your job as a senior or lead is most likely to make big, architectural decisions and to develop junior staff. So do your job and develop them. The alternative is to have a reputation around the office as someone that no one wants to work for because you demand that your underlings work a certain way and then blame them for things without telling them. You don't want to be that guy. I'm not suggesting that means that there isn't a bar for performance that employees have to hit. All I'm saying is that if your junior dev is completing features but is missing a piece of understanding that's causing trouble for others, teach them what they're doing wrong.
|
|
#
?
Aug 21, 2016 20:24
|
|
|
Doctor w-rw-rw- posted:Not knowing anything about you, this terrifies me, because I expect a senior developer to be very broad and very deep, and that's hard to do in that period of time. Well, if this is what you meant to get at, I appreciate the importance of asymptotic complexity. Blinkz0rz posted:If you have a hated developer and you're a senior or lead then you're failing at your job. You should be improving the quality of code that your juniors produce and developing them. It's probably worth an hour or two to learn the notation if you already understand the idea. RICHUNCLEPENNYBAGS fucked around with this message at 22:57 on Aug 21, 2016 |
|
#
?
Aug 21, 2016 22:55
|
|
|
Blinkz0rz posted:If you have a hated developer and you're a senior or lead then you're failing at your job. You should be improving the quality of code that your juniors produce and developing them. There's really nothing to it if you can classify the asymptotic runtime of a subsection of code. Just add everything up at the root level where the sum operator is the max function. Big-Omega is similar, but provides a lower bound instead of an upper bound; eg, best case running time. If something is Big-O and Big-Omega of the same function, it is Big-Theta of that function. Remember that shortcuts like "loops multiply the current counter by N" aren't necessarily correct (or at least don't provide tight bounds). It's entirely possible to nest a loop within another loop and still have O(N) runtime.
|
|
#
?
Aug 21, 2016 23:16
|
|
|
leper khan posted:There's really nothing to it if you can classify the asymptotic runtime of a subsection of code. Just add everything up at the root level where the sum operator is the max function. It's probably worth noting that people use Big-O (technically incorrectly) when they really mean big-theta all the time.
|
|
#
?
Aug 21, 2016 23:22
|
|
|
RICHUNCLEPENNYBAGS posted:It's probably worth noting that people use Big-O (technically incorrectly) when they really mean big-theta all the time. Those people are bad people. Though I only rarely see proofs, so it's hard to judge the veracity or your claim. 
|
|
#
?
Aug 21, 2016 23:38
|
|
|
leper khan posted:Those people are bad people. Though I only rarely see proofs, so it's hard to judge the veracity or your claim. Oh, I don't mean in academic contexts. But when talking about programming.
|
|
#
?
Aug 22, 2016 01:11
|
|
|
RICHUNCLEPENNYBAGS posted:It's probably worth noting that people use Big-O (technically incorrectly) when they really mean big-theta all the time. f(n) \in \Theta(g(n)) implies f(n) \in O(g(n)), so it's not strictly speaking incorrect. It's just not the strongest claim they could be making.
|
|
#
?
Aug 22, 2016 03:28
|
|
|
ultrafilter posted:f(n) \in \Theta(g(n)) implies f(n) \in O(g(n)), so it's not strictly speaking incorrect. It's just not the strongest claim they could be making. I took the statement to mean people think O() is a bound above and below, not that they make only claims on the upper bound. Theta requires a proof of the lower bound, and if you don't care about the lower bound then you don't care about it.. It is absolutely not technically incorrect to say something is O(f(x)) if it is Theta(f(x)), especially if Omega(f(x)) has not been shown.
|
|
#
?
Aug 22, 2016 06:16
|
|
|
RICHUNCLEPENNYBAGS posted:Well, if this is what you meant to get at, I appreciate the importance of asymptotic complexity. In more than 10 years of professional software development I've never come across a situation where I've needed it.
|
|
#
?
Aug 22, 2016 12:58
|
|
|
If "I've never needed to do it in my professional experience is a bar" then in 13 years I never needed to remember literally anything from my CS curriculum because my jobs have been pretty easy from a technical standpoint. Just because you don't need or use it does not mean there aren't a lot of other people that do need it. I've used DeMorgan's law to simplify some conditionals, needed to futz with an RC filter to de noise a circuit, and I've needed to do dynamic programming but everything I've written was not exactly that hard technically and is mostly an achievement in a combination of trivia and debugging skills rather than computer science where I can prove a solution is viable or that an operation is guaranteed to use only O(1) space... unless someone activates a retard mode switch that makes it O(n m) where m is something you didn't even know existed.
|
|
#
?
Aug 22, 2016 13:57
|
|
|
Blinkz0rz posted:In more than 10 years of professional software development I've never come across a situation where I've needed it. I have an anecdote for the other side of this coin. Maybe eight or so years ago, I joined a company that had a mature software product that was widely deployed. It was messaging middleware for hospitals and the like. So, when you hit the bedside button to call the nurse to your bed, the software would send messages out to the nurses via their pagers, Cisco phones, Vocera badges, etc. While the software worked, it was written by a bunch of talented (but junior) staff at the "main" office. I joined a new office that would be taking over software development duties (which later became the "main" office). A quick overview of the products situation when I got there: 1. Most related to algorithmic complexity was the fact that no one had ever run a profiler on the code. I was the first, and I found major slow spots where the previous developers had done silly things with exponential algorithms where linear would do. Management was too focused on fighting fires with incoming bug reports, so I actually had to call a meeting with management to justify the time and funding to rework those pieces of the product and to show the staff what a profiler was and train them on how to use it. So, I had the exponential/logarithmic/linear charts and did a CS 101 explanation of it to two VPs. 2. No STL containers. There were something like five roll-your-own linked list implementations in there. No "const" qualifiers anywhere. "char *" instead of std::string. No asserts anywhere because "they make the program crash".  3. Tons of customer-specific branches of the product. There were features in one branch that weren't in others, and bug reports had to be applied to a specific branch and then added to other branches. Over the span of a year, I merged something like seven branches into one with a minimal set of build #defines for customer-specific features. 4. No documentation beyond sparse comments in the code. I spent a lot of time making notes as I went, which later became wiki-fied in a central documentation location that everyone began contributing to. 5. They were shipping stripped debug builds because release builds "didn't work for some reason". They included the debug C++ libraries in the installer because most customers didn't have them. That would certainly explain the crashes due to asserts. 6. No unit tests were in place. No regression testing procedures. No continual/nightly builds. It was the "fix a bug and do a customer-specific release" school of delivery. All of these items do a pretty good job of showing what the difference is between a talented junior developer and an experienced senior one. Yes, the company was doing well with their product, but it could have been doing so much better without wasting so much time doing a zillion software releases and constantly playing whack-a-mole with bugs. I spent a lot of late nights consolidating, testing, and cleaning up code. I also spent a lot of time working with other developers and mentoring them on better ways to do things. It ended up paying off in the long run, as the company was acquired twice over a span of three years. I'd probably still be there if I hadn't left to go back to grad school. hendersa fucked around with this message at 14:34 on Aug 22, 2016 |
|
#
?
Aug 22, 2016 14:04
|
|
|
hendersa posted:5. They were shipping stripped debug builds because release builds "didn't work for some reason". They included the debug C++ libraries in the installer because most customers didn't have them. That would certainly explain the crashes due to asserts. This is impressive, I presume no advantage was taken of everyone using the debug build either.
|
|
#
?
Aug 22, 2016 14:18
|
|
|
That kind of situation is the default state of programming in the real world, sadly. Sometimes they start with good teams that leave, sometimes management squeezed budget on engineering when they didn't have much money at first, the reasons are as varied as the kinds of developers out there. I was a newbie before and I knew to write tests of some sort and that I shouldn't roll my own container classes for basic data structures until I know better. It's the equivalent stupidity of growing your own grove of trees to make a better bike shed. Not sure if you can say anyone is talented if they let that kind of bad code hygiene happen.
|
|
#
?
Aug 22, 2016 14:55
|
|
|
hendersa posted:Did something about old-school development operations Just wondering, did management assigned you time in your regular schedule to do all that work or did you end up doing it for free in unpaid overtime ? Did you get something out of making the company more efficient ? I had to resign from one of my employer where I tried to improve branches management, continuous deployment, build and testing automation. 50-100 employees company, 10 years old framework. They preferred to just throw more warm bodies to the problem instead of automating. I resigned because I loath that mentality. Have any tips for how to approach this with management ? Doctor w-rw-rw- posted:... I've started programming self-taught when I was a teen in front of my Commodore 64 and later got a formal education in computer science in my late twenties. I had understood most of the content of what they taught at university by myself but I learned the official terms for them. What I learned at Uni was mainly about how to structure my taught and how to speak with other educated person. Yeah I learned some neat trick like how a B-Tree work is how to QuickSort but really, the most important stuff you learn it on the job I think. That said, I've seen really bad and really good programmer coming from formal education and self-taught schools. Most are right there in the middle in term of skills. It's true that self-taught or usually more wild and formal want to apply all the optimal stuff they learned in school. A programmer job is so much more than just code anyway. I'm not sure what was my point.
|
|
#
?
Aug 22, 2016 14:57
|
|
|
MrMoo posted:This is impressive, I presume no advantage was taken of everyone using the debug build either. Nope. While some sort of fancy remote debugging would have been useful in a few cases, the standard method for troubleshooting a customer issue was to provide the customer with another build full of logging fprintf() calls and hope that the log gives you something useful. It has been my experience that "build with debug, strip, and ship" is commonly seen in shops desperate to get a release out that has a lot of uninitialized variables, since debug initializes all of your variables to 0, null, etc. This solves a surprising number of bugs that would not immediately appear as bugs if someone unfamiliar with this quirk was doing a code review. What, pay attention to compile warnings about using uninitialized variables? Pffft. They had a pragma in the build configuration to silence a ton of warnings! necrobobsledder posted:That kind of situation is the default state of programming in the real world, sadly. Sometimes they start with good teams that leave, sometimes management squeezed budget on engineering when they didn't have much money at first, the reasons are as varied as the kinds of developers out there. I've found this also to be the case in outsourced code that was brought back in-house from overseas when outsourcing turned out to be a disaster. AskYourself posted:Just wondering, did management assigned you time in your regular schedule to do all that work or did you end up doing it for free in unpaid overtime ? Did you get something out of making the company more efficient ? I was doing it on my own time at first, but it was becoming more and more apparent after several months of scrambling that it would not work out that way in the long run. That is why I made an appointment with management to present my findings and request time and funding to do training and get everything cleaned up. I am an outlier in this as I got an MBA along the way and made a compelling business case for return on investment for making the change in the way development was done. Development managers that were excellent devs and who were promoted into management often have a difficult time making the business case for this kind of stuff outside of the claim of "but it is the right thing to do!" Just like development, the business side of things takes mentoring and experience to do really effectively and to bridge that gap between the "business" people and the "engineering" people. Edit: To take it to management: Figure out how much time is being spent on rapid releases and the time needed to troubleshooting and fix a bug. Figure out how much of that is "overhead" that could be eliminated by reducing the number of releases. Figure out how many bugs are due to regression. Estimate how much time is wasted trying to reinvent the wheel or looking for info that only so-and-so knows. Apply a dollar value to that time. Estimate the amount of money required for training (and loss of development time during training), additional tools, books for the office, etc. Compare the costs to savings and find an estimated break even point. Estimate what the return on that investment is on multiple timeframes (quarter, year, 3-year, etc.). Finally, suggest what intangibles might result from the improvement in process (improved customer perception of product, give the appearance of outpacing competitors, etc.). Measure what hasn't been measured and make it easy for management to make a decision that would improve the state of things. hendersa fucked around with this message at 15:21 on Aug 22, 2016 |
|
#
?
Aug 22, 2016 15:07
|
|
|
Welp, my 3 top picks after Google gave me 2nd round invites, so I guess I better get that phone screen with Google scheduled. If I do pass that, what's the turnaround between initial phone screen and in person?
|
|
#
?
Aug 22, 2016 15:40
|
|
|
Good Will Hrunting posted:Welp, my 3 top picks after Google gave me 2nd round invites, so I guess I better get that phone screen with Google scheduled. If I do pass that, what's the turnaround between initial phone screen and in person? Depends on how lucky you are and how well you do at a phone screen. If you mention to your recruiter that you're actively interviewing with other companies, it should be reasonably quick.
|
|
#
?
Aug 22, 2016 15:48
|
|
|
b0lt posted:Depends on how lucky you are and how well you do at a phone screen. If you mention to your recruiter that you're actively interviewing with other companies, it should be reasonably quick. Okay, cool, thanks. I don't want to get tunnel-vision with one company obviously, but I also don't wanna gently caress myself out of Google for no reason but poor planning.
|
|
#
?
Aug 22, 2016 15:56
|
|
|
hendersa posted:To take it to management: Figure out how much time is being spent on rapid releases and the time needed to troubleshooting and fix a bug. Figure out how much of that is "overhead" that could be eliminated by reducing the number of releases. Figure out how many bugs are due to regression. Estimate how much time is wasted trying to reinvent the wheel or looking for info that only so-and-so knows. Apply a dollar value to that time. Estimate the amount of money required for training (and loss of development time during training), additional tools, books for the office, etc. Compare the costs to savings and find an estimated break even point. Estimate what the return on that investment is on multiple timeframes (quarter, year, 3-year, etc.). Finally, suggest what intangibles might result from the improvement in process (improved customer perception of product, give the appearance of outpacing competitors, etc.). Thank for specifics 
|
|
#
?
Aug 22, 2016 15:58
|
|
|
Quality post.
|
|
#
?
Aug 22, 2016 17:04
|
|
|
Good Will Hrunting posted:Welp, my 3 top picks after Google gave me 2nd round invites, so I guess I better get that phone screen with Google scheduled. If I do pass that, what's the turnaround between initial phone screen and in person? It was 2 years for me, but it could've been one year if I didn't keep pushing them back until I felt like I was able to hand off my project at my current job. Basically they didn't go past the phone interview I had right before graduating, until they contacted me a year later and said since I had already done a phone interview I could just skip straight to the in-person interview. It takes 2-3 weeks after the in-person to hear if you got in, and then hiring managers who want you on their team set up calls with you to talk about what they do. I interviewed July 11th and signed my offer last Friday, but I experienced a lot of unusual delays for various reasons.
|
|
#
?
Aug 22, 2016 17:12
|
|
|
So do people basically go through the motions at Google and then only apply to other places only once they've gotten rejected? Cause that timeline doesn't really work thrown in the mix with a regular job hunt.
|
|
#
?
Aug 22, 2016 17:55
|
|
|
Good Will Hrunting posted:So do people basically go through the motions at Google and then only apply to other places only once they've gotten rejected? Cause that timeline doesn't really work thrown in the mix with a regular job hunt. People who want to work at Google bad enough do yeah. Most people just get other comparable jobs. I actually legit think the terrible recruiting timeline Google has is a culture fit filter to remove people who don't want to work at Google enough to wait. I imagine it probably works pretty well for them as that.
|
|
#
?
Aug 22, 2016 18:06
|
|
|
Their timeline seems typical for huge corporations. I think that's broken my brain because people are complaining about their turnaround and I'm thinking, "Situation normal." I mean, it's still poo poo, but I don't know why people are calling them out on it in particular. I guess people still treat them as small and lean.
|
|
#
?
Aug 22, 2016 18:06
|
|
|
It's a fine timeline if you're applying to other large corporations. I have no idea how the other "big, good" tech companies do it (I'm thinking mainly Facebook here) but all the "small, good" companies I've talked to really wanted to accelerate the process when I spoke to them and they realized I was fairly competent and was doing a lot of cool and challenging poo poo at my current company.
|
|
#
?
Aug 22, 2016 18:37
|
|
|
Good Will Hrunting posted:So do people basically go through the motions at Google and then only apply to other places only once they've gotten rejected? Cause that timeline doesn't really work thrown in the mix with a regular job hunt. Yeah, I only applied to other places while I was waiting for news after my on-site. If not for a recruiter contacting me, my plan had been to work my current job until I had 3-5 years' experience, which I could use to get a job at SpaceX or Tesla. I'm glad I'm moving away from embedded though, because a lot of it is a huge pain in the nads. Now my plan is to work at Google for 5+ years and then see if I can get in at Valve. Anyway, now that hiring managers are done with some sort of annual headcount review thing, the process after you've been approved by the hiring committee should be faster. You can probably schedule your on-site a lot sooner after your phone interview than I did, I wanted a few weeks to practice.
|
|
#
?
Aug 22, 2016 18:43
|
|
|
Google's timeline is unusually long because of their committee system for making final hiring decisions which most other companies don't have. Means you have to wait until the next time the committee meets which if badly timed could take a while. Its a trade off that guarantees the decisions are more standardized. Facebook's process is definitely a lot faster but probably more varied between teams with the major delay being some rear end in a top hat engineer taking two weeks to submit feedback.Stinky_Pete posted:Now my plan is to work at Google for 5+ years and then see if I can get in at Valve. 5+ years is a long drat time to work for a company, especially if you're considering it a stepping stone. Spending 6 years at Google isn't a bad decision by any means but if you really want to work at Valve you should try sooner rather than later. If nothing else, it'll give you context on what their interviews look like.
|
|
#
?
Aug 22, 2016 19:17
|
|
|
pr0zac posted:Google's timeline is unusually long because of their committee system for making final hiring decisions which most other companies don't have. Means you have to wait until the next time the committee meets which if badly timed could take a while. Its a trade off that guarantees the decisions are more standardized. Facebook's process is definitely a lot faster but probably more varied between teams with the major delay being some rear end in a top hat engineer taking two weeks to submit feedback. I've given some though to tossing my res over to Facebook but I don't really want to work on Enterprise team which fits my skill set best as far as my location goes.
|
|
#
?
Aug 22, 2016 19:20
|
|
|
pr0zac posted:5+ years is a long drat time to work for a company, especially if you're considering it a stepping stone. Spending 6 years at Google isn't a bad decision by any means but if you really want to work at Valve you should try sooner rather than later. If nothing else, it'll give you context on what their interviews look like. Yeah, I thought they wanted more experience but some positions only need a bachelor's and 5 years, so I'll probably apply around when my Google stock is done vesting.
|
|
#
?
Aug 22, 2016 20:19
|
|
|
Stinky_Pete posted:around when my Google stock is done vesting. How it'll work is you'll have your sign-on RSU's. Then every year after that you'll have another grant, probably on the same order of magnitude & time. When your sign-on RSU's are expiring, you'll have built up 4 years of equity grants and likely be receiving the majority of your compensation that way. No matter when you leave, you're probably leaving huge equity on the table to do so.
|
|
#
?
Aug 22, 2016 20:30
|
|
|
|
| # ? Apr 19, 2024 22:08 |
|
|
JawnV6 posted:What? Why would this have a termination date? So you're saying by the time my sign-on stock has finished vesting (4 years), I'll be offered additional RSUs across my career there?
|
|
#
?
Aug 22, 2016 21:08
|
|