-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
Showing
21 changed files
with
2,334 additions
and
12 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,19 @@ | ||
+++ | ||
title = 'CLI: Bootable USB From ISO' | ||
date = 2024-03-31T09:29:19-23:53 | ||
draft = false | ||
+++ | ||
|
||
Check if flash drive is properly plugged and identify its label (something like `/dev/sda`): | ||
|
||
```bash | ||
sudo fdisk -l | ||
``` | ||
|
||
Run `dd` command to make a bootable USB from the ISO file: | ||
|
||
```bash | ||
sudo dd bs=4M if=/path/to/file.iso of=/dev/sdX status=progress oflag=sync | ||
``` | ||
|
||
Replace `/path/to/file.iso` with the path to your ISO file and replace `/dev/sdX` with the name of your device. |
79 changes: 79 additions & 0 deletions
79
content/notes/coding-interview-technical-questions/index.md
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,79 @@ | ||
+++ | ||
title = 'Coding Interview: Technical Questions' | ||
date = 2024-03-09T07:50:00-00:00 | ||
draft = false | ||
+++ | ||
|
||
# Walking Through A Problem | ||
|
||
1. **Listen**: pay attention very closely | ||
2. **Example**: debug your example and find special cases | ||
3. **Brute force**: state a naive algorithm and then optimize it | ||
4. **Optimize**: BUD Optimization or look (or ask) for unused info, make time vs. space tradeoff | ||
5. **Walk Through**: make sure you understand each detail of your optimal solution before coding | ||
6. **Implement**: modularize your code from the beginning and refactor | ||
7. **Test**: code review, look for hot spots and special and edge cases | ||
|
||
### Technique #1: BUD Optimization | ||
|
||
Acronym for **B**ottlenecks, **U**nnecessary work and **D**uplicated work. Bottleneck is a part of your algorithm that slows down the overral runtime. Common ways this occurs are having one-time work that slows down your algorithm and having a chunk of work that is done repeatedly (like searching). Then look for unnecessary and duplicated work. | ||
|
||
### Technique #2: Do It Yourself | ||
|
||
Use a nice, big example and intuitively solve it. Think hard about how you solved it and reverse engineer your own approach. | ||
|
||
### Technique #3: Simplify And Generalize | ||
|
||
Multi-step approach that simplify some constraint (such as the data type). Solve the simplified version of the problem and then adapt for a more complex version. | ||
|
||
### Technique #4: Base Case And Build | ||
|
||
Solve the problem first for a base case and then build up for more complex cases. Generally lead to recursive algorithms. | ||
|
||
### Technique #5: Data Structure Brainstorm | ||
|
||
Solving a problem may be trivial once it occurs to use a specific data structure. The more problems you do, the more developed your instinct on which data structure to apply will be. | ||
|
||
# Handling Situations | ||
|
||
### Handling Incorrect Answers | ||
|
||
Candidates don't need to get every question right. You will be evaluated about how optimal your final solution was, how long it took to get there, hhow much help you needed, and how clean was your code. You will also be evaluated in comparison to other candidates and the questions my be too difficult to expect even a strong candidate to immediately spit out the optimal algorithm. | ||
|
||
### When You've Heard A Question Before | ||
|
||
If it occurs, admit this to your interviewer. Otherwise it may be highly dishonest if you don't reveal that you know the question and, conversely, you'll get big honesty points if you do reveal this. | ||
|
||
### The Perfect Language For Interviews | ||
|
||
Many top companies interviewers aren't picky about languages. Choose whatever language you're most comfortable with considering some points. | ||
|
||
- **Prevalence**: It's ideal for your interviewer to know the language you're coding in. Prefer widely known languages. | ||
- **Readability**: Languages such as Scala or Objective-C have fairly different syntax. | ||
- **Potential Problems**: For example, using C++ means that, in addition to all the usual bugs you can have in your code, you can have memory management and pointer issues. | ||
- **Verbosity**: Languages with simple syntax may be preferred, but some verbosity can be reduced by abbreviating code (most interviewers wouldn't mind) | ||
- **Ease of Use**: Some operations are easier in some languages than others. | ||
|
||
# Writing Good Code | ||
|
||
A good code is correct, efficient, simple, readable and maintainable. Striving for these aspects requires a balancing act. For example, it's often advisable to sacrifice some degree of efficiency to make code more maintainable, and vice versa. | ||
|
||
### Use Data Structures Generously | ||
|
||
Design your own data structure may be a good solution in some cases. It's a good point to evaluate with the interviewer. Some might argued that this is over-optimizing. | ||
|
||
### Modular | ||
|
||
Separate isolated chunks of code out into their own methods. This helps keep the code more maintainable, readable, testable and reusable. | ||
|
||
### Flexible And Robust | ||
|
||
Use variables instead of hard-coded values, use templates to solve a problem. You should write your code to solve a more general problem. | ||
|
||
### Error Checking | ||
|
||
Adopt failing fast and don't make assumptions about the input. If the error checks are much more than a quick if-statement, it may be best to leave some space where the error checks would go and indicate to your interviewer that you'll fill them in when you're finished with the rest of the code. | ||
|
||
# Don't Give Up! | ||
|
||
Interview questions can be overwhelming, but this is how they are supposed to be. It shouldn't be a surprise when you get a really tough problem. Show excitement about solving hard problems for extra points. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,169 @@ | ||
+++ | ||
title = 'Data Structures' | ||
date = 2024-03-09T07:50:00-00:00 | ||
draft = false | ||
+++ | ||
|
||
# Arrays | ||
|
||
A contiguous memory block that stores elements of the same data type. The memory address of the first element in the array is the base address and any other element's address can be calculated using the base address and the size of each element. | ||
|
||
```python | ||
array = [] | ||
array.append(1) | ||
array.append(3) | ||
print(array[1]) # 3 | ||
array.append(2) | ||
print(array.remove(3)) # 3 | ||
print(array.index(2)) # 1 | ||
``` | ||
|
||
### Operations | ||
|
||
- **Access by index**: `O(1)` by calculating the position | ||
- **Access by value**: `O(n)` by traversal | ||
- **Write in the beginning**: `O(n)`, requires shifting elements | ||
- **Write in the end**: `O(1)`, no shifting required | ||
|
||
### Pros And Cons | ||
|
||
**Pros**: Direct access using indexes, contiguous storage minimizes memory overhead, easy to sort. | ||
**Cons**: Fixed (limited) size, inefficient writing due to shifting, unfilled memory keep allocated. | ||
|
||
# Linked List | ||
|
||
```python | ||
class ListNode: | ||
def __init__(self, val=0, next=None): | ||
self.val = val | ||
self.next = next | ||
|
||
class LinkedList: | ||
def __init__(self): | ||
self.head = None | ||
# implements the following methods: | ||
# def append(self, val): | ||
# def remove(self, val): | ||
# def display(self): | ||
``` | ||
|
||
A linear data structure where elements (nodes) are connected through pointers. Doesn't require contiguous memory locations and each node contains a reference to the next one, allowing to be placed anywhere in the memory. | ||
|
||
### Operations | ||
|
||
- **Access by index**: `O(n)` by traversal | ||
- **Access by value**: `O(n)` by traversal | ||
- **Write in the beginning**: `O(1)` by pointing the new node to the old head | ||
- **Write in the end**: `O(n)` by traversing and then pointing the last node to the new | ||
|
||
### Pros And Cons | ||
|
||
**Pros**: Dynamic size, no waste of memory, more efficient writing operations. | ||
**Cons**: Access always requires traversing, node requires extra memory for pointers, traversing have a higher constant factor compared to arrays. | ||
|
||
# Stack | ||
|
||
It's a LIFO-behaved data structure with a pointer to the last element for fast access. The stack itself is a pre-allocated region of memory with a fixed size, and the memory for individual function calls on the stack is dynamically managed. So the nature of the allocation depends on the type of stack and the context in which it's used. | ||
|
||
```python | ||
stack = [] | ||
stack.push(1) | ||
stack.push(3) | ||
print(stack.pop()) # 3 | ||
stack.push(2) | ||
print(stack.pop()) # 2 | ||
print(stack.pop()) # 1 | ||
``` | ||
|
||
### Operations | ||
|
||
- **Access in the end**: `O(1)` by stack pointer | ||
- **Write in the end**: `O(1)` by accessing via stack pointer and updating it | ||
|
||
# Queue | ||
|
||
It's a FIFO-behaved data structure that also can be pre-allocated or dynamically allocated depending on the type and context. | ||
|
||
```python | ||
from collections import deque | ||
|
||
queue = deque() | ||
deque.append(1) | ||
deque.append(3) | ||
print(queue.popleft()) # 1 | ||
deque.append(2) | ||
print(queue.popleft()) # 3 | ||
print(queue.popleft()) # 2 | ||
``` | ||
|
||
### Operations | ||
|
||
- **Access in the beginning/end**: `O(1)` by pointers | ||
- **Enqueue (insertion)**: `O(1)` by accessing via pointer and updating it | ||
- **Dequeue (deletion)**: `O(1)` by accessing via pointer and updating it | ||
|
||
# Hash Map | ||
|
||
It's a key-value pair collection, where each key is unique. It provides operation efficiency (**all operations are** `O(1)`) through memory overhead. Uses hashing function to convert a key into an index and maintains an array where each index corresponds to a bucket that can hold multiple pairs. | ||
|
||
# Set | ||
|
||
It's a unordered collection of distinct elements. Internally uses hash maps and **all operations are** `O(1)`. | ||
|
||
# Binary Tree | ||
|
||
It's a hierarchical data structure in which each node has at most two children and the topmost node is called root. | ||
|
||
### Traversal | ||
|
||
```python | ||
def preorder_print(self, start, traversal): | ||
"""Root->Left->Right""" | ||
if start: | ||
traversal += (str(start.value) + "-") | ||
traversal = self.preorder_print(start.left, traversal) | ||
traversal = self.preorder_print(start.right, traversal) | ||
return traversal | ||
``` | ||
|
||
```python | ||
def inorder_print(self, start, traversal): | ||
"""Left->Root->Right""" | ||
if start: | ||
traversal = self.inorder_print(start.left, traversal) | ||
traversal += (str(start.value) + "-") | ||
traversal = self.inorder_print(start.right, traversal) | ||
return traversal | ||
``` | ||
|
||
```python | ||
def postorder_print(self, start, traversal): | ||
"""Left->Right->Root""" | ||
if start: | ||
traversal = self.postorder_print(start.left, traversal) | ||
traversal = self.postorder_print(start.right, traversal) | ||
traversal += (str(start.value) + "-") | ||
return traversal | ||
``` | ||
|
||
# Heap | ||
|
||
Is a specialized tree-based data structure that satisfies the heap property (for max and min heaps) and **all operations are** `O(log n)`. It's used to implement priority queues, for heap sort and graph algorithms like Dijkstra's. | ||
|
||
```python | ||
import heapq | ||
|
||
min_heap = [] | ||
heapq.heappush(min_heap, 4) | ||
heapq.heappush(min_heap, 1) | ||
heapq.heappush(min_heap, 3) | ||
min_element = heapq.heappop(min_heap) | ||
print(min_element) # 1 | ||
|
||
max_heap = [] | ||
heapq.heappush(max_heap, -1) | ||
heapq.heappush(max_heap, -4) | ||
heapq.heappush(max_heap, -3) | ||
max_element = -heapq.heappop(max_heap) | ||
print(max_element) # 4 | ||
``` |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,40 @@ | ||
+++ | ||
title = 'Interview Storytelling' | ||
date = 2024-03-10T12:58:19-23:53 | ||
draft = false | ||
+++ | ||
|
||
This post is inspired in a [video from A Life Engineered](https://www.youtube.com/watch?v=hU6BVxtGd5g) that gives many advices about telling good stories. He also explains how STAR model is more like a linter than a way to structure your story and compare it with U-shape model. This is also a fast cheatsheet, I won't talk about any of these topics in depth. | ||
|
||
### General Tips | ||
|
||
- Present yourself very quickly | ||
- Do your homework and bring questions to the interviewers | ||
- Talk about what you've done, not your team | ||
- Challenges may be compatible with the level you aim | ||
- Anchor your status and show that you can handle challenges of your level | ||
- Show your career progression and growth mindset | ||
- Have a good story to tell about your journey in programming | ||
|
||
### U-shape | ||
|
||
- Stablish **status** about yourself | ||
- Explain the **challenge** and then deep dive into it | ||
- Introduce **obstacles** | ||
- **Climb** until the situation is proportionally better than how it started | ||
- Make sure that you have an **imperfect solution** | ||
|
||
### STAR Model | ||
|
||
- Describe a **situation** | ||
- Explain the **task** that you had to complete | ||
- Describe the **actions** you took | ||
- Show the **results** op your efforts | ||
|
||
### Most Frequent Questions | ||
|
||
- Challenging project/task | ||
- Improvements in your team | ||
- Successful projects | ||
- Handling feedbacks | ||
- 3 strengths and weaknesses |
Oops, something went wrong.