DEV Community: jhaji12

My Interview Experience at Google - Customer Engineer, Gen AI

jhaji12 — Sun, 17 Sep 2023 19:25:49 +0000

In the midst of an ordinary morning routine, a message notification on my phone brought a wave of unexpected excitement—a job opportunity at Google via LinkedIn.🤩🤩🤩 Skeptical but curious, I replied, expressing my interest in the Customer Engineer Gen AI role. The prospect of joining Google, even as a full-stack developer, was too alluring to ignore. To my astonishment, within minutes, I received a call from Google's HR team, a surreal moment I hadn't anticipated. As the conversation unfolded, I found myself invited to a screening round, signaling the beginning of a life-changing journey.

On the day of the screening, I joined a Google Meet call, heart pounding with anticipation. The HR welcomed me and initiated discussions about my professional journey and work experience. What I thought would be a routine profile discussion quickly turned into a coding challenge. With determination, I tackled each question, emerging successfully from the initial screening round, a proud moment that I eagerly shared with family and friends.
🥳🥳🥳
Following the screening, an email from Google's recruiting team arrived, detailing the interview process, expectations, and comprehensive insights into each stage. Armed with this knowledge, I embarked on a week-long journey of intensive preparation, diving into Google Cloud fundamentals, Gen AI, Vertex AI, and various Google Cloud services.
🫠🫠🫠
The pivotal interview day arrived, and though my nerves were palpable, I resolved to give it my all. Two interviewers greeted me, creating an atmosphere of comfort and mentorship as they presented a coding challenge. They guided me through multiple problem-solving approaches, ultimately arriving at the optimal solution. As a pleasant surprise, they presented a bonus question, fostering a comfortable and supportive interview environment.
🥹🥹🥹
The joy of successfully passing the first round was tangible, a milestone celebrated with loved ones. An email from Google's HR soon followed, informing me of my qualification for the next round: RRK (Role Related Knowledge). I requested additional time to prepare, given my full-stack developer background and limited knowledge of Google Cloud, and the HR team graciously granted me a week.
😁😁😁
In the second round, I navigated questions about Gen AI and deployment while sharing insights from my freelance projects. The interview transitioned into situational inquiries, challenging me to prioritize stakeholders and defend my choices. Despite moments of doubt, I persevered, discussing containerization and addressing stakeholder needs.
🫡🫡🫡
However, my confidence faltered as the conversation delved into topics like hypervisors and VMWare, ultimately affecting my performance. Constructive feedback from the interviewer acknowledged that my tech journey had only just begun. I awaited the outcome with a mix of hope and uncertainty.
🥲🥲🥲
A week later, an email from HR shattered my anticipation: rejection. Yet, they left me with a glimmer of hope, assuring me that my profile would be considered for future roles. While this chapter didn't end as I had hoped, it taught me invaluable lessons about resilience, preparedness, and the unpredictable nature of life's journey. With renewed enthusiasm, I look ahead, ready to embrace the next opportunity and continue learning.
😇😇😇
Life is an ever-evolving journey, filled with experiences meant to guide and inspire us. As we navigate this vast landscape of opportunities together, I invite you to share your stories and learnings.

Happy Learning!🚀🚀🚀

Let's connect on LinkedIn 😄- https://www.linkedin.com/in/jyoti-jha-bb1461175

Vault for Beginners

jhaji12 — Fri, 02 Jun 2023 07:22:06 +0000

Let's dive into a story-like narrative to help us understand Vault in a more engaging way.

Once upon a time, in a world where sensitive information held great power, there existed a kingdom known as Vault. Vault was a fortress designed to safeguard valuable secrets like API keys, passwords, and database credentials.

The king of the kingdom understood the importance of protecting these secrets from falling into the wrong hands. To ensure the security of the kingdom, he summoned the expertise of HashiCorp, a renowned master of secrets management.

The HashiCorp team introduced Vault, a powerful tool that would serve as the guardian of the kingdom's secrets. They began by installing Vault within the fortified walls of the kingdom, setting up a stronghold dedicated to secrets management.

To start their journey with Vault, the king's team launched a development server. This allowed them to experiment and learn without risking the security of the actual secrets. The development server simulated the real Vault environment, providing them with a safe space to explore its capabilities.

With the server up and running, the team initiated Vault by executing a special ritual known as initialization. Vault generated a set of initial root tokens and presented them to the team. These tokens granted unparalleled access and control over the secrets within Vault.

However, Vault was sealed shut to protect the secrets from unauthorized access. To unlock the vault's doors, the team used the unseal keys obtained during initialization. Each key acted as a unique piece of a puzzle, and combining them unsealed the fortress, making the secrets accessible.

Now that Vault was unsealed, the team embarked on their quest to interact with the kingdom's secrets. They leveraged Vault's command-line interface (CLI) and RESTful API to authenticate, store, retrieve, and manage secrets. Vault provided them with the tools and capabilities to ensure the secrets remained secure and accessible only to authorized users.

The team discovered that Vault employed secrets engines, magical entities responsible for managing different types of secrets. They enabled and configured secrets engines based on their specific needs. Each secrets engine possessed unique powers, allowing the team to generate secrets on the fly, store them securely, and retrieve them when needed.

To maintain order within the kingdom, Vault introduced access control. The team defined policies using a special language known as HCL (HashiCorp Configuration Language). These policies granted or restricted access to specific secrets and operations. They assigned policies to users, groups, or tokens, ensuring that only those with the right permissions could unlock the secrets' potential.

As the team delved deeper into their journey, they discovered that Vault's powers extended beyond the kingdom's borders. Vault seamlessly integrated with external platforms like Kubernetes, databases, and cloud providers. These integrations allowed the team to extend their secrets management practices beyond the boundaries of their kingdom, ensuring a holistic approach to security.

With time, the kingdom flourished under Vault's protection. Secrets remained secure, access was granted to those who deserved it, and the kingdom's sensitive information remained safe from harm. Vault had become an invaluable asset, empowering the kingdom and its people to harness the power of secrets responsibly.

And so, the story of Vault continued, empowering organizations far and wide to protect their secrets, maintain control, and keep their sensitive information away from prying eyes.

Vault is a popular open-source tool developed by HashiCorp that provides secrets management, secure storage, and access control for applications and infrastructure. It helps in safeguarding sensitive information such as API keys, passwords, certificates, and database credentials.

Installation and Setup:

Download and install Vault from the official HashiCorp website (https://www.vaultproject.io/). Choose the appropriate version for your operating system.
Follow the installation instructions provided in the documentation.

Running a Development Server:

Vault has a development mode that allows us to run it locally for testing and learning purposes. Start a development server by running the following command in our terminal:

vault server -dev

Initializing Vault:

Once the development server is running, initialize Vault by executing the following

vault operator init

Vault will generate a set of initial root tokens and provide you with unseal keys. These keys are crucial for managing and accessing Vault.

Unsealing Vault:

Vault is initially sealed to protect the sensitive data stored within it. Unseal Vault using the unseal keys generated during initialization. Run the following command for each unseal key:

vault operator unseal <unseal_key>

Interacting with Vault:

Vault provides a command-line interface (CLI) and a RESTful HTTP API for interacting with its services.
Use the CLI or API to authenticate, store secrets, and perform various operations.
Explore the available commands and capabilities by referring to the Vault documentation.

Secrets and Secrets Engines:

Vault uses the concept of secrets engines to manage different types of secrets.
Enable and configure secrets engines based on your requirements. Examples include KeyValue, AWS, Azure, Database, and more.
Secrets engines allow you to generate, store, and access secrets securely.

Access Control:

Vault provides robust access control mechanisms to manage who can perform specific operations and access certain secrets.
Define policies using the HashiCorp Configuration Language (HCL) to enforce fine-grained access control.
Assign policies to users, groups, or tokens to control their permissions.

Integrations:

Vault integrates with various tools and platforms, such as Kubernetes, databases, cloud providers, and more.
Explore Vault's documentation to learn about specific integrations and how to configure them.

_Vault has many features and capabilities beyond the basic steps outlined here. As a beginner, it's recommended to read the official Vault documentation _

EC2 - Elastic Compute Cloud

jhaji12 — Sun, 03 Apr 2022 11:18:38 +0000

Elastic Compute Cloud is a web service by AWS which provides scalable computing capacity. Here Computing refers to processing power, memory, networking, storage, and other resources. It offers infrastructure as a service(IaaS).

Amazon EC2 eliminates your need to invest in hardware up front, so you can develop and deploy applications faster. It is highly scalable and pay-as-you-go model.

Benefits of EC2 -

Features of EC2 -

Instances - It is a virtual server for running applications on AWS infrastructure.
AMI - Amazon Machine Image is a template that provides information required to launch instances.
Instance types - Amazon EC2 provides a total of 8 instance types which are classified according to their use cases. Instance types comprise varying combinations of CPU, memory, storage and networking capacity to give the client a flexibility to choose the appropriate mix of resources for your applications.
Secure Login - It allow secure login for your instances using key-pairs.
Regions and Availability Zones - It is a physical location around the world where data centers are clustered. Each group of logical data centers are called Availability Zone.
VPCs(Virtual Private Clouds) - It enables you to launch AWS resources into a virtual network that you've defined.

Amazon Machine Image

An Amazon Machine Image (AMI) is a template/prototype that contains a software configuration (for example, an operating system, server, and applications). From an AMI we can launch an instance, which is a copy of the AMI running as a virtual server in the cloud.
It includes EBS, Launch permissions, a block device mapping that specifies the volumes to attach to the instance when it's launched.

In the below diagram, it shows how we can create and register an AMI which includes EBS snapshot or template that can be used to launch new instance or to create another copy of AMI within same region or different AWS region. If we want any changes then we can deregister AMI and then launch it again.

In simple words AMI is a base image(it can include different OS) using which we can launch instances.

Creating an EC2 Instance - Hands on

Open the Amazon EC2 console at click here
To launch an instance click on ec2
Click on instances to see the instances and their running status

If there is no instance created you will see this

Click on new Launch instances and then it will show you all the AMIs that are available for different use cases. We will select windows (Microsoft Windows Server 2019 Base - ami-0f9a92942448ac56f) to launch an instance of windows OS.

On choosing the AMI, you will select the instance type according to your usage of CPU, RAM, Storage, bandwidth, if you are having free tier then only t2.micro is available.

Then you will choose the number of instances to be created from the AMI which is the configure instance details, this is the part where you can choose if you want to create a VPC.

Add Storage - Here you will decide the size and volume type according to your requirements.

Add Tags - We can add tags for our convenience it will be easier to identify and manage our instances like name, department, etc.

Configure Security group - Here we can decide how we want to access our instances, we can choose the protocol type(RDP,HTTP, HTTPS, SSH). RDP stands for Remote Desktop Protocol which will allow us to create remote desktop for windows. We can also decide who can access our instance. As you will see this warning

Warning
Rules with source of 0.0.0.0/0 allow all IP addresses to access your instance. We recommend setting security group rules to allow access from known IP addresses only.

Review and Launch will allow you to check your instance launch details. You can go back to edit changes for each section. Click Launch to assign a key pair to your instance and complete the launch process.
On clicking launch, AWS asks for a key which you download and use to access via RDP download and keep the key safe as it only can be downloaded once. You can also select a previous key if you have a key generated already.

As you can see your instance is in running state, Select the instance you want to connect and click on connect button

Download the remote desktop file

Click on get password which you will need while login to the Remote desktop. Now upload the download .pem file or the key pair value that you have generated while launching the instance.

After uploading click on decrypt password and copy the password so that you can use it to login the Remote Desktop Connection.

Go to the downloaded remote desktop file and use the password to login. Here you go with the remote desktop connection, create your application and it is totally independent from your personal computer having it's own property.

Likewise you can create an instance for different AMIs.

If you want to create a template of your instance then stop the instance from running and then you can create templates of launched instances.

Likewise, you can create an image of your instance to launch another instance using your saved image(my AMIs) instead of using AMI.

That's all for this blog.
Next I will be creating a blog on Instances and their types.

Understanding the Dockerfile Commands

jhaji12 — Wed, 30 Mar 2022 08:01:45 +0000

"Blueprint for creating a docker image"

Docker builds images automatically by reading the instructions from a Dockerfile.
It is a text file without any .txt extensions that contains all commands in order, needed to build a given image.
It is always named Dockerfile.

Docker image consists of read-only layers each of which represents a Dockerfile instruction. The layers are stacked and each one is created by the change from the previous layer. For example, if I create a base layer of ubuntu and then in second instruction I install Python it will create a second layer. Likewise, if I do any changes by the instructions(RUN , COPY , ADD) it will create a new layer in that image.

Containers are read-write layers that are created by docker images.

In simple words, a Dockerfile is a set of instructions that creates a stacked-layer for each instruction that collectively makes an image(which is a prototype or template for containers)

Frequently used Dockerfile commands -

FROM - Defines a base image, it can be pulled from docker hub
(for example- if we want to create a javascript application with node as backend then we need to have node as a base image, so it can run node application.)
RUN - Executes command in a new image layer( we can have multiple run commands )
CMD - Command to be executed when running a container( It is asked to have one CMD command, If a Dockerfile has multiple CMDs, it only applies the instructions from the last one.
EXPOSE - Documents which ports are exposed (It is only used for documentation)
ENV - Sets environment variables inside the image
COPY - It is used to copy your local files/directories to Docker Container.
ADD - It is more feature-rich version of the COPY instruction. COPY is preferred over ADD. Major difference b/w ADD and COPY is that ADD allows you to copy from URL that is the source can be URL but in COPY it can only have local ones.
ENTRYPOINT - Define a container's executable (You cannot override and ENTRYPOINT when starting a container unless you add the --entrypoint flag.)
VOLUME - It defines which directory in an image should be treated as a volume. The volume will be given a random name which can be found using docker inspect command.
WORKDIR - Defines the working directory for subsequent instructions in the Dockerfile(Important point to remember that it doesn't create a new intermediate layer in Image)

#Basic Dockerfile FROM ubuntu:18.04 COPY . /app RUN make /app CMD python /app/app.py

Each instruction creates one layer:

FROM creates a layer from the ubuntu:18.04 Docker image.
COPY adds files from your Docker client’s current directory.
RUN builds your application with make.
CMD specifies what command to run within the container.
Let's see this demo example of Docker layer architecture-

If some files should be prevented from being copied into the Docker image(it can be sensitive informations like .env files which contains API keys or any other files that are not much important), a .dockerignore file can be added at the same level as the Dockerfile where files that should not be copied over into the Docker image can be specified. By this if we are using a COPY or ADD instruction in a Dockerfile to specify the files to be added into a Docker image, any file specified in the .dockerignore file will be ignored and not added into the Docker image.

Shell and Exec forms

All three instructions (RUN, CMD and ENTRYPOINT) can be specified in shell form or exec form.

Shell form

RUN apt-get install python3
CMD echo "Hello world"
ENTRYPOINT echo "Hello world"

Exec form
This is the preferred form for CMD and ENTRYPOINT instructions. ["executable", "param1", "param2", ...]

Difference between RUN,CMD and ENTRYPOINT?

RUN - RUN instruction allows you to install your application and packages required for it. It executes any commands on top of the current image and creates a new layer by committing the results. Often you will find multiple RUN instructions in a Dockerfile.

RUN apt-get install python

CMD - CMD instruction allows you to set a default command, which will be executed only when you run container without specifying a command. If Docker container runs with a command, the default command will be ignored. If Dockerfile has more than one CMD instruction, all but last CMD instructions are ignored.

CMD "echo" "Hello World!"

ENTRYPOINT - ENTRYPOINT instruction allows you to configure a container that will run as an executable. It looks similar to CMD, because it also allows you to specify a command with parameters. The difference is ENTRYPOINT command and parameters are not ignored when Docker container runs with command line parameters.

Prefer ENTRYPOINT to CMD when building executable Docker image and you need a command always to be executed. Additionally use CMD if you need to provide extra default arguments that could be overwritten from command line when docker container runs.

Choose CMD if you need to provide a default command and/or arguments that can be overwritten from command line when docker container runs.

To know more about it -
Click here

Docker For Beginners

jhaji12 — Thu, 24 Mar 2022 09:48:12 +0000

Small Story to Understand the use of Containers 🧙🏻‍♀️
"Let's meet our Characters first -

John (Software Developer)🙋🏻‍♂️

Harry(Software Tester)👨🏻‍💼

John is a fresher and he is very excited to start his journey as a software developer. He is working on his first project which involves multiple languages, frameworks, and different libraries. According to his requirements, he use to install all the dependencies on his machine. 👨🏻‍💻

Successfully, he was able to finish his project and it was running fine on his machine.

Next, he has to verify his project, so he sent the code to the testing team. Harry checked the code and It shows an 'Error ' ❌, but we know that the code runs fine on John's machine.

The problem comes with dependencies. All the dependencies that are used by John are different from what is being used by the tester which creates the problem. It can be due to the change in versions( for ex: John has used python 2.0 and the testing team is using python 3.0) or maybe there are some dependencies that John may not be knowing about and it is getting used in the app( Because that dependency was already installed in his machine). There are many reasons for the error that are not possible to detect again and again.

Now, we know that some dependencies or libraries are dependent on the Operating System as well, which may also be one of the reasons. It is not possible to transfer the OS itself to the testing team for John. 🤷🏻‍♂️

Here, comes the role of Containers.

With the help of Containers, John can isolate his application from the environment, which solves the 'It works on my machine' problem. By this, his application can run quickly and reliably from one computing environment to another.

John gets appreciation from the manager, and he is very happy with his job and the team

🕺🕺🕺🕺🕺🕺🕺🕺🕺🕺🕺🕺🕺🕺🕺🕺🕺🕺🕺🕺🕺🕺🕺🕺🕺🕺🕺🕺🕺🕺🕺🕺🕺🕺🕺🕺🕺🕺🕺🕺

What are Containers?

Creating a Docker container can be described as creating a small software package that can run a particular application and its associated processes.

The container that you create becomes portable and can be run on Docker installations on all types of computers in the same way without fear of compatibility issues.

What is the need for Containers if we have Virtual Machines?

A Virtual Machine (VM) is a compute resource that uses software instead of a physical computer to run programs and deploy apps. One or more virtual “guest” machines run on a physical “host” machine. Each virtual machine runs its own operating system and functions separately from the other VMs, even when they are all running on the same host. This means that, for example, a virtual Mac OS virtual machine can run on a physical PC.

There are disadvantages that became the reason for using Containers-

Running multiple virtual machines on one physical machine can result in unstable performance if infrastructure requirements are not met.
Virtual machines are less efficient and run slower than a full physical computer.
Whereas, Containers can be started much quicker than Virtual Machines. This is because the container is using the underlying host computer's Operating System, and not starting its own whenever it launches

What is a Docker?

Docker is an open platform for developing, shipping, and running applications. Docker enables you to separate your applications from your infrastructure so you can deliver software quickly.

Docker Architecture

Docker uses a client-server architecture. In simple words, Client communicates using REST API with daemon requesting for pull, build, run commands. Daemon accepts the commands and does the heavy lifting of building, running, and distributing your Docker containers. If a client is requesting to pull an image, then first it will communicate with daemon, and daemon will search for the image in local image registry, If not found then it will search it in Default Registry i.e Docker Hub and then the image will be sent to the client by daemon.

Docker Client -

When you use commands such as 'docker run', the client sends these commands to dockerd(Daemon), which carries them out. The docker command uses the Docker API to connect with daemon.

The Docker daemon

The Docker daemon (dockerd) listens for Docker API requests(from client) and manages Docker objects such as images, containers, networks, and volumes.

Docker registries

A Docker registry stores Docker images. Docker Hub is a public registry that anyone can use, and Docker is configured to look for images on Docker Hub by default. You can even run your own private registry.

Images

An image is a read-only template with instructions for creating a Docker container. Often, an image is based on another image, with some additional customization. For example, you may build an image which is based on the ubuntu image, but installs the Apache web server and your application, as well as the configuration details needed to make your application run.