Hacker News Reader

Comment by sdenton4 | Hacker News Reader

From the couple people I know who have done this, I think it's pretty choose-your-own-adventure... Get paid to look for your new job, with very few actual responsibilities.

It's worthwhile to compare this relative downtime to ramp-up time for new hires... who also generally spend a couple-few months being fairly useless (though working hard at it).

And googlers being googlers, there's a decent chance that the 'down' time turns into interesting learning or side project time.

View on HN

So...it's kind of like being Big Head working at Hooli? Hanging out on the roof, or building potato guns and piezoelectric sensors?

Finding a new role inside the company actually requires some work though.

This practice isn’t uncommon. In some cases, I’ve seen FAANGMs give people up to 6 months of ‘window viewing’ time to find new jobs

After a recent merger at my employer, had some people in of the teams at my office with very little responsibilities for most of a year. The first six months they had minimal work because the company hadn't told them yet they were dropping them for a competing team on the other side of the merger, then they did inform them and gave them 3 months to find a new role in the company and apart from the odd production incident on their system, there was basically no work incoming to their former team.

I think 3-4 moved within the company, 3 left on their own time before the deadline, and 4 waited out for the redundancy payment.

Finding a job can itself be a full time job though

Lots of networking over coffee. You don't just blindly apply on the internal job board. You talk to people you know in other parts of the company, you schedule meetings with managers with open roles. You reflect on what you actually want to do next. You reach out to mentors on if they know anyone who has interesting open roles or just on advice for next steps.

Also interviewing with other companies. The next best job for you may not be with Google even if you could easily get an internal transfer role. And teams don't just blindly accept you because you already work at Google (although it helps). You still have to go through a somewhat more informal interview loop that you will definitely want to prepare for.

Of course this is up to the individual, you can definitely just screw around for awhile and apply for an interal role with much less care.

Do they have you whiteboard asinine college CS algo problems in the internal version?

Entirely dependent on the team and hiring manager. And the technical requirements of the role you want to move into versus your prior role. If you want to move from working on gmail to working on the android kernel, I imagine there's gonna be some whiteboarding. (Not that gmail is simple software, but just picked two examples that came to mind with different domain expertise).

Sounds reasonable. I was referring more to the gatekeeping type, like a heavy focus on things like balancing trees and recursion for roles that clearly involve neither trees nor recursion.

It's really not that at level. Once at Google you really get the benefit of doubt of clearing a high bar. It's mostly a talk around your work / perf / CLs and then team fit.

what is CL?

Change List: internal Google lingo for what is more commonly known as patch, diff, or pull request in the Open source wold.

If it's anything like amazon they will just be able to look at all of your code for the last N years which is a very strong signal to go along with interview questions. For internal transfers I general focus more on design questions and check the code history for "can they code IRL". Design is harder to check for and also is more dependent on "can we work together to solve problems" which isn't always apparent from just artifacts.

Roles that don't involve recursion? What next, no for loops please - we are developers!!

We hired an engineer once. He wrote a tail recursive function. We had to fire him. We hadn't tested him on that on the whiteboard.

Shrug recursion, where it makes sense, is wonderful and fun. I’m always happy when I find a problem where it makes sense, because those tend to be interesting problems. But in a lot of roles, working in languages like Python and Java, it just isn’t the best option very often.

Yes of course, traversing directories or dependencies is hard. We are developers, not mercenaries!

@ericd, what programming roles don't deal with trees or recursion?

I've dealt with trees in every single domain I've been in, frontend or backend, whether doing "real" programming or building with no-code tools like FileMaker. I've seen admins and accountants build trees and recursion with spreadsheets. I don't think these things are as "gatekeeping" as you imagine.

I don't think people understand that when you work at scale, efficient data structures and algorithms actually matter. I doubt there are many positions in Google that don't fundamentally require the ability to understand both.

Since all programming jobs deal with trees and recursion, and if you are already at Google working on another team, wouldn't it mean you already know about those (since our assumption being all jobs deal with those)? Why not just check directly if you were actually useful instead?

It's 100% not true that all programming jobs deal with trees. I worked for years on a major audio/video/screensharing communications SaaS product and never once needed to write recursive code or use a tree structure. Not all code is for processing data. There was tons of code that had very little to do with data structures or algorithms, and much more to do with implementing network protocols, business logic, managing state, abstracting the differences between the various operating systems we had to support, etc...

I was just taking GP's statement and shows that it is not consistent with the rest of his argument.

I don't agree that all jobs have to deal with trees either.

They're both occasionally the best tool for the job, but I think they're hugely overrepresented in that type of interview. I haven't found that they come up very often in most web development, as an example, but they definitely come up in interviews for web developers.

Trees as data structures are inevitable. Did you have to balance them or perform other nontrivial graph theoretic transformations though?

Totally depends. My team has specific domain expertise requirements so I interview transfer candidates in addition to speaking to their manager, reading their prior performance reviews, and speaking to them more casually.

There are other teams where there is little need for more formal process.

You do realize that show is based on reality, right?

Not really. It was pretty stressful for me last time since I needed to find a project whose commute allowed to get home in time to take care of my kids, since my spouse's job has no flexibility in that regard.

Reply on news.ycombinator.com