Frontend Engineering Interview Questions

We have a Git repository on the folder repo that has a feature branch feature login. This feature branch was created from the wrong base branch. It was created from the base branch main while it had to be created from the branch develop. We need to rebase feature login branch from the develop while preserving all the commits. First we need to move to our Git repository and run git log. All, one line and graph are optional fields. Try to rebase our feature login from the develop. For this, we need to either switch or checkout feature login branch. I'll use checkout, but you could use switch as well and we'll rebase this branch. If there'll be conflicts, we can resolve them.

We have a Git repository that has detached head. Head is basically our latest commit and detached head means that the head that we are currently located at is not pointing to any Git branch, any points directly to commit or tag. It happens when we check out directly tag or we check out directly at comit hash, or we can check out some remote branch. How we can restore from detached head is we either need to return to some existing branch or we have to create a new branch from that detached head. Run git status. We can see that GIT message that head is detached. We'll create new branch by typing Git Checkout the name of the branch, or you can run more modern command Git Switch. Run checkout minus B. And then name of the branch.

We have a feature branch feature API, and this is our repository folder. We have to provide unique commits and we will need to exclude merge commits, and write unique commits to this text file. Type git branch to see all our branches. View current logs for feature branch. The two dots shows commits in feature API branch, but not in origin main. This reveals only unique work on this particular branch. Next we need to exclude merge commits. We will add another flag. Once we added no merge flag, we get three commits. The final thing is we need to save this output to the file.

We have some files that have been created during the time when we worked in this directory, meaning some build outputs, some temporary files and so on. We need to locate all those untracked files and clean them up. First we need to run git status to get all untracked files. Next, we'll run git clean. This is the main command that this question is about. Hyphen n to run this in dry mode. We'll see what is going to be deleted and hyphen d to delete directories as well. It'll remove untracked directories and untracked files. Run git clean fd, which will remove files and directories. Everything now has been cleaned up.

We need to change our git repository from HTTPS to SSH remote origin. First we'll need to go to this directory, then check current remote configuration git remote -v. Finally, use git remote set-url to configure SSH URL. Additionally, in order to connect to this repository, you need to add your public keys to GitHub. To do this, you can type ssh-keygen, type enter multiple times, check your public key, and you'll need to copy this public key into your GitHub account.

We have a Git repository. Under this folder we have a feature payment branch and it's behind our main branch by 32 commits. We need to rebase a feature branch onto the latest main. We need to bring all the latest changes from main to this feature branch. Switch to feature payment branch. We need to rebase from main. Type git rebase main. We have conflicts. Some of the commits cannot be rebased. We have two changes for the same line. Remove the obsolete one and keep what we need. And now we can git add and git rebase continue. We've successfully rebased and updated feature payment.

Git stash lets us to save our work in progress, go to some other task, and then return back, restore our stashed work, and continue from that moment on. We can save multiple work in progress jobs, so we can have multiple stashes. We have to navigate to this repository, identify the third stash in the list and restore that. So we need to apply it without removing it from the stack. Run git stash list. This will show us list of the stashed work. Index starts from zero. In order to restore this, git stash apply stash and then two. This will still retain stash number two in the list. In order to remove stash from the list, we need to run command git stash drop and then the name of the stash. Another command to restore stash is git stash pop. Git stash pop applies the latest stash, meaning stash number zero, and then drops it from the list.

When we have specific format of the branch names that we have to follow, and if it's not in the specific format, those pushes will be rejected. We have a local branch named feature new feature that violates this naming convention and we need to change this to feature slash new feature. Once it's changed, we have to push those changes into remote repository and we have to delete that repository from the upstream. We need to rename this branch by typing hyphen M, which will move feature new feature to feature slash new feature name. Since our branch is renamed, we need to push this new branch to the remote repository, and while pushing this, we have to create an upstream. Why we create an upstream is to link this local feature slash new feature to the remote feature new feature branch. We'll use git push command with origin, but with hyphen hyphen delete flag, and then the name of the old branch name.

We've committed some local changes that contain incorrect changes and we need to completely erase that from history. Our task is to navigate to this repository, remove last commit entirely. The most important thing here is to discard all associated files changes. First run get log to see all the current commits. We will go a few steps back, and we also need to discard all associated file changes. This means that this is not soft reset, which will reset that, but keep the local changes. So this has to be a hard reset. We have bad commit, wrong changes. It's the last commit and we will reset it. One commit back, run Git, reset hard at one.

We need to navigate to the folder workspace and clone into this directory a repository located here named Shallow Rebel, and we need to restrict that to the latest commit only. We don't need to copy entire history, but just latest commit. Cloning only latest commit called shallow clone and command for this would be git clone depth one meaning only last commit, location of the repository and the name of it. Our repository was cloned. Move into it and see the logs. We see only latest log commit 50.

We have two branches, main and feature settings, and we have a file config json that is located in the feature branch. We need to copy this file into the main branch. We don't need to cherry pick the commit. Cherry pick and copying one single file is different. Cherry picking adds specific commit from another branch to the branch that we are in currently. When we need to copy the file, we need to check out, but we need to check out specific file. GI Checkout, and we type the name of the branch and then Hyen and name of the file that we would like to check out. Now if we run Git status, we'll see this file as modified in our directory.

We've got repository and a feature branch and commits are in wrong logical order. What is being asked from us is to reverse the order and also replace this feature branch from Maine. Navigate to repository folder. Check the logs and we've got four commits. We'll need to first Rebase feature branch and then we will need to reverse this order. While doing GIT rebase, we can change order of our commits. We've changed the order. Save this file control O and close it. Control X, we've successfully rebased our branch.

Bootstrap new projects with Git version control by creating project directories and initializing repositories. Use git init to establish version control infrastructure, verify .git directory creation, and prepare projects for commit and collaboration. Essential for starting new projects, establishing version control foundation, enabling team collaboration, and implementing proper source code management from project inception.

We have a repository and have some untracked files. We need to move to the repository and stage that untracked file. So during next commit, this file will be committed. Type git status to see all untracked files. We have one untracked file. Use git add to stage that file. Alternatively, we can use git add . to add all untracked files. Try git status again, and now this file was added.

We have two branches, main and development, and we need to create feature login based on the development branch. First move to this repository. Next we'll check out our development branch. If we type git branch and name of the branch, it'll create new branch from the development branch because we are in development branch. We can type git branch -a to see all created branches and feature login was created. Alternatively, if we're on the main branch and we don't want to switch to different branch, we can type git branch, the name of the branch we would like to create, the name of the branch that we would like to create this one from.

We have a Git repository on the home repo that has been created already, and we've modified three files, app js, style css, and config json. We need to stage only app js and style css. Staging means that those files will be committed and could be pushed to a remote repository and so on. And we'll leave config unstaged. Move to the repo directory. Use git add to stage files app js and style css. Use git status and we can see that those two files are staged as config json is not staged.

We have a Git repository where we did some mistake. We need to revert last three commits so we can recommit it more properly. Run Git status to see any uncommitted changes and we have nothing to commit. We need to run Git reset soft head three means we go back. An important part here is this soft. It means that we'll revert back to three commits, but we will keep the local changes intact, meaning they'll be staged. If we reset hard, we will discard local changes as well. We reset everything, local changes and commits. We can see that those files are modified, they're staged, they're not reset.

We have repository under this directory and we need to merge feature login into the main. View list of our branches by typing git branch hyphen v. The important thing, when we merge, we have to be in the branch to which we are merging. We are merging something in the main, we have to be in the main branch, and while we're in the main branch, we type git merge and the branch that we would like to merge into the main. Lastly, we need to delete the feature branch. For this we'll use git branch D to delete, and the name of the branch that we would like to delete.

Document commit history by exporting commits to files for reports, changelogs, and documentation. Use git log --oneline with output redirection to create commit history files, generate reports, and maintain commit records. Essential for documentation, changelog generation, audit trails, project reporting, and maintaining commit history snapshots for reference.

We have a git repository and we have a feature branch called feature. This feature branch contains a fix that fixes the bug on main, but we don't want to move all the commits from feature branch to the main. We just want to pick one commit and move only that. That's called cherry picking. We need to navigate to this repository, identify the commit that fixes the main branch and move it to the main from feature. See the git log to identify the commit that fixes the bug on main, so this commit has message fix critical bug. Next, we need to type git cherry pick and hash of this commit. This commit now was added to our main branch.

We have a Git repository under this folder with a branch main. In this repository we have a code owner's file which defines the owners of this repository who are authorized to make changes. And we have config json file with configurations of the database with a password and other information for the connection. Our task is to check who has modified the database password for this file and if it was modified by someone who is unauthorized, we have to revert this. During that process we have to use default, no edit revert message. Once it's done we have to push the corrected version. We'll type git log P one conviction. We'll check last commit and we can see that modification was done by someone who is not in the code owner's file. We will revert last commit. We will type ahead because it's in the head of the branch. This is a special flag, because otherwise if you try to GI revert, it will offer you to type your own message. Then GI push origin made.

We have a Git repository where we have a file config gs. This file has been modified in the last two commits, but those two commits introduced a bug. We need to restore config gs to the version that it had two commits ago while not affecting any other file. Run Git log to see last five commits. Next, we'll preview config gs that was two commits ago, for this we'll type git show head meaning our current last commit and then the sign, and then two. Next, we'll type git checkout head tilde sign two and then two hyphens config gs, which will restore config gs that was two commits ago. Last thing, we need to commit our changes with restore config gs message.

We have Git Repository located on this directory which is completed new version of our application. We need to create an annotated tag, and once it's created, we need to push that to remote repository with this name. First, move to this directory, view current commit. This is our latest commit at head of our branch. A lightweight flag just references some commit. It doesn't have its own SHA hash meaning that cannot reference the tag. Annotated tag, however, has its own SHA, so you can reference that. Verify that tag was created by typing Git Tag. And now push this.

Integrate external repositories as submodules to manage dependencies without code duplication. Add submodules with git submodule add, configure .gitmodules file, initialize submodule directories, and commit configuration. Essential for managing shared libraries, vendor dependencies, monorepo structures, and maintaining decoupled version control across interdependent projects.

We have a repository interview repo that contains a submodule vendor details and submodule lets us nesting repositories. When submodule is used, it uses the specific commit. We need to update a submodule to the latest commit on its default branch. Run git submodule to see our submodule status. Next, run git fetch and then log to see commits in our submodule. We need to pull latest changes. Go to the parent and check status again. Those changes are not committed yet. We run git add and then git commit. Submodule is updated to the latest version.

Imagine a common scenario when you've been working on some git repository on the feature ui and suddenly you need to do something to fix authentication issue on the main branch. For this, you have to create new hotfix branch, commit changes into that branch and then merge that with main branch. While you've been working on feature ui, you cannot simply change the branch because you have uncommitted changes. Before moving to main branch, we need to stash those changes, meaning to put them aside. Next, move to our main branch and to fix our authentication issue, we first need to create hotfix branch. Move to the main branch and merge our hotfix with main. And finally we delete the hotfix branch since we don't need it anymore. We need to move back to our work that we paused meaning to feature ui, and then rebase it from main. Finally, we need to move back the work that we stashed aside. For that, we need to type git stash pop.

We've committed file secrets env, which contains some sensitive credentials and we have to remove this from entire git history. First we'll need to move to the repository directory. Check logs that contains secret env file. For this we'll type git log all to see all logs, one line to see them in one line. In order to filter it by the file name we type hyphen and then name of the file. To see exactly what was changed in those commits we can add hyphen p flag. We need to delete this from our current git history and for this we'll run command called git filter branch. We'll run force flag to change this in entire git history. And we'll use the filter flag that lets us run certain command. And the command is basic Linux syntax rm to remove file. Prune empty flag is used in certain cases that removing this will make the commit useless. Finally, we need to delete the history file, meaning we need to run rm rf to delete everything in the git refs original. In case if we'd like to change also this on the remote origin, we need to run git push force all.

In our Git repository home interview repo, we have file called script sh. This file gets consistently shown as modified when we run git status. The reason for this consistent change is when we run git diff, it shows every line has changed with this symbol, which indicates line ending difference between Windows style systems and Linux style systems. Our task is configure git to handle line endings automatically and fix this issue. To fix this, we need to implement git attributes that will automatically fix the line endings and also enforce this to the sh files. Once this file is applied, we need to renormalize our git repository by running git add hyphen hyphen renormalize and current directory.

We have two separate git repositories, repo A and repo B, five and four commits respectively. They've been developed independently, so have different histories, and we need to create one monorepo, combine both of them and have full commit history. Important thing is we need to use subtree. Subtree is git subtree command used when we have some shared libraries or other shared resources when we do not want to merge everything into one monorepo, but rather have some repository and reference other repositories in a directory. We'll use git log one line. Create a directory and then initialize git inside this directory. We'll do git init. We'll do our first commit. We'll do empty commit, so we'll need to add a empty flag. Now we will need to integrate our directories as a subtree in our repository. Use git subtree add, and then we use prefix project A. Finally, verify our monorepo. Check it with Git logs.

The repository interview is in broken state. The local and remote branches diverged with no common ancestor, meaning they don't share the same history. When we use Git Push to push things to the remote main, it fails with non fast forward error. And the same happens when we try to pull from Main. Our task is to fix this repository, merge and linearize the unrelated histories using Rebase and create new single commit sequence. When we use Git merge, branch that was merged into the main branch retains the same commit hashes. When we use Rebase, those commit hashes get rewritten. Next we'll pull main and we'll Rebase not merge. The flag that we'll use in this case is allow unrelated histories. We need to resolve this issue. Those three are the main types of the conflicts: modify modify, modify delete, add add. Once this is done, we have to type Git rebase continue.

Handle urgent work interruptions by stashing incomplete feature work, switching branches cleanly, fixing bugs, and restoring work exactly as it was. Use git stash for temporary storage, switch branches without commits, fix urgent issues, and git stash pop to resume. Essential for interrupt-driven development, urgent hotfixes, emergency bug fixes, and maintaining productivity during context switching.

We had Git repository located under this directory and we've been in detached head state. When we switch the main branch, those three commits are now unreachable and we'd like to restore those three commits. When we do git log, we don't see those commits, so we need to find a solution to restore those commits and create a branch called recovered work where those commits will be listed. To see all the logs that we've done to the head of this branch, meaning the ones that were lost from the detached head or while we did git reset and so on, we can type command called git reflog. Git reflog shows us logs exactly for the head. In this git reflog we can see that we have much more than we have in git log. Since our task is to restore this with the branch recovered work, we have to create branch recovered work from some Git commit. We'll use this git commit's hash.

Users are complaining about slow file access and we have high disc utilization. We need to reduce IO activity of top offenders using IO priorities and we need to settle the IO priority to idle. While doing so, we need to keep critical jobs, databases, message queues, applications at high priority. First we need to identify processes that have high IO activity. We'll use IO top command, and we at hyphen N 10 at the end of this command. This means that this command will run 10 times. To check current IO priority of job one, we need to use ionice command. First we need to look into process ID of this job. We have no priority set for this process, and we need to set this to idle. And idle will be priority number three. The command for this will be ionice three and the process ID.

We have multiple applications that write their logs under var slash log. An issue with this approach is that since multiple logs file are constantly being written to this folder, checking them one by one would be slow and inefficient. We want to use this file to consolidate all the lines that contain errors and write them here. We can use grep and we'll use recursive flag to get error lines in var slash log folder, and it will include only files that are in dot log extension. What we left to do is send this into the consolidated error logs file.

We have developer account dev that has been locked out of the server and security logs indicate that there were too many failed SSH identification attempts. We need to check logs and count exactly how many attempts this user had today. And once we have this number, we need to update the configuration to increase this allowed login attempts above this number. We'll need to check log for login attempts. We'll need to use sudo to view this as admin. We can use grep command to filter out the lines that we need. We can also count this with word count hyphen L, which will print us number of lines. We need to change SSHD daemon configuration file, which is located under etc ssh and then sshd config. Find something that says Max. Finally, restart sshd daemon using systemctl restart.

When we build our container from this file, it builds it in architecture of our host system. Our task is to change the setup to build it in multiple architectures. We'll use Docker build with an instance named Multi Arc and we will use buildx create. We'll list current builders by typing Docker buildx ls. We have only default that builds it in our current platform's underlying os. So add new builder. Docker buildx create and then name multi arc. Then we use driver network host and then use to have it as default builder. Now attempt to build for our multi architecture setup. We'll run Docker buildx build. Verify this by typing Docker images.