# Revisiting Data Structures

Since I had alittle bit of time, I've started to revisit my understanding of data structures after a conversation with a friend of mine over lunch 2 weeks ago. Also it seemed to me that since my next semesters module is Data Structures and Algorithm, it would be a good challenge to re-learn everything I know and to see what I missed out.

### What is a Data Structure?

This is a question that I always ask myself. Originally, I thought of it simply as something that can store values/elements in a list. From a software engineer POV, data structure or the basis of any data structure consists of...

- A variable assigned.
- An Array of values

However, the definition of a Data Structure to be more precise is:

- A collection of elements each of which is either a data type or another data structure.
- A set of associations or relationships involving the collection of elements.

Data Structures can be Linear in structure like Stacks, Queues. Or Hierarchical like a Tree or your Organisational Structure. It can also be a Graph, something which you commonly see the MRT Map, a visual representation of your Computer Networks. It could also be a Set, unique and atomic like a group of people.

We can all imagine that a data structure is in fact just blocks of bytes stored in a row diagonally or horizontally in memory. So i'm not entirely wrong, yet not entirely right either.

### What is an Algorithm then?

So an Algorithm is, what we software engineers are hired for. We write code based on the given business logic, and algorithms is something like a mathematics equations. Where we write statements in the given programming language so that it asserts the output. And for every algorithm, there is a question about its efficiency which we know it as the Big O Notation which helps us to define the time / space complexity of any given statement.

We have the holy grail of O(1) referred to as `constant time`

, O(n) referred to as `linear time`

and then we have quadratic time O(n^2), cubic time O(n^3) and lastly logarithmic time O(log n). I wouldn't elaborate how you count and determine the given Big O as I presume this is easily understood.

### The Struggles of Software engineer

To be honest, I always have problems with coding tests be it live or via a platform. For many if you want to test how well a SWE can code, it should not be via any algorithm question. Of course not testing for any coding ability would also make it hard to determine the ability of the person. So its a dilemma that I have yet to convince myself on the necessity of having coding tests.

I'm FOR coding tests, but not super hard ones as it serves no meaning. I would dare say that 90% of the time, I have never ever implemented complex data structures in the codebase. So why do smaller companies still benchmark potential hires with coding tests. I would say that the bare minimum for any SWE would be to understand or be able to code a Stack or Queue out.