Ever wondered how technology like Google’s Pixel Watch comes to life? For Mr. Piyush Itankar, it’s about combining low-level programming with a passion for understanding how everything works from the inside out.
In this episode of Calculated Conversations, I had the pleasure of speaking with Mr. Piyush Itankar, a highly respected Embedded Systems Engineer currently working at Google. Mr. Itankar has built a remarkable career at the intersection of hardware and software, playing a crucial role in developing Google’s Pixel Watch firmware and previously contributing to the foundational software behind Google’s custom Tensor SoCs.
His journey into embedded systems started with a simple fascination for glowing bulbs and motors, evolving into a deep passion for electricity, low-level programming, and CPU architecture. With a strong belief in learning from first principles, Mr. Itankar has built an impressive track record through hands-on experimentation, intellectual curiosity, and relentless problem-solving.
In our conversation, we explored a wide range of topics, from the importance of taking a “round-robin” approach to learning to how vulnerability and trust fuel leadership in high-performance teams. Mr. Itankar also shared honest and insightful advice for aspiring engineers, emphasizing the value of reasoning from the ground up, embracing failure, and building systems not just for function but for understanding.
Whether you’re a budding embedded enthusiast or a seasoned engineer seeking perspective, this discussion offers both depth and direction – the kind you can only get from someone who’s truly lived it, layer by layer.
1. You’ve built an impressive career in embedded systems, from low-level programming to hardware-software co-design. What first sparked your interest in working so close to the metal, and how did that early curiosity evolve into the expertise you have today?
I was fascinated by glowing bulbs as a kid. I loved connecting batteries to a bulb and watching it glow. I slowly moved on to playing with motors. I fell in love with electricity early in life. I would try out experiments from science project books, got myself a book on electronics, and understood nothing. This was around the time when I was in 8th–10th grade.
Past my 12th grade, I chose to do Electrical Engineering. It was tough, but I sailed through because I loved the subjects. I didn’t understand the content as much back then (everything makes sense now: the math, the equations, everything). I got a job in a production plant after my bachelor’s. It was not what I thought I would be doing. I took a risk, quit the job, and started to prepare for entrance exams for a master’s degree.
I got a chance to pick my major at the School of Information Science, Manipal. I had a choice between VLSI and Embedded. I picked Embedded because I felt programming CPUs would be so cool. Plus, I was willing to take the path of suffering again. Today, looking back, it is all worth it. I didn’t understand how the world works, and EE accidentally enabled me!
2. A lot of young engineers struggle to find the right balance between hardware and software interests. How did you navigate that path, and what advice would you give to someone unsure whether to specialize deeply or keep things broad in this space?
I was lucky. I focused on my love, electricity, and just tried to understand how it can be controlled. Turns out it runs everything, and Embedded is at the heart of it. I wanted to be able to design a CPU and write my own instruction encoding for it. That pursuit led me to learn FPGAs, CPU architecture (here and there), and the C language.
It took me years, and what seems to have worked for me is – Round Robin. Do a little bit of each, move on, and return when the interest spikes! Don’t force yourself to master something too soon – it doesn’t happen that way. Learn when you feel like it; that’s the only thing that really sticks anyway. Also, don’t go around constantly validating your abilities. Take it easy.
3. It is clear you place a strong emphasis on learning from first principles. Can you share a moment where that mindset helped you solve a complex problem or take a project to the next level?
Because I had tried to program ARM Cortex-M CPUs from scratch (in my personal time over a year), there was a time at work when certain hardware with the same CPU needed to be programmed. Because it was new, no one knew how to get started with it. I volunteered, managed to boot it from scratch, and later went on to write a task scheduler for it from scratch. This impressed the seniors so much that I was promoted. I got three promotions in four years.
All of this was because I spend time understanding and breaking down abstraction layers – in this case, I knew the layers between CPU, OS, and the application.
Also, I try to reason from first principles. I can rely on my reasoning a lot more, and it’s very hard to lose a debate if your arguments are based on facts of nature. The closer you are to reality, the more you win.
4. You have mentored junior engineers and led projects even early in your career. What have you learned about leadership in technical teams, and how do you approach mentoring others in such a high-performance field?
The rules are – let others be vulnerable and allow space to fail. I’ve always let my team know that I don’t know any better than them, and any step they take toward the end goal is right by default.
I tend to teach them everything I know (relevant to the project), so they’re armed with information and can skip the research. That lets them bump into and solve other problems. I spend a lot of time talking to them over coffee, planning their career moves, and making sure they’re rewarded for what they’re doing.
I ensure they have reasons to trust me with part of their journey – and that they understand why working toward the common goal helps them reach their own faster.
5. A lot of aspiring engineers dream of working in top-tier tech environments, but few understand the real demands behind the scenes. What habits or perspectives helped you stay consistent and deliver high-quality work throughout your journey?
Round Robin. The fact that I knew a lot of keywords helped. When the work dynamics changed and I was assigned to a new task, because I had some idea about it, I’d get curious and dive into reading or research and learn things faster.
It’s like I managed to have an “adventure” response as opposed to a “fear” response. Another thing that helped me is giving my seniors some rights over me. I always tell my seniors they should call me out if I’m being an idiot, getting in the way, or bluffing.
Also, I’m not too attached to the work I produce, code, documents, etc. , so if someone calls it bad or wants to throw it away, I’m completely okay with that. What happens because of that is people realize it’s easy to work with me and have hard conversations.
And guess what? People naturally look out for those who are easy to work with! You never want to work with someone you have to filter your thoughts around. Be vulnerable. People love it. And if you’re punished for it, the place wasn’t for you anyway.
6. With such a strong technical foundation, how do you keep your learning sharp today? Are there specific books, tools, or communities that have helped you grow continuously?
I don’t rush to stay on top of every new trend. I’m a slow learner and look for and learn things that don’t change as rapidly but are still relevant. For example, my entire career is built on the C language. I tend to focus on math, physics, and EE.
I keep revisiting lectures from MIT, Cornell, and Harvard (just because they also focus on first principles). I also spend a lot of time talking to my friend Mahmad, who, much like me, likes to predict how things must be working and later tries to find evidence to prove or disprove a hypothesis. We both learn very fast because of that.
7.Lastly, what advice would you give to a young person, possibly still in school, who is interested in embedded systems but overwhelmed by how complex it seems at first glance?
Everything you are learning is there for a reason. It’s the foundation for what’s to come. That said, you don’t need to master everything – just know that things are there for a reason and try to remember the keywords as much as possible.
If embedded interests you, focus on building and understanding abstractions. Program an Arduino and make something move – but also realize that someone has made the job easy for you. Try to look for what’s being hidden from you.
In general, for embedded systems, do a round-robin between C, CPUs (ARM-M, RISC-V), OS, and FPGAs. And finally, remember: learning is not a function of age. A 4-year-old is not half of an 8-year-old. Enjoy the process, don’t compare yourself with peers, and look for the truth. You’ll be just fine!
What an incredible conversation with Mr. Piyush Itankar! His journey from a young curiosity about electricity to becoming a key figure in embedded systems at Google is nothing short of inspiring. His insights on embracing failure, learning from first principles, and building systems not just for function but for understanding provide valuable guidance for anyone pursuing a career in this field.
Key takeaways from our chat:
- Embrace a “round-robin” approach to learning. Don’t rush mastery – let your curiosity guide you.
- Trust in the value of learning from first principles. It’s the key to solving complex problems and driving innovation.
- Vulnerability and trust are foundational to leadership. Create space for others to fail and grow with you.
- Consistency beats intensity. Show up, stay curious, and keep learning, even when it feels tough.
If you’re looking to dive into embedded systems or want to enhance your skills in low-level programming, be sure to check out Mr. Itankar’s personal effort – a free roadmap for beginners in embedded systems:
Thank you, Mr. Itankar, for sharing your incredible journey and wisdom. Your advice is a blueprint for anyone ready to take on the world of embedded systems.
What’s something you think is often overlooked in the world of embedded systems or engineering in general, and why do you think it’s important?
Leave a Reply