Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I'm a new manager, having been an SWE IC for 15 yrs. I just did comp planning for the first time. I was given such a small budget for my team, it's not even funny! The system is designed so that most of the staffing budget goes to new hires, not to reward existing employees. Even promotions are fairly small, compared to what you could get by leaving. It's a game of chicken between you and your company: how long are you willing to tolerate small annual raises while more money goes to new hires before you decide to become a new hire at a new company, yourself?

Now that I see it from the manager perspective, I pledge to stay sharp and become a job hopper ... as soon as I find the time to start interviewing. :^)



> The system is designed so that most of the staffing budget goes to new hires, not to reward existing employees.

Organizations undervalue their employees, encouraging brain drain, and then wonder why retention is such a hard problem. It's almost comical.

It also doesn't help that salary sharing is still so taboo (in the US/Canada at least). Stinginess is hard to do when people know what they're worth and know what you're paying everyone else.

> Now that I see it from the manager perspective, I pledge to stay sharp and become a job hopper ... as soon as I find the time to start interviewing. :^)

It's true that interviewing takes up a lot of time, but you can accomplish a lot just by doing low-stakes networking. Connecting with someone new over coffee at a cafe (and/or virtually) is a 15-30 minutes, every once-and-a-while kind of thing. Even better if you interact with them before/after on social media.


Fascinating! How do you plan to stay sharp if I may ask?


I personally just constantly interview. I find the time for that by no longer seriously reviewing any code.

Code review is mostly to think long term about code (as tests catch the immediate stuff). I have no long term future at the company, so oh well.


Guess it's time to start giving strong no hires to job hoppers then /s


Its not that simple. If somenone wanted you wouldn't even know that. Besides - IMO for the hopper it is also not easy - changing colleagues, earning respect again etc. OTOH, whatever one says - the goal of the job is to get paid and support your familly. That gets especially important when you have kids.


We do background checks, so hopefully we're not actually hiring people who tell big lies on their resumes.

> IMO for the hopper it is also not easy I agree. I'm changing jobs soon and have some apprehension for the reasons you mention, plus don't forget the fear of underperforming and being deported for losing my job :/

> the goal of the job is to get paid and support your family Parents and people who pass the vibe check get strong yeses from me so no issue there /s

But in all seriousness I do feel really bad when interviewing parents or anyone with other obligations that stop them from grinding practice questions if I have to fail them because they can't solve some BS leetcode question. Unfortunately my intuition if someone is a good engineer or not doesn't matter much if they can't crank out some leetcodes in 35 minutes :/


The signal for who is a good developer is so unbelievably low for a leetcode interview. I do feel like some codebases have been made unmaintainable because of the "fail fast, break often" mentality that I feel like is taking over things. In the interviews I give I touch on many other aspects of code design, testing, and review especially for senior candidates.

Obviously its not bad enough yet to warrant changing the process though at top companies, so maybe I'm the one who is interviewing in the wrong ways.


What I’m seeing is that some big tech companies these days (including my own) have standardized rubrics [1] for leetcode-style questions that focus on a few areas (like DS&A, communication and coding style) so I can’t really give any marks for these other positive behaviours.

There’s some benefits to rubrics (reduces differences between interviewers and is more fair to minority candidates from what I’ve seen) but I’m it definitely impacts or senior hiring.

Unfortunately there are also so many experienced developers in the hiring pipeline who actually can’t code, so doing at least one coding interview seems inevitable. I’d give less “tricky” questions but, like rubrics, the questions are standardized too :/

[1] https://blog.tryexponent.com/google-coding-interview-rubric/...


I do give coding exercises in my interviews, but they’re usually more open ended and don’t require understanding tricks. If there’s a DS&A portion it’s usually something I’d expect to be used on the job (e.g. a map or array list, not a BST). I also touch on things like SQL and API design. These things feel like they’re hardly hit on in most tech interviews.


The problem is this is great news to other competitors and its not possible to bring everyone on board. Its probably not even legal.


It's ok if my employer's competitors are advantaged because I'm switching jobs soon to get that sweet sweet pay bump anyways :)




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: