Tag: Gemini

I am in the part of my journey to upgrade from a Data Center Technician at Google to a Software Engineer in the company where I need a detailed roadmap. I used the website Developer Roadmaps and found it lacking. However, that’s a free source so I won’t complain too much. Since I use Gemini for many other tasks, I decided to ask for it to give me a Google Fullstack Software Engineer Roadmap. And it did! In today’s post I’ll review what the LLM created and my study plan.

Gemini’s Google Fullstack Software Engineer Roadmap

First, I like Gemini’s introduction to its roadmap for me:

Here is a comprehensive roadmap designed to help you transition from your current tech stack and personal project experience to an L3 Fullstack Software Engineer role at Google, with a strong focus on areas critical for success in their interview process.

This plan emphasizes not just learning new technologies, but also solidifying core computer science principles and adopting best practices in software development.

I need to explain what the “L3” means. It’s the entry-level role for a Software Engineer (SWE) at Google. This role requires usually 0 to 1 years of professional experience.

Gemini’s approach to creating a roadmap for me is in three phases spanning a matter of months:

• Phase 1: Foundational Strengthening (Estimated: 2-4 Months)
• Phase 2: Fullstack & System Design Enhancement (Estimated: 3-5 Months)
• Phase 3: Software Engineering Best Practices & Interview Prep (Estimated: 2-3 Months, Ongoing)

Let’s review each phase in more detail.

Phase 1: Foundational Strengthening (Estimated: 2-4 Months)

The first phase in the Google Fullstack Software Engineer Roadmap is “about building a rock-solid foundation, especially in areas Google heavily emphasizes” according to Gemini.

In this phase are three topics I’ll cover:

1. Algorithms & Data Structures (The Most Critical Area)
2. Unit Testing & Test-Driven Development (TDD)
3. Deep Dive into Python

I’m glad learning about algorithms and data structures is the first topic because I feel it’s the right time in my studies to do so. Although Gemini suggested I use some Coursera courses to learn this (such as “Algorithms, Part I & II” by Princeton University) I’m going to use the second edition of “Grokking Algorithms” by Aditya Bhargava. I learn better through reading (which I wrote about previously on my blog). However, I will follow the LLM’s plan to practice on LeetCode and HackerRank.

As for Unit Testing I’ll spend time reading the official documentation that Gemini told me to read. I’m not sure if I want to buy a book about that. I may watch a few videos and see how I get along. Basically I need to learn the following:

• Testing Frameworks: unittest and pytest for Python.
• Assertions: Understanding common assertion methods.
• Test Fixtures: Setting up and tearing down test environments.
• Mocks & Stubs: Isolating components for testing.
• Code Coverage: Tools and importance.
• TDD Principles: Write tests before code.

Finally, to get better at Python I will purchase the “Fluent Python” book by Luciano Ramalho. Gemini suggests I dive deeper into the language by learning all of this:

• Advanced Data Structures: collections module (e.g., deque, Counter, defaultdict), heapq.
• Generators & Iterators: Understanding lazy evaluation.
• Decorators & Context Managers: How to create and use them.
• Metaclasses (Basic Understanding): How they work at a high level.
• Concurrency & Parallelism: threading, multiprocessing, asyncio.
• Object-Oriented Programming (OOP): Deeper understanding of classes, inheritance, polymorphism, design patterns.
• Performance Optimization: Profiling code, using cProfile, understanding GIL.

Is the estimated duration of two to four months doable for me? Yes, if I dedicate myself everyday with at least two hours a study time.

Phase 2: Fullstack & System Design Enhancement (Estimated: 3-5 Months)

The second phase in the Google Fullstack Software Engineer Roadmap “focuses on broadening your fullstack capabilities and introducing system design concepts” according to Gemini.

In this phase are two topics I’ll cover:

1. Modern Frontend Development
2. Advanced Backend Concepts & System Design

Frankly, this going to be a new change for me because I’m so used to using Bootstrap. I told Gemini of my current tech stack, and it told me it’s time for an upgrade:

• JavaScript (ES6+): async/await, Promises, Modules, Destructuring, Spread/Rest operators, this keyword, closures.
• Framework: React.js (Highly Recommended for Google), Angular, or Vue.js. Focus on one and master it.
• Component lifecycle, Hooks (for React), State Management (Context API, Redux/Zustand for React).
• Routing (React Router).
• Component libraries (e.g., Material-UI, Ant Design, or Shadcn UI if using React with Next.js concepts).
• Build Tools: Webpack/Vite (basic understanding).
• CSS-in-JS/Tailwind CSS: Modern styling approaches.
• Responsive Design: Beyond Bootstrap, understanding Flexbox and Grid.
• Accessibility (A11y) & Performance: Best practices.

Instead of learning React.js, I’m going to learn Angular since Google created that framework and uses it on internal (and some external) applications. Everything else I’m fine with learning.

As for the backend Gemini gave me this:

• Flask Mastery: Dive deeper into Flask extensions, blueprints, context, custom decorators, error handling.
• Relational Databases (PostgreSQL):
• Advanced SQL: Joins, subqueries, window functions, indexing, optimization.
• Database Design: Normalization, denormalization, schema evolution.
• ORM: Deeper dive into SQLAlchemy.
• NoSQL Databases (Basic Understanding): When to use them (e.g., Redis for caching, MongoDB for flexible schemas).
• RESTful API Design: Best practices, idempotency, versioning, authentication/authorization (OAuth2, JWT).
• Microservices vs. Monoliths: Understanding trade-offs.
• Caching: Strategies (client-side, server-side, CDN).
• Message Queues: Basic understanding (e.g., Celery with RabbitMQ/Redis for background tasks).
• Load Balancing & Horizontal Scaling: Basic concepts.
• Monitoring & Logging: Tools and principles.

Again, this is so much to learn. Which is why I think it’ll probably take me closer to five months to learn instead of three months.

Phase 3: Software Engineering Best Practices & Interview Prep (Estimated: 2-3 Months, Ongoing)

The third phase in the Google Fullstack Software Engineer Roadmap “focuses on polishing your engineering skills and specifically preparing for Google’s interview loop” according to Gemini.

In this phase are two topics I’ll cover:

• Software Engineering Best Practices
• Google-Specific Interview Preparation

This phase is heavy on developing the normal workflows for SWEs (such as using Git and going through Code Reviews), along with interview preparation. This phase is last, and I think it should be in my study plan because this is good to learn a month or two before starting interviewing. Thus, I’m not going to start on Phase 3 until probably Q2 of 2026.

My Final Verdict On Gemini’s Google Fullstack Software Engineer Roadmap

Overall, I’m happy with the road the LLM provided. I exported the plan into a Google Doc which resides in my Google Drive. Thus, I have access to it where I go. I also had the LLM add check-boxes to each action item in each topic so I can mark them off as I learn them.

My start date will be the middle of this month (July). I’ll post updates on my blog.

I’m using Gemini to find potential bugs in my code because it works so well. I used it while creating my last project: Easy Home Directory Backup. After it worked out so well, I’m going to continue using it for all my future projects.

Why Am I Using Gemini To Find Potential Bugs?

I can’t think of all the potential issues a user could run into while using my program. Oh yes, I can think of the big ones like validating user input, but there are other issues lurking that I’m missing.

So I turned to Gemini and entered this prompt:

Hey Gemini, I'm building a backup program that will run in the terminal (CLI) just for Linux distros that uses rsync to back up the currently-signed in user's Home Directory to a backup device. I'm building this with Python. The user supplies the path to the backup device. What are some potential issues a user can run into using this program?

I wanted to give the Large Language Model (LLM) that background information so it could form a good answer. Then I put my question last so the LLM knew what I wanted. I’ve tried putting questions in the middle of the prompt, and that works sometimes, but more often than not I don’t get the greatest replies.

Speaking of replies, I got a lengthy one. I’ll break it down in sections:

Potential Issues and Considerations for Your Backup Program

Here are some potential issues a user might encounter when using your Python-based rsync backup script:

1. Incorrect Backup Device Path:

* Permissions: Ensure the user has read-write permissions to the backup device.
* Device Mount: Verify the device is properly mounted and accessible.
* Device Format: Check the device's file system (e.g., ext4, NTFS, FAT32) and its compatibility with rsync.

Gemini correctly pointed out that a user could provide a backup device that doesn’t have read/write permissions. Without validating that my program could crash. Or it could run and not do anything. Next, the user could try to use a backup device that isn’t mounted, or has non-Linux compatible file system. With this information in hand I added a TODO in my notebook to figure out a solution to these issues.

2. Rsync Errors and Failures:

* Network Issues: If the backup device is network-mounted, intermittent network connectivity can cause failures.
* Disk Space: Insufficient space on the backup device can lead to incomplete backups.
* File Access Permissions: If files or directories on the source or destination have restrictive permissions, rsync might fail.
* File System Errors: Corrupted file systems or disk errors can disrupt the backup process.

This section is all about various rsync errors users could run into. I skipped over the information about network issues because my program is strictly for local storage usage, and I inform the user of that. However, disk space is a huge potential issue I didn’t think of. Or course checking for ample free space to contain the Home Directory backup was vital, so I created a TODO for that. Regarding the last two bullet points I decided to check for basic file access permissions, but not for file system errors. The user will need to do the latter.

3. Script Execution and Permissions:

* Script Permissions: The script must have executable permissions for the user.
* User Privileges: The user might need elevated privileges (e.g., sudo) to access certain directories or devices.
* Background Execution: If the script is intended to run in the background, ensure proper configuration for logging and error handling.

These issues I skipped over. Since I’m targeting experienced Linux users with my backup program they should know how to make the script executable. However, I don’t think that’s needed from my testing. The other two bullet points don’t apply to my program since it doesn’t require elevated privileges or runs in the background.

4. Backup Strategy and Retention:

* Incremental Backups: Consider implementing incremental backups to reduce backup time and storage usage.
* Backup Rotation: Implement a strategy to rotate backup files to prevent excessive disk usage.
* Backup Verification: Regularly verify the integrity of backups to ensure data recoverability.

Frankly, I skipped over this section since I wasn’t going to implement any of these features in my program.

5. User Experience and Error Handling:

* Clear Error Messages: Provide informative error messages to help users troubleshoot issues.
* Progress Indicators: Display progress indicators to keep users informed about the backup process.
* Logging: Log detailed information about the backup process for troubleshooting and analysis.
* User Input Validation: Validate user input to prevent invalid paths and other errors.

These suggestions was what I was looking for, and it should’ve been the first thing listed instead of the last. I added all of these as TODOs in my notebook.

Now I hope you see why I will continue using Gemini to find potential bugs in my code.

Yesterday, I wrote a post about my great experience using Google AI, especially Gemini (which you can read here). Well, I ran into a problem using the chatbot today, which reminded me that Gemini does make mistakes. However, the mistake I ran into forced me to research and learn so there is a silver lining. I’ll explain that in more detail a little later in this post.

When It Comes To Code Snippets Gemini Does Make Mistakes

Allow me to set up the scene: I’m writing code for my backup program (which I will discuss in a future post), and I wanted to know the following:

This is Gemini’s reply:

I read through the explanation about the code provided:

I wasn’t going to copy the code and paste it into my Integrated Developer Environment (IDE) without knowing what it did first. That’s tempting, don’t get me wrong, but I want to understand what the code does. That way I can learn and use that knowledge to writing better code in the future.

So after understanding what the function did I customized the code for my project. Then I ran into a problem: My IDE (PyCharm) didn’t have “f_fstype” in the autocomplete. I thought I made a typo so I retyped it. That didn’t work. I turned to Google Search and searched to see if this was a problem with my computer or even PyCharm. There wasn’t a problem with my setup.

I finally visited the official Python documentation and found the entry regarding os.statvfs(), read about the options the module used and “f_fstype” wasn’t one of them.

I went back to Gemini and asked if “f_fstype” was part of os.statvfs() and the chatbot said it was:

As you can see Gemini does make mistakes and can double-down on them. So what did I do?

I Left Feedback

I left negative feedback about this answer because it’s incorrect. Then I provided a link to the official Python documentation that shows all the available options for the os.statvfs() module.

This is important because Gemini, like any other Large Language Model (LLM) learns. There’s a possibility it learned incorrect information just like you or I would. And when I find out I learned wrong, I go to learn the correct information. Gemini needs to do that too. Thus, leaving feedback is so vital.

So Gemini Does Make Mistakes…And Makes Me Think

When I got the incorrect information I had to rethink my solution for my problem. I did use Gemini again for assistance, but first I wanted to think about how to approach the problem. I used some Linux commands on my computer like “stat” and wondered if I could use that to gather the information about the file system on a disk.

While this setback could have discouraged me, I didn’t let it. Writing code, programming a computer, developing software, whatever you want to call it is about solving a problem. Sometimes the problem is straight-forward, other times it’s not. Becoming a great code or programmer or Software Engineers is about finding a one or more solutions to a problem. That’s what I learned from this situation.

So thanks, Gemini!

I’m currently in the midst of coding my latest technical project: A backup program only for Linux distros that performs either a full backup or a partial backup of the user’s Home Directory. So far I’ve made great progress with the code, in part because I’m writing code with Google AI. I know there is a big debate whether AI chatbots help or hinder developers, especially Junior Developers. However, my experience so far has been positive, and I’m using this post to explain why.

Writing Code With Google AI: It’s Better Than Using Search For Long (Or Complex) Questions

The main reason I’m making great progress with my project because Google AI, especially Gemini, understand my longer questions better about Python modules and features better than Google Search.

I still do think that Google Search has its place for quick questions, but Gemini is so much better when it comes to asking longer questions about coding issues.

For example: I wanted to know if it was possible in Python to validate a path to a directory provided by the end user through user input. Gemini was able to formulate an answer to that question within seconds, and provide example code I could use in my project! Oh, and the chatbot explained what each line of code did! Thus, I got a learning lesson and code I could use.

I find myself learning more about the Python programming language and its built-in functions and/or modules I can use through Gemini than reading through the official Python documentation. Not to say I don’t read the documentation because I do. Especially when I want to use a specific flag or option. However, I find myself turning to Google AI more and more often to provide a different, and sometimes simpler, explanation on how to use certain modules or functions.

Writing Code With Google AI: It Understands My Code And Provides Good Suggestions For Improvement

Writing code with Google AI is like having access to a Senior Developer who not only understands my code and what you’re trying to accomplish, but also provides improvements and explains why I should use them.

My backup program is going to run the rsync command to run the backup. In my original design I use the os.system module to run the command. I provided this snippet of code to Gemini for help for some reason. Unfortunately, I’ve forgotten now. The chatbot came back with the answer to my question, but then suggested I use the subprocess.run module instead because it offered between security and performance.

I took this information and did my own research because I wanted to learn more about what the subprocess module was in Python, and how it worked. And in my research I discovered Gemini was correct.

That’s why I’m excited for this technology: It is helping people do more than ever before faster!