We're a place where coders share, stay up-to-date and grow their careers.
Create templates to quickly answer FAQs or store snippets for re-use.
I just have a simple question, what are your recommendations or suggestions for developers who want to work for Google? :)
Here are some links:
I'm actually involved with hiring, and have gone on many outreach campus trips around Australia and NZ (we get 100s of students in a room, and talk about Google and try to get applications). Fun story: I got made into a meme on Reddit once (from a photo from these trips).
For Software Engineering roles, my opinion is that Google hires generalists. This means that while you might be an expert in Java, maybe a team will have an opening for a C++ dev. We don't expect you to know C++ if your resume says you're a Java developer, but we try to assess that you'd be capable of slotting into almost any role.
What this means is, don't focus too much on the minutia of one language or type of problem. As for how we assess this, my advice for interviews: know one or two programming languages reasonably well, and be able to talk through solving problems on the phone. Call even your non-technical friends and get them to ask you the "basic" questions from online coding questions, and write up an answer in Google Docs while you do it.
Now, that's something I don't usually see on the quora, or reddit posts!
Thank you, Sam!
What's different and similarity between Developer Relation and Developer Advocate?
Will your team refactor Santa Tracker using lit-html or lit-element this year?
What are Web API features you wish published and stable in all browsers in several next years?
So Google has two very similar roles, DPE "Developer Programs Engineer" (which I am) and DA "Developer Advocate". Both roles exist within Developer Relations, but we also have Tech Writers, UX folks, ... etc.
Yes! I suppose you saw my post. After the crazy failure we had last year, I have a much better idea of how to build it out this year. Also, I'm currently weighing up whether to drop IE11: global usage is sub-2%, and it would save us a huge burden: I literally would get to ship only <script type="module"> code because that's what all evergreens support.
I'm actually not sure! I think for PWAs to be successful, we have to solve some of the 'gaps' that make folks want apps. I'm often asked at events about access to SMS, Contacts, etc, and this list is huge enough that I'm not convinced just playing whack-a-mole is the right answer. (But I also don't work on standards at all.)
I feel that the largest issue with PWA's is the lack of public knowledge.
On Android users are hit with a popup, something they are trained to ignore. Then if every site pressured you to download its PWA then users will stop caring.
On iOS users are given no hint that it exists without prompt from the site. Apple seem keen to bury them.
I feel the solution would be to allow PWA's onto app stores and have more seamless transitions between the 'APP' and the web
So something you should look at is the onbeforeinstallprompt event. It lets you capture the 'popup' and display it again somewhere in your UI. Controlling this display is a better experience, because you can show it only to your engaged users, in a part of the UI that they'll expect.
Trusted Web Activities are also a way, on Android, to get your PWAs on the Play Store.
TIL! Ill take a proper look at all this.
How do you feel about Chrome becoming so dominant that it's actually becoming detrimental to the free and open web?
Similar question but regarding the proposed Chrome manifest v3 changes for extensions and their potential crippling of ad blocking extensions (yes, there's declarativeNetRequest, but it's limited in number of blocking rules). After all Alphabet's most recent 10k filing explicitly mentions "New and existing technologies could affect our ability to customize ads and/or could block ads online, which would harm our business."
We are aspiring to build a strong developer community for our SaaS product. Our product has a marketplace where the apps are developed using the platform features & we are expecting 3x growth in no. of apps. (one of the primary metrics from our perspective). Currently, the engagement with developers is at its nascent stage.
What do you think should be the approach of DevRel and key aspects that should be focused at this point ?
What are the top 5 things that you would recommend to do in the short term? Say in 6 months to ensure strong developer engagement & enable them to build high-quality apps ?
It's not five things, but some general DevRel advice I've learned over the years:
make sure the sample code (or whatever) to use your platform is well-written and polished—99% of devs will copy and paste it to create their experience
be your zeroth customer—constantly ensure your onboarding experience works well and try to look at it from different levels of experience
what 'community' means is different to everyone (mailing list, public chat, GitHub issues... ?), but make sure you have one, and code samples/answers are well-indexed so when folks search, they can get their answers easily!
Please don't the f*ck follow ANY of these links. Reported for blatant spam. Please go away.
Congratulations Sam! 🎉
I have two questions for you -
Measuring our effectiveness is really difficult. If 100 people use a library or read a post, but go and change their behavior based on that, that's more effective than 1000's of people reading an article about something that perhaps they already understand.
Google has a culture of building its own tooling right? Could you describe that?
There's a bit of history here, I think. A good example is Google's Closure Compiler (which I've worked on, a little bit): it existed aeons before the Node ecosystem, and Babel and Rollup etc, and I think we tend to try to build things that don't exist elsewhere.
I think the (assumed) negative connotation is that we still use Closure, and so we must not be keeping up with the times. I'll let readers decide if that's correct or not 🤷
Well I know this can be subjective, I'm a junior dev got his second job after many interviews and still failing at many interviews, but should I opt out and start learning Dart and Flutter? Anyways I want to focus more on mobile App dev and I think from the videos I have seen and the flutter community on reddit urges me to learn it, so yeah.
Also in the long run how should I not get burned out and frustrated of failing interviews. Even my senior friends (3-8 years of experience) also gets rejected in 3 out of 6 interviews here so yeah I don't want that to keep happening to me at an age of 30 or more. Any advise on that?
If this sounds more controversial I can understand anyone avoiding this question
Here is my question for you -
With regards to learning and diving in actual code, what resources have helped you in your journey and would really recommend to aspiring beginners? =)
So I started coding when I was a young'en, so I don't think I can actually give solid advice for beginners. I had a head-start that many others did not.
I think there's two angles: aim to build a real website, app, etc, because it's something you can do. Use frameworks and tools because they are how the world works, but don't be afraid to dig into their source to see how they work, either.
I know this will sound a bit like a stock question, but what's a typical day for you? Coding, creating talks, demos etc. or all the above?
Right now, it's wake up, change the baby, help my wife feed the baby, write a blog post to keep my sanity, ... repeat 🤣
But when I'm not on parental leave, that is about right. The days stretch a bit too: while Googlers can work 9-5, for a remote person, it's often useful to get up early or stay up late to dial in to some meetings where possible. I try to work from the office even though my local team in Sydney is mostly DevRel folks from other teams, too—like Chris Banes (Android) and Brett Morgan (Flutter), so while we socialize etc, our product goals are totally not aligned at all.
I think the flow for DevRel is: we have an idea, we shop it around our colleagues, we build a prototype/polyfill, and then go to building some developer artefact (talk, video, whatever we think is best), or put pressure on browser vendors to fix some hole. Demos like proxx, built by my colleagues Mariko and Surma, is a recent amazing example of that. DevRel honestly is an amazing job because I mostly get to be creative for a living.
Cool. Thanks for sharing!
Oh, and my days right now also consist of watching game design talks from GDC's from previous years, because I find that interesting (and I have a naïve goal of writing video games while on leave).
I'm 17 years old. I know react. I build some projects using React.
What should I do next now.
Can you help to me know what should I do next
When I was 17, I was mostly having a good time, working casual jobs and studying. My advice is that React might not be around forever (it also could be, I'm not prescient), so try broadening your knowledge a bit so you can become a generalist able to work in any environment. Build some toy programs in other non-web languages like Python, C/C++ (if possible), and study basic algorithms (they'll help you no matter what you end up doing).
Hey Sam, how do you feel about PWAs and their future?
I think it's my job to say optimistic! 😄👍
Discovery and mindshare is always going to be a challenging problem. But even in 2016 (!), our stats from Santa Tracker showed that 10% of all Android launches came from the home screen icon, so it's not insurmountable either. Some of the ways we've tried to make the web more discoverable haven't worked either—there used to be a beacon protocol which'd announce URLs on your Android, but that's been cut, and QR codes aren't exactly ubiquitous.
And this is all while every modern browser can actually register SWs, use their own cache and run offline. 99% of your users don't know this is happening. I'm still surprised when sites like dev.to do anything while my internet is down, and my job is literally to promote this behavior. And to be clear, I don't think being on the home screen is necessarily the ultimate goal of PWAs either. I don't want Reddit on my home screen but I'd love it if the experience was better when I do go there.
I'm reassured by the big players like Twitter and Facebook building proper PWAs, as that happens, I think your classic 'agencies' who are told by their customers that "we need an app" will have more data to push back on that and argue for web-only. I'm always amused when some single-purpose app is built for no particularly good reason (... I'm excited to see what @ShouldBePWA tweets next). I think this sort of 'fixing the long tail' will be what actually brings PWAs into the limelight.
Thanks for the response!
I'm a big fan of PWAs and am writing a series on them at the moment. Google is clearly supporting PWAs, but Apple still seems to lack behind. Do you see them increasing their support or get behind PWAs in the way Google has done?
I have no insight into Apple's motivations but we've seen some progress (reading the Web App Manifest, Service Worker support, ...). I can also plug PWACompat as a partial solution to some of Apple's problems... but it won't get you ATHS prompts. I don't think that should always be the ultimate goal, but it's what most people equate PWA success to.
What general purpose books do you think are a must read for a software developer or programmer? By general purpose books, I mean something like "Introduction to Algorithms".
I'm trying to think back to my university days (literally 10 years ago). For me, my CS degree provided a bunch of those foundations for me (and yeah, my professors got me to read textbooks, but it's been so long that I've forgotten them). So I don't have specific advice.
What I will say though, is understanding the fundamentals is important. As bland as it seems, research how a dictionary/hashmap works, and research big-O notation at a high level.
And my favourite esoteric resource, for anyone programming languages with proper integer types (i.e., not JS, but WASM is fine):
Thanks for the response. That resource feels like a cheat sheet for math-based CP problems. :)
As an Australian, how has Google’s remote culture evolved in ten years?
So "Mountain View" is what we think of as head office, and ten years ago, that was just a few buildings. Visiting MTV was simple, because you could basically hit up everyone you knew or worked with, in really a very small physical radius.
Now, we actually have a challenge of the company being say, about 10x as large as when I joined in 2009. So interacting with my colleagues is not as simple as going to one head office. We have other offices in the Bay Area, plus all the other engineering centers around the world.
This is actually great: it's one of the things I love about Google, that you can work for us but not have to move to Silicon Valley or just one of a few hubs. But it's not for everyone, and it means that it's really hard to conceptualize everything the company is doing.
If I worked at Google, what would be the top 3 things to learn?
I've answered this a bit elsewhere, but my advice is that we look for generalists. Be able to dive into varied code bases in different programming languages.
How does information flow between teams and departments at Google?
Most teams at Google will be located in a few offices with different timezones (although usually always partially on the west coast of the USA). So whatever you work on, you tend to use email, internal sites, docs etc, to share information, and have a couple of group chats.
We're a place where coders share, stay up-to-date and grow their careers.