My name is Diego Jara and I just started as a Software Engineer Resident at Google. I am also a new grad.
It’s a program that targets new grads. It’s a full time position for one year where the focus is on having an extended training program, as opposed to a usually shorted onboarding program for traditional software engineers. We go into a rotation program - for instance, for 4.5 months we get assigned to one team, and we work with them, and then after that, we rotate to another team. Then after one year, we’re eligible for basically a full time position at Google through that.
The program makes it really clear that the goal is to basically transition into a full time software engineering role. So they try to set up a non-competitive environment - since I enter the program in a specific month with other grads too - and make it extremely collaborative and friendly. We go through the training together - it’s very different to a class in college where you’re being graded on a curve, so often students will treat it like a competition. This is completely the opposite in the sense that it’s not zero sum.
So far, everyone is willing to help each other out and there’s no tension. We have team activities where we get to know each other more and then we also do projects that are collaborative, so we get to work together.
In terms of onboarding, I was supposed to start around March 20th, but that also happened to be the first week that the Stay At Home Order notice was implemented in the Bay Area. So instead they mailed us our laptops.
Remote onboarding is definitely different, right, because if I have a question (which everyone new to a company will have) I can’t just walk over to somebody’s desk and ask them straight up. Instead, I have to PM them (we use Google Meet) and be proactive about that.
I wake up around 7:45 and go on a run. Exercise is really important to me. I do that from Monday to Friday. From there at 10, I start working. I think it’s also important to note that I work in a separate space to where I sleep - otherwise I’d get too distracted in my room.
In terms of my actual work: I’m currently in my training period, on my 6th week, so keep in mind that my average day now will be very different to an average day later. In the beginning of our training, we held a lot of meetings about learning new technologies at Google and that required a lot of meetings. So someone presents through Google Meet.
The projects I’m focusing on are a combination of individual projects where we focus on learning the basics, and then once we’ve done that, we work in teams to build on those fundamentals and work on a project that we all want to work on which is more open ended.
My interview process started in August and I got my acceptance in November, so it’s definitely a very thorough, fleshed out interview process. The amount of interviews you need to do at Google is very different from most other companies. So hopping from one interview to the next can be stressful because I was always thinking “What if they give me that one problem I get stuck on?” That was something I was worried about.
In trying to prepare, I would do a combination of LeetCode medium questions, look at frequency and try to do plenty of those, especially closer to my interviews. I would also focus on how the problems are approached, how they’re written, especially when looking at the solutions after I attempted them. The thing about interview questions is that it’s rare to get the same ones in an interview, so it’s more important to know how to approach problems rather than to know specifically how to solve a problem you saw on LeetCode.
In terms of how Google’s interview questions are different to other companies - at smaller companies I interviewed at, they make you run your code in some sort of executable run environment, where you have to execute your code after you write it and it’s easy to make mistakes even if you got the logic right, because you could have made some syntax errors.
The thing that Google does well for interviews, in my opinion, is that they hold their interviews through Google Docs, so that lets people write pseudo-code and they don’t have to think too much about writing good syntax because Google prefers to focus on people approaching problems well rather than nailing down the peculiarities of a language. They want to see you communicate with your interviewer and ask them questions.
Instead of thinking very long term and being worried about not meeting a deadline or something, I like to take it in steps and focus on doing the best taks I can that day. At the end of the workday, ask yourself: “What did I do that day?” - make note of the answer, and if you can answer that everyday, then that will motivate you to reach your goal and to keep working towards something bigger. You wouldn’t think about it, but all those little: “I implemented X today”, or “I learnt about this new thing today”, etc - they all add up over months of work and then you can really see all the progress that you’ve made.
When I go to my first rotation team and I learn about how they do things, what features they want me to write, I’ll try to break things into little pieces and approach my tasks that way. When you’re very clear and communicative to your manager about all these tasks and changes, they also start to notice your growth over time, and that helps with moving forward.
Another thing is that you should be really communicative to whoever your higher ups are. Because typically they want to help you out, too - if them helping you increases your output at work, then that benefits the whole company (and even more specifically, it benefits the team you are working with).
I really resonate with how you phrased that. At my last internship, I used a lot of my soft skills to help me out and be a better intern. So, in general, academia sharpens your problem solving skills and all the classes you take in college sharpen that muscle. But when you go work in a team, you realize that that’s not the only that is important. For instance, when you’re working on a certain product that people are using, you have to realize that there are so many different aspects to it - for instance, there’s a Marketing team, there’s a Manager who may not necessarily be a Software Engineer who’s overlooking the entire project - and all these different stakeholders each have specific goals that they need to reach, so it is your job to not only ship great code, but to make everyone you work with also help reach their goals.
So, yeah, you need to write emails, you need to be able to have access to someone else’s API - let’s say internally I need to access someone else’s API. You’re going to have to be comfortable reaching out to that relevant person and explaining why you need access. Most of the stuff that you need is made by other people - it’s unlikely that the code you write will be completely from scratch.
Overall, I agree - communication skills are really important, because if you only rely on your technical ability, then you won’t be able to improve as fast as you can. Let’s say you write a web application, and you have a user interface - if you don’t ask your users for feedback on how it looks, then you can’t improve because you only have your own perspective to look at. Collaborating with others gives you their perspective, and that makes your code better overall.
Some people call it a newsletter - I call it a good time. I write about tech careers and how you can get ahead in yours. It’s my best content (like this case study) delivered to you once a week.
