DEV Community: Emma(minjoo)

Testing interview

Emma(minjoo) — Sat, 23 Aug 2025 21:47:05 +0000

The following content is taken from Cracking the Coding Interview.

Testing problems usually fall under one of four categories

Test a real world object(like a pen)
Test a piece of software
write test code for a function
troubleshoot an existing issue

Remember that all four types require you to not make an assumption that the input or the user will play nice. Expect abuse and plan for it

1. Testing a Real World Object

example Question : How would you test a paperclip?

step1. Who will use it? And Why?
The answer could be "by teacher, to hold papers together", or it could be "by artists, to bend into the shape of animal". The answer to this question will shape how you handle the remaining questions.

step2. What are the use cases?
It will be useful for you to make a list of the use cases. In this case, the use case might be simple fastening paper together in a non-damaging(to the paper) way.

step3. What are the bounds of use?
The bounds of use might mean holding up to thirty sheets of paper in a single usage without permanent damage(e.g, banding), and thirty to fifty sheets with minimal permanent bending. The bounds also extend to environmental factors as well

step4. What are the stress/failure conditions?
No product is fail-proof, so analyzing failure conditions needs to be part of your testing. A good discussion to have with your interviewer is about when it's acceptable(or even necessary) for the product to fail, and what failure should mean.

step5. How would you perform the testing?
For example, if you need to make sure a chair can withstand normal usage for five years, you probably can't actually place it in a home and wait five years.

2. Testing a piece of Software

it is actually very similar to testing a real world object. The major difference is that software testing generally places a greater emphasis on the details of performing testing.

two core aspect to it

Manual vs Automated testing : In an ideal world, we might love to automate everything, but that's rarely feasible. Some things are simply much better with manual testing because some features are too qualitative for a computer to effectively examine. Additionally, whereas a computer can generally recognize only issues that it's been told to look for, human observation may reveal new issues that haven't been specifically examined. Both humans and computers form an essential part of the testing process.
Black Box vs White Box Testing : This distinction refers to the degree of access we have into the software. In black box testing, we're just given the software as-is and need to test it. With white box testing, we have additional programmatic access to test individual functions. We can also automate some black box testing, although it's certainly much harder.

step1. Are we doing Black Box Testing or White Box Testing?
Though this question can often be delayed to a later step, I like to get it out of the way early on. Check with your interviewer as to whether you're doing black box testing or white box testing- or both.

step2. Who will use it? And why?
Software typically has one or more target users, and the features are designed with this in mind.

step3. What are the use cases?
In the software blocking scenario, the use cases of the parents include installing the software, updating controls, removing controls and of course their own personal internet usage. For the children, the use cases including accessing legal content as well as "illegal" content.

step4. What are the bounds of use?
Now that we have the vague use cases defined, we need to figure out what exactly this means. What does it mean for a website to be blocked? Should just the "illegal" page be blocked, or the entire website?

step5. What are the stress conditions / failure conditions?
When the software fails - which it inevitable will - what should the failure look like? Clearly, the software failure shouldn't crash the computer. Instead, it's likely that the software should just permit a blocked site, or ban an allowable site.

step6. What are the test cases? How would you perform the testing?
Here is where the distinctions between manual and automated testing and between black box and white box testing, really come into play.
Step 3 and 4 should have roughly defined the use cases. In step 6, we further define them and discuss how to perform the testing.

3. Testing a Function

In many ways, testing a function is the easiest type of testing. Suppose you were asked to write code to test 'sort(int[] array)' which sorts an array of integers. You might proceed as follows.
step1. Define the test cases

The normal case: Does it generate the correct output for typical input? Remember to think about potential issues here.
The extremes: What happens when you pass in an empty Array? Or a very small(one element) array? What if you pass in a very large one?
Nulls and "illegal" input: It is worthwhile to think about how the code should behave when given illegal input.
Strange input : A fourth kind of input sometimes comes up: strange input. What happens when you pass in an already sorted array? Or an array that's sorted in reverse order? Generating these tests does require knowledge of the function you are writing. If you are unclear as to the constraints, you will need to ask your interviewer about this first.

step2. Define the expected result
Often, the expected result is obvious: the right output. However, in some cases, you might want to validate additional aspects. For instance, if the sort method returns a new sorted copy of the array, you should probably validate that the original array has not been touched.

step3 Write test code
Once you have the test cases and results defined, writing the code to implement the test cases should be fairly straightforward.

4. Troubleshooting Questions

A final type of question is explaining how you would debug or troubleshoot an existing issue. many candidates balk at a question like this, giving unrealistic answers like "reinstall the software". You can approach these questions in a structured manner, like anything else. Reinstalling the browser might solve this user's problem, but it wouldn't help the other users who might be experiencing the same issue. your goal is to understand what's really happening, so that the developers can fix it.

step1. Understand the Scenario
The first thing you should do is ask questions to understand as much about the situation as possible.

step2. Break Down the Problem
Now that you understand the details of the scenario, you want to break down the problem into testable units. A strong tester would iterate through the elements of this scenario to diagnose the problem

step3. Create Specific, Manageable Tests
Each of the above components should have realistic instructions - things that you can ask the user to do, or things that you can do yourself(such as replicating steps on your own machine). In the real world, you will be dealing with customers, and you can't give them instructions that they can't or won't do.

Sorting Algorithms

Emma(minjoo) — Fri, 08 Aug 2025 01:43:51 +0000

Common Sorting Algorithms

Bubble Sort | Runtime : O(n²) average and worst case. Memory : O(1). In a bubble sort, we start at the beginning of the array and swap the first two elements if the first is greater than the second. Then we go to the next pair, and so on, continuously making sweeps of the array until it is sorted. In doing so, the smaller items slowly "bubble" up to the beginning of the list.
Selection Sort | Runtime : O(n²) average and worst case. Memory : O(1). Find the smallest element using a linear scan and move it to the front (swapping it with the front element). Then, find the second smallest and move it, again doing a linear scan. Continue doing this until all the elements are in place.
Merge Sort | Runtime : O(n log(n)) average and worst case. Memory : depends. Merge sort divides the array in half, sorts each of those halves, and then merges them back together. Each of those halves has the same sorting algorithm applied to it. Eventually, you are merging just two simgle-element arrays. It is the "merge" part that does all the heavy lifting. The merge method operates by copying all the elements from the target array segment into a helper array, keeping track of where the start of the left and right halves should be (helperLeft and helperRight). We then iterate through helper, copying the smaller element from each half into the array. At then end, we copy and remaining elements into the target array.
Quick Sort | Runtime : O(n log(n)) average, O(n²) worst case. Memory : O(log(n)) In quick sort, we pick a random element and partition the array, such that all numbers that are less than the partitioning element come before all elements that are greater than it. The partitioning can be performed efficiently through a series of swaps.
Radix Sort | Runtime : O(kn) Radix sort is a sorting algorithm for integers (and some other data types) that takes advantage of the fact that integers have a finite number of bits. In radix sort, we iterate through each digit of the number, grouping numbers by each digit. For example, if we have an array of integers, we might first sort by the first digit, so that the 0s are grouped together. Then, we sort each of these groupings by the next gdigit. We repeat this process sorting by each subsequent digit, until finally the whole array is sorted. Unlike comparison sorting algorithms, which cannot perform better than O(n log(n)) in the average case, radix sort has a runtime of O(kn), where n is the number of elements and k is the number of passes of the sorting algorithm.

Class, Object, Instance

Emma(minjoo) — Fri, 01 Aug 2025 18:01:35 +0000

Class

A blueprint or template for creating objects
A collection of related variables and methods

Object

An entity to be implemented in the software
An instance created exactly as defined by the class
It is also called an instance of a class.
The term "object" has a broader meaning that represents all instances.
From an OOP perspective, it is called an "object" when declared with a class type.

Instance

A concrete entity implemented in the software world based on a blueprint.
In other words, when an object is materialized in software, it is called an "instance."
The materialized instance is allocated in memory.

Feature

An instance can be considered a subset of an object.
From an OOP perspective, when an object is allocated in memory and actually used, it is called an instance.
The term is used when focusing on the relationship between an abstract concept (or specification) and a concrete object.

Data structure - Graph

Emma(minjoo) — Sat, 31 May 2025 20:57:57 +0000

Graphs

A tree is actually a type of graph, but not all graphs are trees. Simply put, a tree is a connected graphs without cycles.

A graph is simply a collection of nodes with edges between (some of) them

graphs can be either directed (like the following graph) or undirected. While directed edges are like a one-way street, undirected edges are like a two-way street.
The graph might consist of multiple isolated subgraphs. If there is a path between every pair of vertices, it is called a "connected graph"
the graph can also have cycles. An "acyclic graph" is one without cycles

Adjacency List

This is the most common way to represent a graph. Every vertes(or node) stores a list of adjacent vertices. In an undirected graph, an edge like(a,b) would be stored twice : once in a's adjacent vertices and once in b's adjacent vertices.

In order to implement of simple graph, the graph class is used because, unlike in a tree, you can't necessarily reach all the nodes from a single node. You don't necessarily need any additional classes to represent a graph. An array(or a hash table) of lists(arrays, arraylists, linked lists, etc.) can store the adjacency list. But it isn't quite as clean. We tend to use node classes unless there's a compelling reason not to.

Adjacency matrices

An adjacency matrix is an NxN boolean matrix (where N is the number of nodes), where a true value at matrix[i][j] indecates an edge from node i to node j( you can also use an integer matrix with 0s and 1s.)

In an undirected graph, an adjacency matrix will be symmetric. In a directed graph, it will not(necessarily)be.

Data Structure - Tree

Emma(minjoo) — Sat, 31 May 2025 19:28:55 +0000

Tree

A tree is a data structure composed of nodes.

Each tree has a root node -> Actually a root node isn't necessary in graph theory, but it's usually how we use trees in programming.
Root node has zero or more child nodes. Each child node has zero or more child nodes, and so on
The tree cannot contain cytcles. The nodes may or may not be in a particular order, they could ahve any data type as values, and they may or may not have links back to their parent nodes.

Binary Tree vs. Binary search Tree

A binary search tree is a binary tree in which every node fits a specific ordering property ->All left descendents <= n < all right descendents. This must be true for each node n
The definition of a binary search tree can vary slightly with respect to equality. Under some definitions, the tree cannot have duplicate values. In others, the duplicate values will be on the right or can be on either side. All are valid definitions.

Balanced vs. Unbalanced

a "balanced" tree really means something more like "not terribly imbalanced".

Complete Binary Trees
A complete binary tree is a binary tree in which every level of the tree is fully filled, except for perhaps the last level(leaf node). To the extent that the last level is filled it is filled left to right

Full binary Trees

A full binary tree is a binary tree in which every node has either zero or two children. That is, no nodes have only one child.

Perfect Binary Trees

A perfect binary tree is one that is both full and complete. All leaf nodes will be at the same level, and this level has the maximum number of nodes -> it is rare in real life, as a perfect tree must have exactly 2ᵏ-1 nodes(k is the number of levels)

Binary Tree Traversal

In-Order Traversal this means to "visit"(often, print) the left branch, then the current node, and finally, the right branch. When performed on a binary search tree, it visits the nodes in ascending order
Pre-Order Traversal this visits the current node before its childnodes. In a pre-order traversal, the root is always the first node visited.
Post-Order traversal Post-Order traversal visits the current node after its child nodes. The root is always the last node visited.

Binary Heaps

there are min-heaps and max-heaps. Max-heaps are essentially equivalent, but the elements are in descending order rather than ascending order.

A min-heap is a complete binary tree(that is, totally filled other than the rightmost elements on the last level) where each node is smaller than its children. Therefore the foot is the minimum element in the tree.

two key oerations on a min-heap -> insert and extract_min

insert when we insert into a min-heap, we always start by inserting the element at the bottom. We insert at the rightmost spot so as to maintain the complete tree property. Then we "fix" the tree by swapping the new element with its parent, until we find an appropriate spot for the element. We essentially bubble up the minimum element. This takes O(log n) time, where n is the number of nodes in the heap.
Extract Minimum Element First we remove the minimum element and swap it with the last element in the heap(the last element -> the bottommost, rightmost element). -> (Remove the root (minimum element), and move the last element to the root position.) Then we bubble down this element, swapping it with one of its children until the min-heap property is restored. Do we swap it with the left child or the right child -> that depends on their values. There's no inhent ordering between the left and right element, but you'll need to take the smaller one in order to maintain the min-heap ordering. This algorithm will also take O(log n) time.

Tries (Prefix Trees)

A tries is a variant of an n-ary tree in which characters are stored at each node. Each path down the tree may represent a word. The *nodes(sometimes called "null nodes") are often used to indicate complete words. -> For example, the fact that there is a *node under MANY indicates that MANY is a complete word. The existence of the MA path indicates there are words that start with MA. The actual implementation of these * nodes might be a special type of child(such as a Terminating TrieNode, which inherits from TrieNode).
Very commonly, a trie is used to store the entire (English) language for quick prefix lookups. While a hash table can quickly look up whether a string is a valid word, it cannot tell us if a string is a prefix of any valid words. A trie can do this very quickly

Literal

Emma(minjoo) — Sat, 19 Apr 2025 20:46:28 +0000

During class of Python, I heard about Dictionaries Literals. I wonder why it's called literals.

Q. What is a Literal

literal is a value you write directly in your code. It is not a variable or a name => it's the actual data.(you can think of it as the raw data -> number, text, etc.)

What is different from a Constant?

a constant is a named variable whose value doesn't change
final int MY_NUMBER = 42; -> like this(in here, the final keyword means constant), but 42 is literal.

Why It's called a literal, not a value.

A literal is the value as it appears literally in your code.

int x = 10;

10 is a literal because you typed it directly into the code.
it's called a literal because it's the literal representation of a value.

But, value has a broader Concept. The word value means the result of anything -> it could be

a literal
a variable
a result of a function call
a complex expression eg. int x = a+b => Here, the value of x is not a literal -> it's calculated(computed). So we don't call it a "literal", even though it has a value.

My frist step

Emma(minjoo) — Sat, 19 Apr 2025 20:31:36 +0000

Taking my first step here.
I’m from Korea, and until now I’ve been using other platforms to write. Just recently found out about dev.to—so yeah, this is all kinda new to me.

From now until the end of September, I’m starting a bit of a personal journey. Gonna dive into Python (starting from the basics), revisit some algorithm stuff, and build out a small project or two. Thought it’d be cool to write things down along the way—stuff I learn, stuff I mess up, random thoughts, all of it.

I’ve worked as a dev in Korea for about two years, but honestly? Still feel like a junior and really I am. There’s a mountain of stuff I don’t know yet. That’s why I wanna be more of a “write-it-down” kind of developer from now on, so I don’t forget things two days later like I usually do 😅

No big goals here, just taking it one step at a time.