A Guide for Early-Career Data Analytics Infrastructure Engineers
Note: This same article was posted on LinkedIn where it got over 100k impressions, and over 250 “saves”.
After my recent post about an opening on the Google BigQuery team for a Senior Software Engineer role, several early-career engineers and university students reached out asking a variation of the same question:
How do you build the skills to work on data analytics infrastructure at Google or other Big Tech companies?
Becoming an expert software engineer in any area involves many different skills: writing (or these days, orchestrating) accurate, well-tested code, holding a large amount of context in your memory, investigation and debugging, system design, clear writing, and the self-confidence, persistence to push work across the finish line. All of this takes time through failures big and small.
If you’re an early-career professional looking to get into data infrastructure engineering, here are some actionable steps to help you on your journey:
1. Pick a language (C++ or Java) and master it.
Data infrastructure is largely a two-language world. Distributed data systems like Spark, Trino, or Kafka use the JVM / Java. High-performance execution/storage layers like Arrow, Velox, DuckDB, and much of Google’s internal stack use C++. Pick one and master it. Yes, we have AI, but language mastery is still critical. If you’re not an expert, you have no way to evaluate if AI-generated code is actually correct, well designed, efficient, testable etc.
The ability to translate your thoughts into working code is still a core part of interview rubrics. (Note: Python is fantastic for data science and pipelines, but under the interfaces, the implementation often is Java or C++. There’s also increasingly Rust, but Java and C++ provide a very wide coverage).
2. Read the basic theory.
Read Martin Kleppmann’s Designing Data-Intensive Applications. There are many other books, but this is a very well-written book. Read Google’s 2010 Dremel paper (https://research.google/pubs/dremel-interactive-analysis-of-web-scale-datasets-2/) to understand how millions of nested records get flattened into columnar storage and how storing data that way can be used for interactive queries and analysis.
Dremel’s repetition and definition levels encoding is one of the key influences in Apache Parquet’s columnar representation of data that is used very widely.
Keep up with engineering blogs across the industry (Google Cloud, AWS, Snowflake, Databricks, Netflix, Meta, Apple).
3. Use the EXPLAIN command.
Download DuckDB (a great learning tool and serious industry product) and a sample Parquet dataset. Run a few SQL queries with EXPLAIN and look at the query plan. Watch exactly how your filters are pushed down to the storage layer. (BigQuery also produces great visual query plans if you have access).
4. Build toy projects (and use AI to stretch your brain).
Assuming your goal is to learn, I suppose it’s good to use AI to assist you, but prompt it to leave the core logic blank for you to implement. You need to write code to actually think, problem solve and build your skills and get to a place where you’re able to translate your ideas into working code. Over your next few weekends, try to build a toy version of:
- A simple SQL parser
- A basic query optimizer
- An append-only Key-Value store
- A zero-copy binary encoder (just as an example: for no particular reason and just because I saw this recently) The Cap’n Proto encoding spec for a great one page guide on this: https://capnproto.org/encoding.html. You can use AI to help break it down for you paragraph by paragraph, e.g. the section on inter-segment pointers. Then you can build C++ programs implementing the two to three key ideas.
If you can read a specification like this, understand the memory layout, and why it’s efficient, and implement the key ideas in C++ correctly with unit tests, you’ll have acquired a skill that is very uncommon in early career engineers.
Key idea: Literally any technology can be decomposed into toy projects you can learn from.
Note: Pay attention to writing good tests, using the appropriate unit testing framework and all its features.
5. Look at Apache Iceberg
Iceberg has become one of the dominant table formats for analytical storage that is open source, in active development and with broad support across major vendors.
If you follow the Apache Iceberg youtube channel, you will see a lot of periodic recordings of design discussions in the community on various aspects of the project (https://www.youtube.com/@ApacheIceberg/videos). Here you can see expert software engineers from top companies discussing trade-offs, pros/cons of design options in the open.
It’s a fantastic representation of how real work in the industry gets done, and the whole process is very close to how design discussions happen internally at Google as well.
If you want to go one step further: Look at the Apache Iceberg C++ community (https://github.com/apache/iceberg-cpp). A lot of spec decisions that get implemented in Java first still need to be implemented in C++. The C++ community is far less crowded than the main Java project. Both are good places to see production quality code, discussions, code reviews. But the C++ project I believe has a lower barrier to entry to add new unit tests or fix starter issues.
Doing this in the open will look incredible on your resume, and you’ll build C++ skills that translate also directly to Apache Arrow and Apache Parquet projects! That’s because the Iceberg C++ community has adopted the Apache Arrow style of coding and abstractions, and the Apache Arrow project itself has merged with the Apache Parquet project. So in one active community, you’re likely to interact with a lot of great engineers from various companies and involved in 3 different projects at once.
6. Do your toy projects in the open (on GitHub).
I say this somewhat hypocritically, as I don’t have an OSS presence myself! But if I were starting my career today, this is what I would do. Just make sure you actually implemented what you list, interviewers will ask you for details.
7. Develop your writing skills.
Good technical writing is more important than ever. Sharing raw AI-generated content with obvious inaccuracies is a fast way to kill your credibility. Use AI to become a better writer, not to write for you. Everyone wants to read artifacts where they know the writer has spent time crafting something authentic, and can stand behind the quality.
As an engineer, your written artifacts (designs, test plans, proposals, investigation reports etc) are seen to be a reflection of your thinking and attention to detail. English is not my first language, but investing in my writing skills has definitely helped my career.
8. Be kind to yourself.
As a newcomer, you are building upon layers of foundational knowledge that someone who started 10 years ago grasped incrementally. It’s a lot! But as an early-career professional in 2026, you have AI to help you navigate complex codebases, and you have time on your side.
Keep learning and building!
You can also find me on LinkedIn.