|
Pollyanna posted:Solution: $X = baseline + $10,000~$20,000 No. If you know the price that you want (you know you can get it and you know that you won't get more) ask for that exact number. If you don't, don't try to play games with the recruiter because they have more information than you do. First off, you can give the deflection line as many times as you want. I've never had anyone stop talking to me because I said "let's wait until after the interview to dig in on salary" 3 times. Second, if you are sick of deflecting, just ask the recruiter how much money you can get.
|
#
?
Jul 12, 2017 04:53
|
|
|
|
| # ? May 13, 2024 04:24 |
|
|
[quote="“TooMuchAbstraction”" post="“474269849”"] The craziest thing about SF real estate (and there are many crazy things) is that people pay huge amounts of money to live in SF, only to commute south to the peninsula for work every day. I used to have a reverse commute simply because I headed into the city in the morning instead of away from it. [/quote] I lived in San Mateo as a consultant and that was pretty much the worse of all worlds. Had a job in Emeryville and got the full reverse commute, but god drat I hated doing the Oakland Bay Bridge every single morning. Watching all the UPS trucks coming over the 101 Overpass was kind of cool though.
|
|
#
?
Jul 12, 2017 05:38
|
|
|
Volguus posted:Funny you're mentioning Stripe. Been looking around for a while for a payment provider for our product and we talked with a fair number of people in our area. I heard Stripe being mentioned numerous times. Maybe their culture is poo poo, but is their product OK? I mean, between them, Paypal or some other payment provider Stripe was the most mentioned. I once integrated stripe payments into a web app faster than it took me to find the documentation for amazon payments. True story. I would still use their product despite those interview alarm bells, and the rest of their culture seemed pretty good.
|
|
#
?
Jul 12, 2017 12:15
|
|
|
duz posted:We're asking those questions to make sure you're not a goon. I'll just answer skydiving or something next time, seems bland enough to stick. Honest Thief fucked around with this message at 12:32 on Jul 12, 2017 |
|
#
?
Jul 12, 2017 12:30
|
|
|
Running through wheat fields.
|
|
#
?
Jul 12, 2017 13:54
|
|
|
Walking behind corn rows.
|
|
#
?
Jul 12, 2017 13:58
|
|
|
Volguus posted:Funny you're mentioning Stripe. Been looking around for a while for a payment provider for our product and we talked with a fair number of people in our area. I heard Stripe being mentioned numerous times. Maybe their culture is poo poo, but is their product OK? I mean, between them, Paypal or some other payment provider Stripe was the most mentioned. They are one of the nicest least sexist racist etc companies in the valley, is the stuff i hear. This is because unlike some unicorns which we all know, they loving print money
|
|
#
?
Jul 12, 2017 14:00
|
|
|
Yeah. I know a couple of people who work/worked there, both men and women. Good people as far as I can tell, and happy.
|
|
#
?
Jul 12, 2017 16:33
|
|
|
I always get Stripe and Square mixed up 
|
|
#
?
Jul 12, 2017 16:41
|
|
|
Wait so is it Stripe or Square that sucks? I did a Stripe CTF a few years back and it was fun so hoping they are cool.
|
|
#
?
Jul 12, 2017 17:36
|
|
|
I had an interview with a young, small startup today (~4 years of operation, 2 as profitable), and I'm wondering whether at this point in my career, I should be going after better mentorship and working with cool people, or with getting invested into a product and starting to transition to a more senior role. During the interview, they spoke of the bootcamp grads they were getting from recruiters and how they were too junior for them (somehow I am not), and that they wanted to build up a really good team so that they can handle bringing those juniors on. I responded by saying that I wasn't experienced in building a team and that I didn't feel like I was senior enough to really mentor junior engineers, which they were apparently surprised to hear. Apparently, I was one of the most senior and capable people they've interviewed so far.  It wasn't quite the environment I was looking for - I wanted a place with both an interesting product and cool, smart people I can learn from and that I can spend a few years at - but it got me thinking about whether my goals and "ideal position" might be misguided.The interview also brought to light how my frustrations with my current job revolves around poor project management and planning and how much product requirements checking/clarification I have to do, and that I really don't want to have to do that work. Stupid poo poo that shouldn't be a problem in the first place if management wasn't blind and disorganized. It's clear that everyone has a different set of standards for junior vs. senior vs. mid-level, and I'm just gonna have to play that poo poo by ear. And also that I recognize the importance of good project management, but I don't want to actually do any of that poo poo.
|
|
#
?
Jul 12, 2017 17:59
|
|
|
Pollyanna posted:I had an interview with a young, small startup today (~4 years of operation, 2 as profitable), and I'm wondering whether at this point in my career, I should be going after better mentorship and working with cool people, or with getting invested into a product and starting to transition to a more senior role. During the interview, they spoke of the bootcamp grads they were getting from recruiters and how they were too junior for them (somehow I am not), and that they wanted to build up a really good team so that they can handle bringing those juniors on. I responded by saying that I wasn't experienced in building a team and that I didn't feel like I was senior enough to really mentor junior engineers, which they were apparently surprised to hear. Apparently, I was one of the most senior and capable people they've interviewed so far. What you want in life is something you really need to sort out yourself. If you want a definition of junior vs senior, consider this: Junior can't make decisions, follows technical direction of senior people on how to solve things. Senior has more decision making powers around technical matters. Team Lead is when you start actually mentoring in a serious fashion Junior and Senior developers, actually dealing with the people aspect and not just the technology.
|
|
#
?
Jul 12, 2017 18:08
|
|
|
Skandranon posted:If you want a definition of junior vs senior, consider this: Junior can't make decisions, follows technical direction of senior people on how to solve things. Senior has more decision making powers around technical matters. This would explain why people look at me as if I have answers but all I do is troll stackoverflow and have a strong google-fu.
|
|
#
?
Jul 12, 2017 20:13
|
|
|
return0 posted:Wait so is it Stripe or Square that sucks? I did a Stripe CTF a few years back and it was fun so hoping they are cool. It's Stripe I was talking about but other than that one very glaring issue I didn't see any problems, other than the lovely area the office is in (nice office though). I was, however, severely jetlagged. Turns out a full day of whiteboarding interviews is about the worst thing ever to do a day after an 11 hour flight.
|
|
#
?
Jul 12, 2017 20:14
|
|
|
Pollyanna posted:The interview also brought to light how my frustrations with my current job revolves around poor project management and planning and how much product requirements checking/clarification I have to do, and that I really don't want to have to do that work. Stupid poo poo that shouldn't be a problem in the first place if management wasn't blind and disorganized. I have some bad news for you about human organizations.
|
|
#
?
Jul 12, 2017 22:38
|
|
|
Pollyanna posted:I had an interview with a young, small startup today (~4 years of operation, 2 as profitable), and I'm wondering whether at this point in my career, I should be going after better mentorship and working with cool people, or with getting invested into a product and starting to transition to a more senior role. At a startup, even if you're CTO, or some big title, be aware that if you think of yourself as *being* senior, more likely than not, to somebody, you're going to be the problem, not the solution. It can be a vehicle to developing the skills, but the title change for title change's sake is empty and companies with decent and rigorous processes for career progression might bump the yardstick they measure you by too high for you to succeed in some cases. OTOH, it can be a real learning experience, and that's recognized too. But really, transitioning into a senior role is, to me, a personal career milestone, not a company thing per se, and the title comes much later, once it accurately reflects your professional behaviors (and has for some time).
|
|
#
?
Jul 13, 2017 04:44
|
|
|
Jaded Burnout posted:Yep. Are they still doing it? I'm not sure if it still is, but I remember it being on their job postings online.
|
|
#
?
Jul 13, 2017 06:17
|
|
|
Finding a good mentor is a difficult problem, Pollyanna, and finding one at a given job increases the difficulty because it decreases the pool of candidates to be your mentor. Wanting them to be senior to you is also a further decrease in the pool. Really, there's nothing wrong with looking for several mentors. I have a couple of people who I get some technical/architectural mentoring from (and only one of them is someone I work with), and I have a couple of mentors who are helping me navigate my rise in seniority through my career - there aren't a whole hell of a lot of women in senior positions in this industry, so I've had to look outside the industry for some good role models and guidance on different ways to handle situations that come up etc. If I were looking for a single mentor who fit all my needs, I'd be out of luck. I'd also be missing out on a diversity of viewpoints. There's also nothing wrong with peer mentoring. I know poo poo my peers don't and they know things I don't and we can work together to learn and grow. I think a lot of people forget about this or discount the value of it, but it's been great in my experience. Anyway, while it might not be for you, check out something like write/speak/code in your area and look for people who you can talk to. The events I went to were a little too grrrrrl power at times, but generally speaking they were useful for making connections, and have resulted in a number of peer mentoring situations, as well as one career advice mentor.
|
|
#
?
Jul 13, 2017 14:59
|
|
|
Ugh, totally whiffed a whiteboard section in an interview today. Just for whatever reason I could NOT wrap my head around the (admittedly) complex and (in my opinion) overly "their domain" specific question to even begin to formulate an answer. They passed and, in a way, I'm glad - I've literally never not gotten an offer result from an in-person interview before, which means I never interviewed for a hard job imo, so this is a chance to grow and learn. Anyone have some tips on how to handle that kind of whiteboarding issue? I think I probably should have taken more time to process it, but I felt time constrained and sort of dove in. Obviously I shouldn't do that! But other ideas?
|
|
#
?
Jul 14, 2017 22:41
|
|
|
metztli posted:Ugh, totally whiffed a whiteboard section in an interview today. Just for whatever reason I could NOT wrap my head around the (admittedly) complex and (in my opinion) overly "their domain" specific question to even begin to formulate an answer. What was the question?
|
|
#
?
Jul 14, 2017 22:46
|
|
|
metztli posted:Ugh, totally whiffed a whiteboard section in an interview today. Just for whatever reason I could NOT wrap my head around the (admittedly) complex and (in my opinion) overly "their domain" specific question to even begin to formulate an answer. Practice. Nothing wrong with diving in, as long as you communicate. Ask questions, talk about assumptions, note why you're doing something one way, note problems you notice even if you choose to ignore them at first.
|
|
#
?
Jul 14, 2017 22:49
|
|
|
Before diving in, I'd first make certain I understand the question -- sometimes interviewers like to throw underspecified problems at you to see how you are at gathering requirements. I'd also recommend verbally sketching out a high-level solution so the interviewer knows what your approach is (like, "I'm going to maintain a map of path lengths for each foo and update that every time I find a new path, then take the shortest path from that once my stack empties"). Also, focus on correctness rather than efficiency. You can always refine your solution to make it more efficient, once you have it working, but it's very easy to get sidetracked trying to make an efficient solution first, and never actually finish. An O(n^n) solution is preferable to no solution.
|
|
#
?
Jul 14, 2017 22:56
|
|
|
The last time I had to do a live coding exercise, I got a little irritated, because the panel was being just a tiny bit too restrictive with their answers. Like, it went like this: Me: "I'm not familiar with the technology in use here, but I would guess it would look something like this." Them: "Well, keep going." Me: "Okay, at this point, I'd have to ask somebody for help on where I need to look." Them: "…" Me: "…Where do I need to look?" Them: "You could tryyyyyyyy…" *several seconds pass as I take my hands off the keyboard* Them: "…looking in the…" Like, come on, guys, I get trying to see how the candidate solves problems, but I just straight-up asked for information, so it's your turn to give me something to go off of. Didn't help that they handed me a Macbook and all my muscle memory for keyboard shortcuts was, thus, shot. They didn't give me help on that, either, unless I specifically phrased a question to them like, "How do I open the developer console? This keyboard doesn't have an F12 key."
|
|
#
?
Jul 14, 2017 23:21
|
|
|
The March Hare posted:What was the question? Ultimately it was an OOP design question but phrased in a complex way that was very, very domain specific. I'm a product/business oriented developer so I focused on that stuff, and this question was really more of a test to see how well one can abstract away the "irrelevant" (to them) questions to come up with an optimal design pattern. I only realized that too late, like literally as I was leaving, and when I did the answer became obvious. The gist of it was given a (specific business problem), design a solution that maximizes reuse and flexibility, and my dumb brain just refused to let go off the domain stuff to see the bigger picture. It was a good place, good bunch of people, but no biggie - I have a job that despite recent grumbles isn't bad and pays well, so I really am taking this as a learning/growth experience. Just felt like a bonehead for whiffing it. And yeah, I feel like I was do fixated on the minutiae that my brain just didn't have room for stepping back and making sure I actually saw what they were asking. In the middle of it I seriously just could not disengage and regroup - that's never happened to me before but now that I know what it feels like, is should be a bit better. Yes to practice, and yes to verbalizing - I didn't prepare at all for this interview (bad me) and I think most of my verbalizing was muttering and seeming confused. Thanks for those suggestions. At least I didn't break down or something - I've had someone literally flee an interview in that situation.
|
|
#
?
Jul 14, 2017 23:53
|
|
|
That bugs me when people talk about candidates failing their interviews. Sometimes the candidate was underqualified, and sometimes you just don't know how to helpfully ask a question, or step in to someone else's shoes during a stressful and unnatural situation.
|
|
#
?
Jul 15, 2017 04:59
|
|
|
piratepilates posted:That bugs me when people talk about candidates failing their interviews. Sometimes the candidate was underqualified, and sometimes you just don't know how to helpfully ask a question, or step in to someone else's shoes during a stressful and unnatural situation. You know, you're right. And my experience today has definitely changed how I'm going to interview people in the future. I think I'm going to ask people to bring in a non-trivial project they created and ask them to walk me through it, explain their choices, and answer questions about it - that seems to be a MUCH better way to get an idea of what they can do than trivia and whiteboarding, and also getting an idea if they are full of poo poo. That should actually be less stressful for both sides.
|
|
#
?
Jul 15, 2017 05:20
|
|
|
metztli posted:You know, you're right. And my experience today has definitely changed how I'm going to interview people in the future. I think I'm going to ask people to bring in a non-trivial project they created and ask them to walk me through it, explain their choices, and answer questions about it - that seems to be a MUCH better way to get an idea of what they can do than trivia and whiteboarding, and also getting an idea if they are full of poo poo. That should actually be less stressful for both sides.
|
|
#
?
Jul 15, 2017 12:54
|
|
|
Jose Valasquez posted:You're going to miss out on people who don't do a lot of recreational coding That depends on what "bring in" means.
|
|
#
?
Jul 15, 2017 13:54
|
|
|
Jose Valasquez posted:You're going to miss out on people who don't do a lot of recreational coding I'm going to miss out on people no matter what. There is no perfect process. This one, at least, seems like it might get me closer to what I actually want to know than the one where we give them contrived situations and ask for trivia. And really, if someone didn't have ANYTHING they could show, I'd offer them one of several good homework assignments I've been given and done over the course of my own job hunts so I know they aren't punishingly long. I'd assess the results based on the level they were applying for. Thinking about it, here's a rough idea of the things I'd want to test and how: - How they code and solve problems: have them show off and explain their project (or homework) - How they work with other people's code and give feedback: have them review a pull request that has some subtle and not-so subtle issues - Fit: Talk about a time you messed up at work and how you handled it; talk about how you resolved a difficult situation with a co-worker; talk about what you're looking for, etc
|
|
#
?
Jul 15, 2017 14:12
|
|
|
metztli posted:I'm going to miss out on people no matter what. There is no perfect process. This one, at least, seems like it might get me closer to what I actually want to know than the one where we give them contrived situations and ask for trivia. Sure, this would allow you to test those things, but there are going to be a lot of candidates who don't really HAVE a lot of high quality work they can just show you as they don't own it.
|
|
#
?
Jul 15, 2017 18:32
|
|
|
Skandranon posted:Sure, this would allow you to test those things, but there are going to be a lot of candidates who don't really HAVE a lot of high quality work they can just show you as they don't own it. Right, but for my interview plan, they don't need to bring in a lot. Just ONE non-trivial thing OR a homework assignment I'd give them that I know is a ~4 project (so you can see, non-trivial is a pretty low bar). The only quality expectation I would have is that the work done match what I would expect from the level of the position the candidate is aiming for. In my opinion If a candidate couldn't provide one of those two things when looking for a job, that's a pretty big red flag to me so I'd be OK passing. I don't think it would turn off good candidates, either, certainly not any more than "we're going to make the interview as much unlike what it would be like to work here as possible" interview styles would and do.
|
|
#
?
Jul 15, 2017 19:41
|
|
|
metztli posted:Right, but for my interview plan, they don't need to bring in a lot. Just ONE non-trivial thing OR a homework assignment I'd give them that I know is a ~4 project (so you can see, non-trivial is a pretty low bar). The only quality expectation I would have is that the work done match what I would expect from the level of the position the candidate is aiming for. I have a project that meets those expectations, but it's 2 years old and I haven't touched it since then. Would it be held against me if I hadn't done anything worth showing in that time (lovely failed attempts at a Clojure game and following some books)?
|
|
#
?
Jul 15, 2017 20:02
|
|
|
metztli posted:Right, but for my interview plan, they don't need to bring in a lot. Just ONE non-trivial thing OR a homework assignment I'd give them that I know is a ~4 project (so you can see, non-trivial is a pretty low bar). The only quality expectation I would have is that the work done match what I would expect from the level of the position the candidate is aiming for. Literally everything I write is owned by my current employer and I can't recall how many NDAs I'm under. I've done 'homework' to interview, but if it takes me more than, say, an hour, I'd pass. Again, I have a job. You're setting yourself up to hire only students and the desperate.
|
|
#
?
Jul 15, 2017 20:18
|
|
|
Sometimes people work at companies that take up a lot of their time, or they're wiped out by the time they get home and don't have the energy to write code after doing it all day, or they have to take care of their kids or other responsibilities, too.
|
|
#
?
Jul 15, 2017 20:29
|
|
|
Pollyanna posted:I have a project that meets those expectations, but it's 2 years old and I haven't touched it since then. Would it be held against me if I hadn't done anything worth showing in that time (lovely failed attempts at a Clojure game and following some books)? I wouldn't have a problem with a project that's 2 years old, not at all. Like any project brought in, if you were able to describe and discuss it in detail, the choices you made, what you'd improve, what you found challenging, what you're most proud of and why, that would be perfectly acceptable. I'd also probably ask a lot of questions about what you learned in the last 2 years that would lead you to make it better of course, and you might find yourself explaining a lot of junior mistakes you made in it, but that's actually probably not a bad thing. That discussion could take place without code, but having the code there lets us really dig into it and see about the details of the language or processes, and also provides a pretty reliable way to determine if someone cribbed it or actually wrote it. Also, if the position were one where the person REALLY needed to know a particular language or platform and the associated quirks, I'd ask them to bring in something in that language/using that platform rather than just any old thing, though for a promising candidate I might take the opportunity to ask them "okay so you wrote this part in foo, but we use baz - what kinds of modifications might you need to do if you were porting it" and that'd give a good idea of their facility with the target language/platform. Edit: Pollyanna posted:Sometimes people work at companies that take up a lot of their time, or they're wiped out by the time they get home and don't have the energy to write code after doing it all day, or they have to take care of their kids or other responsibilities, too. Brain Candy posted:Literally everything I write is owned by my current employer and I can't recall how many NDAs I'm under. Totally - I have a life and a job, too. And at this point in my career, I would probably pass on any position where I couldn't just give them one of the personal projects I've done to go over instead of a homework assignment, if asked, unless the job were particularly interesting. Yet I'd *still* be surprised to meet a solid developer who would be good to work with who didn't have *something* they could show. Like, someone could literally grow a second head during an interview and I'd still only be slightly more surprised by that than them not having SOMETHING they could show. Maybe we run in different circles though? Devs I know from work and socially run the gamut in age, responsibilities and career level from newbie to names you would know, and most of them have a few side projects they would talk your ear off about whether you asked or not. The ones I know who don't have side stuff they mess with are either happy cogs working in "good enough for enterprise" shops (which is totally fine - that has its appeal), or those "students or desperate" types who are, often, desperate maybe BECAUSE they haven't honed their skills working on side projects/keeping stuff fresh. metztli fucked around with this message at 21:54 on Jul 15, 2017 |
|
#
?
Jul 15, 2017 20:38
|
|
|
Your plan filters out anyone who both a) doesn't program recreationally and b) has never worked professionally on open-source project. You might very well be ok with this, but you should acknowledge it explicitly. (And keep in mind that some of those devs exist because they work in environments that are fully supportive of growth, learning, and experimentation, but are still closed-source shops.)
|
|
#
?
Jul 15, 2017 22:33
|
|
|
It's true many people don't have public work available (though everyone I know does  ). Use homework, it's good for interviewee (you can put your best realistic foot forward) and interviewer (you have something to talk about with interviewee, you have realistic work to look at). Yes, there is a problems of scale when you shotgun apply to 50 jobs and they all want you to do homework, but.... 1) be more selective as an applicant: 99% of jobs won't hire you, and you don't want to work at 99% of them anyway -- there's some easy fuckin' wins here just reading a job description carefully or doing a phone screen and saying 'no thanks'. 2) employers should be aware of this and do as much filtering as possible *before* homework. If you haven't spent at least an hour or two talking to people before assigning homework, you're doing it wrong. 3) you should be able to find a few hours to prove yourself to a job you've decided you want
|
|
#
?
Jul 15, 2017 23:12
|
|
|
metztli posted:The ones I know who don't have side stuff they mess with are either happy cogs working in "good enough for enterprise" shops (which is totally fine - that has its appeal), or those "students or desperate" types who are, often, desperate maybe BECAUSE they haven't honed their skills working on side projects/keeping stuff fresh. Alternatively, they have plenty of interesting and engaging things to do in their environment at work that they don't dedicate time to side projects that aren't somewhat work related. You can debate whether that's wise of the individual, but it happens. Where I work, we have a lot of interesting data to work with in an application domain that most employees are personally passionate about. As a result, most of the time people want to build something new and interesting for fun that isn't a direct job responsibility, it's still done within the bounds of work codebases, and often is not appropriate to share with others outside.
|
|
#
?
Jul 15, 2017 23:18
|
|
|
raminasi posted:Your plan filters out anyone who both a) doesn't program recreationally and b) has never worked professionally on open-source project. You might very well be ok with this, but you should acknowledge it explicitly. (And keep in mind that some of those devs exist because they work in environments that are fully supportive of growth, learning, and experimentation, but are still closed-source shops.) I kinda thought my biases were clear and if being explicit I'd phrase it a bit differently: I'm absolutely willing to exclude people who meet all of the following 4 conditions: 1) They have not programmed recreationally in so long that they don't have anything they could show 2) They have not worked professionally or as a volunteer (not work but not really recreation) on open source projects 3) They work in an environment where their work supports and helps them grow their skills but forbids them from generating any or using any no -business related code they generate in that process 4) Are unable or unwilling to do a homework assignment due to lack of time or sufficient interest/motivation in the position I think the cases where all of those conditions are met is, based purely on my experience, small enough where the candidates I filter are most likely not going to be a good fit or would be looking for an organization so unlike mine that they wouldn't even apply. And maybe I'll miss some good ones but I'm willing to bet that's fairly rare. Remember, I'm not proposing replacing an amazing and perfect system with something flawed, I'm proposing replacing a very flawed and kind of useless system with a system that has flaws, but might actually be better. Do you think people who would be weeded out by my criteria would be accurately screened by the system I'm talking about replacing? I don't think they would, because the system I'm talking about replacing has literally NOTHING to do with how someone would actually perform on the job unless the job is entirely comprised of contrived situations with sharp time boxes and frequent trick questions about random CS trivia? I happily acknowledge my biases and the potential for false negatives in my system. Anyone care to propose a better one or provide some rationale for why the current system is somehow better?
|
|
#
?
Jul 15, 2017 23:19
|
|
|
|
| # ? May 13, 2024 04:24 |
|
|
Alternative to the homework; half/full day pairing session on a small ticket on your actual codebase, paid at a reasonable rate.
|
|
#
?
Jul 15, 2017 23:31
|
|