Tag Archives: developers

Byteboard adds interviews for web and mobile engineers

We launched Byteboard inside Area 120, Google’s workshop for experimental projects, with a primary goal to fundamentally change tech hiring for the better. Byteboard is a full-service interviewing platform for software engineers, which uses project-based interviews to assess for skills that are actually used on the job, rather than the theoretical concepts tested for in traditional interviews.

Byteboard aims to help companies efficiently, accurately and fairly assess back-end engineering candidates. In the 14 months since our first pilot, Byteboard has interviewed over 2,000 candidates for clients like Lyft, Betterment and Quibi. By using our platform, our customers have seen their onsite-to-offer rates double and have saved hundreds of hours for recruiters and engineers.

In my role at Byteboard, I have had countless conversations with engineering managers across the tech industry about how expensive, time-consuming, and error-prone hiring engineers can be. Trying to hire a specialist--someone who has mastery in a technical subdomain--is even harder. If you ask a front-end engineer what they think about technical interviews, usually their experience is even worse than the average engineer, since traditional technical interviews over-emphasize skills that are often even less relevant for front-end work.

Today, Byteboard is launching interviews for mobile engineering and web development. These new interview types are still modeled after a day in the life of an engineer, but they give experienced Kotlin, Swift or HTML/CSS/JavaScript engineers an opportunity to dive deeper on some of the front-end skills that they’ve honed and accumulated over their careers. Front-end engineers prefer taking the Byteboard interview for the same reason generalists do: It more accurately represents the work they might actually do on the job.

In addition to the core software engineering skills that all Byteboard questions assess for, Byteboard front-end interviews also evaluate for additional domain-specific knowledge, such as a focus on accessibility or internet principles. This gives hiring managers a comprehensive view of a candidate’s software engineering skills, as well as their role-related knowledge.

Byteboard is on a mission to make technical interviews more effective, efficient, and equitable for all. Front-end engineers should not have to memorize theoretical concepts that they will never use on the job. Instead, they should have the opportunity to demonstrate their skills in an authentic engineering environment that is reflective of their day-to-day work. Expanding our assessment methodology to front-end skill sets is another step towards making interviews better for everyone. 

To learn more about how Byteboard can help you improve your hiring processes, get in touch at byteboard.dev for more information.

Byteboard adds interviews for web and mobile engineers

We launched Byteboard inside Area 120, Google’s workshop for experimental projects, with a primary goal to fundamentally change tech hiring for the better. Byteboard is a full-service interviewing platform for software engineers, which uses project-based interviews to assess for skills that are actually used on the job, rather than the theoretical concepts tested for in traditional interviews.

Byteboard aims to help companies efficiently, accurately and fairly assess back-end engineering candidates. In the 14 months since our first pilot, Byteboard has interviewed over 2,000 candidates for clients like Lyft, Betterment and Quibi. By using our platform, our customers have seen their onsite-to-offer rates double and have saved hundreds of hours for recruiters and engineers.

In my role at Byteboard, I have had countless conversations with engineering managers across the tech industry about how expensive, time-consuming, and error-prone hiring engineers can be. Trying to hire a specialist--someone who has mastery in a technical subdomain--is even harder. If you ask a front-end engineer what they think about technical interviews, usually their experience is even worse than the average engineer, since traditional technical interviews over-emphasize skills that are often even less relevant for front-end work.

Today, Byteboard is launching interviews for mobile engineering and web development. These new interview types are still modeled after a day in the life of an engineer, but they give experienced Kotlin, Swift or HTML/CSS/JavaScript engineers an opportunity to dive deeper on some of the front-end skills that they’ve honed and accumulated over their careers. Front-end engineers prefer taking the Byteboard interview for the same reason generalists do: It more accurately represents the work they might actually do on the job.

In addition to the core software engineering skills that all Byteboard questions assess for, Byteboard front-end interviews also evaluate for additional domain-specific knowledge, such as a focus on accessibility or internet principles. This gives hiring managers a comprehensive view of a candidate’s software engineering skills, as well as their role-related knowledge.

Byteboard is on a mission to make technical interviews more effective, efficient, and equitable for all. Front-end engineers should not have to memorize theoretical concepts that they will never use on the job. Instead, they should have the opportunity to demonstrate their skills in an authentic engineering environment that is reflective of their day-to-day work. Expanding our assessment methodology to front-end skill sets is another step towards making interviews better for everyone. 

To learn more about how Byteboard can help you improve your hiring processes, get in touch at byteboard.dev for more information.

10 shortcuts made possible by .new

Posted by Ben Fried, VP, CIO & Chief Domains EnthusiastHero image of animated man looking at website to cook

Who doesn’t love finding a good shortcut? A year ago, G Suite created a handful of shortcuts: docs.new, sheets.new, and slides.new. You can easily pull up a new document, spreadsheet or presentation by typing those shortcuts into your address bar.

This inspired Google Registry to release the .new domain extension as a way for people to perform online actions in one quick step. And now any company or organization can register its own .new domain to help people get things done faster, too. Here are some of our favorite shortcuts that you can use:

  • Playlist.new: Create a new playlist to add songs on Spotify.
  • Story.new: Write about what matters to you on Medium.
  • Canva.new: Create beautiful designs with your team.
  • Webex.new: For an easy, fast, and secure way to start your personal meeting room from any browser, try this shortcut from Cisco Webex.
  • Link.new: Instantly create trusted, powerful, recognizable links that maximize the impact of every digital initiative using Bitly.
  • Invoice.new: Create, customize and send customer invoices directly from the Stripe Dashboard.
  • Api.new: Prototype and launch your ideas for new Node.js API endpoints with this shortcut from RunKit.
  • Coda.new: Simplify your team’s work with a new doc that combines documents and spreadsheets into a single canvas.
  • Music.new: Create personalized song artwork for OVO Sound artist releases, pre-save upcoming music, and play the latest content with a single click.
  • Cal.new: Create a new Google Calendar event right from your browser.

OpenTable’s reservation.new, eBay’s sell.new and Github’s repo.new are also handy time-savers. Similar to .app, .page, and .dev, .new will be secure because all domains will be served over HTTPS connections. Through January 14, 2020, trademark owners can register their trademarked .new domains. Starting December 2, 2019, anyone can apply for a .new domain during the Limited Registration Period. If you’ve got an idea for a .new domain, you can learn more about our policies and how to register at whats.new.

With .new, you can help people take action faster. We hope to see .new shortcuts for all the things people frequently do online.

All About Updates: More Treble

Posted by Iliyan Malchev, Project Treble Architect

Android 10, our newest release, brings helpful tools for both developers and consumers like suggested actions in Smart Reply to help you multitask faster, Dark theme for battery saving, Focus mode that keeps you from digital distractions, and more. And with almost 50 changes related to privacy and security, Android 10 gives you greater protection, transparency, and control over your data than ever before. It is important to both users and developers that these new releases find their way to mobile devices as fast as possible. In this post, we’ll share an update on the progress we’ve made with Project Treble, an initiative to help manufacturers update devices to new versions of Android more quickly.

Wait and See

When we launched Project Treble with Android 8.0 Oreo, we asked ourselves if our investment would pay off. There were two factors to consider in measuring the effectiveness of the program:

  • Complexity: The new architecture was a major overhaul, meaning it could only be implemented for devices launching with Android 8.0 Oreo and not for devices upgrading from Android 7.0 Nougat and older versions.
  • Time: We had to wait until we released Android 9 Pie to measure the rate of upgrades from Oreo and compare this number to the previous releases.

The Partner Beta Program

One of the earliest indications that Project Treble was having a positive effect was our ability to run the Beta program for Android 9 Pie on many more devices from more manufacturers. In addition to Google Pixels, we had 7 device models from 7 OEMs supporting Android 9 Pie Beta.

With Android 10, this year, we increased the number of devices to 18 (again, in addition to Pixels), representing 12 OEMs. This represents a significant increase over the previous year and shows that Project Treble is having an impact.

Distribution Chart

Beta releases are great, but how did we fare on actual upgrades? To answer this question, we considered two points in time. The first point is right before we released Android 9. The second point is right before we released Android 10. By each of these points in time, the previous release had had a year to reach devices.

In late July, 2018, just before Android 9 Pie was launched in AOSP, Android 8.0 (Oreo) accounted for 8.9% of the ecosystem. By comparison, in late August 2019, just before we launched Android 10, Android 9 (Pie) accounted for 22.6% of the ecosystem. This makes it the largest fraction of the ecosystem, and shows that Project Treble has had a positive effect on updatability.

Graph of Android Oreo Adoption rate

The adoption of Android Pie has been much higher than that of Android Oreo and Oreo MR1 when measured relative to the launch date.

Continuous Improvements in Updatability

The progress shown above results from work we did in Android 8.0 Oreo. We have made serious improvements with Android 9 Pie as well. The most significant one was our behind-the-scenes collaboration with silicon manufacturers. This work had the effect of reducing the average time to upgrade by more than 3 months, and we expect to see upgrades from Android 9 to Android 10 noticeably sooner this year.

There is also the sheer amount of hardening work on the architecture. We completed the seal between the vendor and system components of Android, which ensures that new versions of the top part of the OS run on older versions provided by our partners. We formalized the interface to the Android Linux kernel, expanded the Treble test suite (VTS), and did so much more. As a result, upgrades from Android 9 to Android 10 are going much more smoothly, as evidenced by direct feedback from our OEM and silicon partners.

We are beginning to see the effects already. This year, we saw two OEMs issue software updates to Android 10 on the day we announced it: Xiaomi and Essential. On the same day, OnePlus started a public beta program, and just a few days later, they started updating devices. HMD Global’s Nokia 8.1 just started receiving the update this week. In addition to these partners, many manufacturers such as ASUS, LG, Motorola, OPPO, Realme, Samsung, Sharp, Sony, Transsion, and Vivo have committed to updating some of their devices to Android 10 by the end of the year. Plus, new devices are already hitting shelves with Android 10, such as the OnePlus 7T. We are very excited that Samsung announced an open beta for Android 10 on their devices and started the rollout on October 12th, compared to November 15th last year.

The ROM developer community benefits from improved updatability as well. Mere days after the Android 10 launch, external developers ported it to 15 devices that launched on Android 8 and 9. This work was made much easier thanks to Project Treble, and we are very excited about the potential for open-source development on the OS. We made this even easier by publishing Google-signed Generic System Images (GSIs) and GMS binaries on android.com, as well as posting detailed instructions for developers to try them on their own.

DSU and Project Mainline

In Android 10, we delivered Dynamic System Updates (DSU). For every device launching on Android 10 that supports DSU, developers are able to install Google-signed Generic System Images and boot into them without having to touch the factory ROMs on their devices. We showcased this work at Google I/O, switching painlessly between GSIs and Factory ROMs on Pixel devices.

We also implemented Project Mainline, which allows Google to update directly, via the Play Store, components of the OS that are critical to security and app compatibility. Project Mainline is to the core of the Android OS what Project Treble is to its foundation. It is a dramatic improvement in the velocity of updates of the OS components that fall under its umbrella.

Project Mainline also builds on the work we've done on a less obvious part of Android, called Google Mobile Services (GMS), which has been receiving updates in this way for years. GMS is the part of your Android device that makes it work seamlessly with all of Google's services. Yet another piece, called Webview, is at the core of your browser and every application that interacts with the web. This security- and correctness-critical component also gets updated via Play Store.

Looking Forward

The Android ecosystem is truly vast. There are hundreds of phone manufacturers, dozens of SoC (mobile CPU) models, and thousands of very different devices. Creating an updatability architecture that covers all of them is a complex task. Android is committed to updatability in all forms, whether it’s real-time updates to first- and third-party apps, developer libraries such as Jetpack, or regular security updates for Android devices.

It has been exciting to see the impact of our efforts on updatability. We have a lot more work to do, and we are tirelessly investing on improving updates. I am proud of the progress we all—Android, Google at large, and our many partners—have made so far. I am very optimistic about the future and look forward to sharing our work for the next release of Android.

DevFest 2019: It’s time for Latin America!

DevFest banner Posted by Mariela Altamirano, Community Manager for Latin America with Grant Timmerman, Developer Programs Engineer and Mete Atamel, Developer Advocate

DevFest season is always full of lively surprises with enchanting adventures right around the corner. Sometimes these adventures are big: attending a DevFest in the Caribbean, in the heart of the amazon jungle, or traveling more than 3,000 meters above sea level to discover the beautiful South American highlands. Other times they are small but precious: unlocking a new way of thinking that completely shifts how you code.

October marks the beginning of our DevFest 2019 season in Latin America, where all of these experiences become a reality thanks to the efforts of our communities.

What makes DevFests in LATAM different? Our community is free spirited, eager to explore the natural landscapes we call home, proud of our deep cultural diversity, and energized by our big cities. At the same time, we are connected to the tranquil spirit of our small towns. This year, we hope to reflect this way of life through our 55 official Latin America DevFests.

During the season, Latin America will open its doors to Google Developer Experts, Women Techmakers, Googlers, and other renowned speakers, to exchange ideas on Google products such as Android, TensorFlow, Flutter, Google Cloud Platform. Activities include, hackathons, codelabs and training sessions. This season, we will be joined by Googlers Grant Timmerman and Mete Atamel.

Grant is a Developer Programs Engineer at Google where he works on Cloud Functions, Cloud Run, and other serverless technologies on Google Cloud Platform. He loves open source, Node, and plays the alto saxophone in his spare time. During his time in Latin America, he'll be discussing all things serverless at DevFests and Cloud Summits in Chile, Argentina, Peru, Colombia, and Mexico.

Grant Timmerman, developer programs engineer
Mete Atamel, developer advocate

Mete is a Developer Advocate based in London. He focuses on helping developers with Google Cloud. At DevFest Sul in Floripa and other conferences and meetups throughout Brazil in October, he’ll be talking about serverless containers using Knative and Cloud Run. He first visited the region back in 2017 when he visited Sao Paulo

Afterwards, he went to Rio de Janeiro and immediately fell in love with the city, its friendly people and its positive vibe. Since then, he spoke at a number of conferences and meetups in Mexico, Colombia, Peru, Argentina, Uruguay and Brazil, and always has been impressed with the eagerness of people to learn more.

This year we will be visiting new countries such as Jamaica, Haiti, Guyana, Honduras, Venezuela and Ecuador that have created their first GDG (Google Developer Group) communities. Most of these new communities are celebrating their first DevFest! We'll also be hosting diversity and inclusion events, so keep an eye out for more details!

We thank everyone for being a part of DevFest and our community.

We hope you join us!

#DevFest

#DevFestLATAM

Find a DevFest near you at g.co/dev/fest/sa

Introducing NDK r21: our first Long Term Support release

Posted by Dan Albert, Android NDK Tech Lead

Android NDK r21 is now in beta! It’s been a longer than usual development cycle (four months since NDK r20), so there’s quite a lot to discuss for this release.

We have the usual toolchain updates, improved defaults for better security and performance, and are making changes to our release process to better accommodate users that need stability without hindering those that want new features.

New Minimum System Requirements

This release comes with new minimum system requirements. Following Android Studio and the SDK, 32-bit Windows is no longer supported. While this change will not affect most developers, this change does have an impact if you use 32-bit versions of Microsoft® Windows®. Linux users must have glibc 2.17 or newer.

Release Cycle Changes and LTS

One release a year will be our Long Term Support (LTS) release for users that want stability more than they need new features. The release will undergo a longer beta cycle before being released, and will receive bug fixes as backports until next year’s LTS release. Generally releasing in Q4, our first LTS release will be NDK r21.

The non-LTS releases each year, which we call the “rolling” release, will be similar to our current process. These will be approximately quarterly releases of our latest set of features, which will only be patched later for critical toolchain fixes. If you want the latest features from Clang and libc++, this is the release for you.

More detail, including the criteria we will use to determine what will be backported, what kinds of bugs will trigger a point release, and the bar we hold each release to can be found documented on our GitHub Wiki.

New Features and Updates

There are quite a lot of new things in this release, resolving bugs and helping you write better, safer code.

We’ve updated GNU Make to version 4.2, which enables --output-sync to avoid interleaving output with error messages. This is enabled by default with ndk-build. This also includes a number of bug fixes, including fixing the pesky CreateProcess errors on Windows.

GDB has been updated to version 8.3, which includes fixes for debugging modern Intel CPUs.

Updated LLVM

As always, we’ve updated LLVM and all of its components (Clang, lld, libc++, etc) which includes many improvements.

The toolchain has been updated to r365631 (the master branch as of 10 July 2019). This includes fixes for quite a few bugs in the previous release, perhaps most importantly LLD no longer hangs when using multithreaded linking on Windows. OpenMP is now available as a dynamic library (and this is the new default behavior, so link with -static-openmp if you want to stick with the static runtime).

A handful of driver improvements have been made to reduce the amount of compiler configuration required by each build system as well. Build system owners should check the updated Build System Maintainers guide.

libc++ has been updated to r369764.

Fortify

Fortify is now enabled by default when using ndk-build or the CMake toolchain file (this includes ExternalNativeBuild users). Fortify enables additional checks in the standard library that can help catch bugs sooner and mitigate security issues. For example, without fortify the following code compiles fine: 

    const char src[] = "this string is too long";
    char dst[10];
    strcpy(dst, src);

With fortify, the buffer overflow is diagnosed at compile-time: 

    test.cpp:10:18: error: 'strcpy' called with string bigger than buffer
      strcpy(dst, src);
                     ^

It is not always possible for the compiler to detect this issue at compile-time. In those cases, a run-time check will be used instead that will cause the program to abort rather than continue unsafely.

If you’re using a build system other than ndk-build or CMake via the NDK’s toolchain file, this will not be enabled by default. To enable, simply define _FORTIFY_SOURCE=2. The most reliable way to do this is by adding -D_FORTIFY_SOURCE=2 to your compiler flags.

Clang can also statically detect some of these issues by using -Wfortify-source (also new in r21). This is on by default, but it’s recommended to enforce fixing issues with -Werror=fortify-source. Use this in addition to the C library features, not instead of, since the warnings do not cover the same cases as the C library extension, nor can it add run-time checks.

Note that because run-time support is required for fortify and the feature was gradually added to Android over time, the exact set of APIs protected by fortify depends on your minSdkVersion. Fortify is an improvement, but it is not a replacement for good tests, ASan, and writing safe code.

See FORTIFY in Android for an in-depth explanation of fortify.

Other updates

64-bit requirement

Since August 2019, all existing and new apps are now required to support 64-bit before they can be released to Google Play; there’s an extension for a limited set of apps. For more information and help on adding support for 64-bit, see our guide.

Neon by default

Arm code is now built with Neon by default. In a previous release we enabled it conditionally based on minSdkVersion, but given the very small number of devices that don’t support Neon we now enable it unconditionally. This offers improved performance on all 32-bit Arm devices (64-bit Arm always had this, and it does not affect Intel ABIs).

As before, this behavior can be disabled for apps that need to continue supporting devices without Neon. Alternatively, those devices can be blacklisted in the Play Console. See https://developer.android.com/ndk/guides/cpu-arm-neon for more information.

Up Next

Have a look at our roadmap to see what we’re working on next. The next few big things coming up are package management and better CMake integration.

Build security into your next website

Posted by Ben Fried, VP, CIO & Chief Domains Enthusiast

If you wanted to send a secret message by mail, would you rather send it in an envelope, or on a postcard? If you send it on a postcard, anyone who saw the postcard on its way to the recipient could read the message, or even make changes to what’s written.

Encryption on a website functions like an envelope, protecting information passed between your website and its visitors so it can’t be snooped on or changed. It’s what keeps your visitors safe from bad actors who may try to alter your site’s content, misdirect traffic, spy on open Wi-Fi networks, and inject malware or tracking. You achieve encryption on a website by installing an SSL (Secure Sockets Layer) certificate. This certificate ensures that the data passed between a web server and a browser remains private.

To kick off National Cyber Security Awareness Month, we’re highlighting something that many website owners don’t realize—a single page that isn’t encrypted could potentially be used to gain access to the rest of the website. To avoid this, you need encryption on your entire website, not just for pages that are collecting credit card numbers or log-in info. Even unencrypted landing pages that redirect to an HTTPS page can pose risks. A single unprotected page can become a backdoor for bad actors to snoop on the rest of the site. How do you ensure your entire website is encrypted?

Use a top-level domain that is HSTS preloaded.

The HSTS preload list tells modern browsers which websites to only load over an encrypted connection. The fastest way to get on this list is to use a top-level domain that’s already on the HSTS preload list, such as .app, .dev, or .page. Any website on those extensions gets the security benefits of HSTS preloading from day one, so all you need to do is install your SSL certificate.

Add your website to the HSTS preload list yourself.

Websites can be individually added to the HSTS preload list by the website owner at hstspreload.org. Keep in mind this can be a slow process because the list is manually built into the browser. That means updates to the list are made as new browser releases come out, which can take months to occur for all browsers.

More people are creating websites than ever before, with 48 percent of the U.S. population planning to create one. To help make building your secure website a bit easier, we’ve teamed up with some of our registrar partners, who are offering a discount on .dev, .app, and .page domains plus free SSL certificates during the month of October. We’re also kicking off a video series where existing creators will share their tips for launching a website. You can check them out at safe.page/buildsecurely.

Stephanie Duchesneau, Domains Security Expert, explains the importance of website encryption and the benefits of HSTS-preloading.

Build security into your next website

If you wanted to send a secret message by mail, would you rather send it in an envelope, or on a postcard? If you send it on a postcard, anyone who saw the postcard on its way to the recipient could read the message, or even make changes to what’s written.

Encryption on a website functions like an envelope, protecting information passed between your website and its visitors so it can’t be snooped on or changed. It’s what keeps your visitors safe from bad actors who may try to alter your site’s content, misdirect traffic, spy on open Wi-Fi networks, and inject malware or tracking. You achieve encryption on a website by installing an SSL (Secure Sockets Layer) certificate. This certificate ensures that the data passed between a web server and a browser remains private. 

To kick off National Cyber Security Awareness Month, we’re highlighting something that many website owners don’t realize—a single page that isn’t encrypted could potentially be used to gain access to the rest of the website. To avoid this, you need encryption on your entire website, not just for pages that are collecting credit card numbers or log-in info. Even unencrypted landing pages that redirect to an HTTPS page can pose risks. A single unprotected page can become a backdoor for bad actors to snoop on the rest of the site. How do you ensure your entire website is encrypted?

Use a top-level domain that is HSTS preloaded. 

The HSTS preload list tells modern browsers which websites  to only load over an encrypted connection. The fastest way to get on this list is to use a top-level domain that’s already on the HSTS preload list, such as .app, .dev, or .page. Any website on those extensions gets the security benefits of HSTS preloading from day one, so all you need to do is install your SSL certificate.

Add your website to the HSTS preload list yourself. 

Websites can be individually added to the HSTS preload list by the website owner at hstspreload.org. Keep in mind this can be a slow process because the list is manually built into the browser. That means updates to the list are made as new browser releases come out, which can take months to occur for all browsers.

More people are creating websites than ever before, with 48 percent of the U.S. population planning to create one.  To help make building your secure website a bit easier, we’ve teamed up with some of our registrar partners, who are offering free SSL certificates during the month of October. We’re also kicking off a video series where existing creators will share their tips for launching a website. You can check them out at safe.page/buildsecurely.

Build security into your next website

If you wanted to send a secret message by mail, would you rather send it in an envelope, or on a postcard? If you send it on a postcard, anyone who saw the postcard on its way to the recipient could read the message, or even make changes to what’s written.

Encryption on a website functions like an envelope, protecting information passed between your website and its visitors so it can’t be snooped on or changed. It’s what keeps your visitors safe from bad actors who may try to alter your site’s content, misdirect traffic, spy on open Wi-Fi networks, and inject malware or tracking. You achieve encryption on a website by installing an SSL (Secure Sockets Layer) certificate. This certificate ensures that the data passed between a web server and a browser remains private.

To kick off National Cyber Security Awareness Month, we’re highlighting something that many website owners don’t realize—a single page that isn’t encrypted could potentially be used to gain access to the rest of the website. To avoid this, you need encryption on your entire website, not just for pages that are collecting credit card numbers or log-in info. Even unencrypted landing pages that redirect to an HTTPS page can pose risks. A single unprotected page can become a backdoor for bad actors to snoop on the rest of the site. How do you ensure your entire website is encrypted?

Use a top-level domain that is HSTS preloaded.

The HSTS preload list tells modern browsers which websites  to only load over an encrypted connection. The fastest way to get on this list is to use a top-level domain that’s already on the HSTS preload list, such as .app, .dev, or .page. Any website on those extensions gets the security benefits of HSTS preloading from day one, so all you need to do is install your SSL certificate.

Add your website to the HSTS preload list yourself.

Websites can be individually added to the HSTS preload list by the website owner at hstspreload.org. Keep in mind this can be a slow process because the list is manually built into the browser. That means updates to the list are made as new browser releases come out, which can take months to occur for all browsers.

More people are creating websites than ever before, with 48 percent of the U.S. population planning to create one.  To help make building your secure website a bit easier, we’ve teamed up with some of our registrar partners, who are offering free SSL certificates during the month of October. We’re also kicking off a video series where existing creators will share their tips for launching a website. You can check them out at safe.page/buildsecurely.

From Code to Community: Why developers call DevFest home

DevFest Banner
Ricardo on the left with fellow GDG lead planning DevFest Coimbra

Ricardo Costeira is a Software Engineer from Coimbra, Portugal. For the first time last year, he attended DevFest, the largest developer community-led movement hosted by Google Developer Groups across the world. To celebrate DevFest 2019, we want to share with you Ricardo’s story and how he went from writing code to finding community.

Ricardo (left) and a fellow GDG Lead plan DevFest Coimbra.

1. How did you first hear about DevFest? What inspired you to join?

In 2018, after living in Coimbra for 3 years, I didn't have any friends outside of work that were software developers. I longed to fill my life with more people that understood my passion and decided it was time to make a change. So I took to social media to see how I could connect with more like minded thinkers. Eventually, DevFest showed up on my feed. Out of nowhere, I saw this crazy event in Coimbra packed with bold leaders, energizing speakers, and profoundly creative exercises. I never expected that being with a community would get me so excited. I got a ticket on the spot.

2. Can you tell us about your first experience at DevFest?

It was exhilarating - out of this world. When I first walked in, everyone talked to me as if we had known each other for years. Big smiles, loud laughs, and deep kindness were all around me. As someone who is relatively shy and a loner by nature, I was stunned when I felt myself saying, "I belong here, I'm home." That very same night, I looked up the next event I could attend. Since then, I have attended 2 other events, signed up for 6 more, and have become a GDG Lead. In other words, I’m hooked.

Ricardo

So how did this all change me? To be honest, DevFest brought forward a shift in my personality. I now want to be part of a community - that is a new feeling in my life.

“As someone who is relatively shy and a loner by nature, I was stunned when I felt myself saying, "I belong here, I'm home."

3. What from DevFest 2018 are you looking forward to seeing again this year?

The booths. DevFest Coimbra has booths where you can talk with different companies. It’s exciting to learn about all the opportunities to grow so close to home. In my case, it was thrilling to see just how quickly Portugal is scaling and how so many companies come to DevFest eager to talk with the best talent. Forming these relationships is what can make the difference when finding the right opportunity for you.

4. Leading up to DevFest 2019, what are you most excited for?

Lighting a spark in new attendees. I recently joined the organizational staff and I’m excited to give new attendees that feeling I had when I first walked into DevFest. I’ve found such meaning in working with my fellow GDG Leads to bring together attendees in a sense of shared awe.

5. Any advice for those attending DevFest 2019?

Just say hi. You will be surprised with how far it will take you. DevFest is not only about the talks or workshops, it’s also about the people. This community knows the extrovert and understands the introvert, and warmly welcomes both. That is to say, no matter who you are or how you code, there is a place for you here.

“DevFest is not only about the talks or workshops, it’s also about the people.”

Want to find a DevFest event near you? Check out devfest.withgoogle.com to join our community, meet other developers and learn about Cloud, Android, Flutter, Machine Learning and more.

#DevFest #Community