|
My current job inerview required me to be on site for 3 days. They paid all my expenses (pre-paid credit cards), booked the hotels and airplane tickets for me, and added ~2 days of free time to visit around and make it a part vacation. It's really a huge pain to find the time and reasons to be able to run away for a few days like that and go work for someone else. I ended up getting and taking the job, but I can totally understand why that would be annoying, and I don't think I'd do it again. I don't feel like endangering my current job for a very complex interview. It's sometimes pretty great though, in that it lets you find flaws in how people work you wouldn't get otherwise. You can be testing remote employees who, you find out, don't know how to communicate the work they've done for a single day nor document it, for example These kinds of things can be deal breakers but won't easily show up in an interview. They can also often highlight deficiencies or strong areas of a candidate and let you figure out what kind of on-boarding they'll need when they actually start working for you, and so on. As the interviewee, it also lets you figure out what kind of place the office is, who you're gonna work with, and quickly get to see how the sausage is made and what kind of code you'll be working on. I'm a bit torn on the issue because it's really annoying for the candidates, you cut yourself off from a lot of potentially great people, it's really freaking weird to have people come work on your projects from 1-3 days under whatever condition, but it's very efficient filter and lets you test the interaction between the candidate and the rest of the team better than many other interview processes.
|
#
¿
May 25, 2014 20:20
|
|
|
|
| # ¿ May 6, 2024 14:44 |
|
|
mrmcd posted:- We'll make our devs do all the infrastructure and operations tasks as well. 2 jobs for the price of 1! that's what I get to do  it's not like you'd find a lot of ops teams who love the idea of operating Erlang stacks on your behalf anyway.
|
|
#
¿
Oct 12, 2015 01:22
|
|
|
it's me i'm the dev who does not realize that interview processes are usually not be the same for employees with 2 years or fewer of experience and devs with 10 years behind them
|
|
#
¿
Aug 7, 2019 22:21
|
|
|
Explain how an oversaturated market keeps having ever-inflating wages where people hop jobs and get double-digit percentages raises time and time again.
|
|
#
¿
Aug 7, 2019 22:58
|
|
|
You might have gotten in when the market (or your employer specifically) was desperate and thought this was normal.
|
|
#
¿
Aug 8, 2019 02:37
|
|
|
Working as a team and sharing knowledge? No! Not for me! Leave me alone! Hey why is nobody willing to bring me on their team in a senior role?!
|
|
#
¿
Aug 8, 2019 15:59
|
|
|
from his perspective, it's probably a good thing that how!! prefers silos and asks for guarantees of a job if he passes the take-home because the longer you talk with him the more awful his professional opinions seem to be to everyone else.
|
|
#
¿
Aug 8, 2019 18:02
|
|
|
kayakyakr posted:So you guys talking about companies falling all over themselves looking for people interested in becoming engineering managers... I seem to have found the 3 companies that don't fall into that category. I guess that depends how you perceive the IC role. The way I've grown to perceive it is that a leadership job as an IC still comes with mentorship, training, and soft skills. It's just that rather than defining the next gen architecture alone, you have to be able to do so while keeping lower-ranking individual contributors involved, and knowing how to communicate the questions you ask yourself and why the answers you give are useful. As you grow in seniority, there is less and less work you can do alone on your own in a vacuum that makes sense, and more and more work where your hard-gained experience can be useful to those who have less in ways that is a multiplicator; for most problems, you can do better preventing 5-6 developers who are less proficient or knowledgeable from making mistakes than you would ever accomplish on your own. The same is true of seniority when it comes to domain knowledge rather than just tech stuff; there are few replacements for "knowing the business" and you'll save a lot more time for everyone by communicating that expertise to others so they don't rediscover it through bug reports and hamfisted TDD. You'll still have plenty of opportunities to work on hard interesting problems in many places, but you should expect to make room for more and more time spent complementing and growing the technical strenghts of those around you on top of just honing your own skills. There are better ways to bring people up than "have them suffer through the same yak shaving I've had to go through" as far as systems go, but a lot of tech folks focus on just suffering through poo poo as a rite of passage. Aside from mentorship and experience sharing, more senior ICs are often just expected to take on larger projects with larger scopes; impact is department or company-wide rather than team-wide (often at a senior or tech lead level) or feature-wide, and those larger impacts tend to require better communication and negotiation skills anyway; you'll have to be able to herd cats across the various silos How!! is actively creating, make your points to folks working on product or marketing concerns, and so on, just to get the technical ball rolling the way you want. Eventually CTOs at big orgs do that nearly full time, negotiating budgets and priorities with other departments as a nearly full-time job. This is entirely distinct as a concern from what you'd get through a management track. I wouldn't expect a people manager to be doing technical training for engineers on their own, even though part of their work is likely to focus on career growth. It's just that your more senior technical contributors become a very good way to help that career growth if they are able to.
|
|
#
¿
Aug 8, 2019 18:30
|
|
|
School of How posted:I would argue that a programmer's job is not to improve morale. My job as a programmer is to be productive at programming. If morale is low, that's someone else's problem. It's actually HR's problem. If HR had done their job correctly, morale wouldn't be so low. In my opinion, HR people are always the most worthless people within an organization. gently caress HR.
|
|
#
¿
Aug 8, 2019 19:38
|
|
|
I wanted to get in a relationship, and I asked someone out. They said sure, let's start with a date. I said if we go through the effort of going on a date, will you at least sleep with me after and possibly move in together? They said no. I keep behaving that way with all the folks I asked out, and I keep having a very hard time finding my soulmate. 8 years ago I met someone who was plain content that I weren't a violent offender, and I can't figure out why this no longer is enough today. I believe the dating market is oversaturated, that people are too difficult, and I am here to convince you it is actually so.
|
|
#
¿
Aug 10, 2019 21:45
|
|
|
raminasi posted:Does anyone have advice on dealing with the ego challenges that come from having younger coworkers leveled higher than you? It’s really just a stupid ego thing, I have no reason to think anyone at any part of this has made a bad decision, but knowing that doesn’t make it just go away. I'm someone who self-educated regarding most programming activities and rose somewhat fast to the point of becoming a systems architect at a company with maybe 400 devs at 30, as an outside hire that went above folks who were there for 15+ years. It was kind of a shitshow to get in there, but to my defense, I came in as someone with specific skillsets that were complementary to what they had there, not because I could do the job better than any of the existing devs at that place. I've left that place and landed at another place where I'm a more regular senior dev. So I'd say the thing to keep in mind when that kind of stuff happens is that these younger folks (or any outside hire) might have a type of expertise or a background that puts them in a different bucket than most of the people already in the organization. And that's the weird thing, they might only need to have a few of these more limited strengths, even though an older dev would have a lot more experience overall. An older more senior dev might know a lot about a fuckton of things in all kinds of contexts and business domains, but it's possible the skill the employer is looking for in a position only focuses on a narrow band of that skill in which the younger person just happened to have more experience. And it might not even be more actual experience, just more recognized experience, of which the folks making the hiring decisions are actually aware.
|
|
#
¿
Aug 13, 2019 19:38
|
|
|
A side project is usually seen positively as in "this person is taking their own time to improve themselves professionally" and while not doing that shouldn't necessarily be counted negatively, doing it is hard not to project in a positive way. Go in the old 3 year old repo, edit the README to state it was an experiment, archive the thing (so it's read-only), and if anyone asks a question, specify that it was a learning thing and name a couple lessons you could have learned from it back then and you'll be good to go.
|
|
#
¿
Nov 4, 2019 14:47
|
|
|
To be honest, when I see someone's an ex-googler my first reaction is to wonder whether they'll be able to work outside of the Google development environment and if they'll just spend their time trying to reimplement a version of some tool Google had internally instead of whatever they'd be supposed to work on.
|
|
#
¿
Jul 29, 2020 02:11
|
|
|
|
| # ¿ May 6, 2024 14:44 |
|
|
I'm currently "Staff Engineer" which is fun because in some places Staff is the lowest level and in some places it's high ranking. Also I have no legal right to call myself an Engineer where I live, and got no formal education in the discipline.
|
|
#
¿
Sep 9, 2020 13:20
|
|