You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Mar 1, 2026. It is now read-only.
This repo’s layout isn’t idiomatic to any one language — it’s a mix of Elixir, Go, Python, and TypeScript.
5
6
7
+
Spot something I could improve? Open an issue and point it out — that would be swell.
6
8
7
-
This repo’s layout isn’t idiomatic to any one language — Python was my strongest when I started, and it probably shows. I’m aiming to make that less obvious as I go through the challenges that by the end.
9
+
## 🙋 Why?
8
10
9
-
Spot something I could improve? A pull request would be lovely.
11
+
The HackerRank 90-day course was designed as a three-month prep for recruitment pipelines. Whilst I started out with that intention, I’m not using it for that purpose anymore (_at least not directly_). I’m using it to apply my Python and Elixir knowledge to scaffold my development in Go and TypeScript.
10
12
13
+
What I’m noticing, though, is that it’s also improving my authoring skills more broadly.
11
14
12
-
## 🙋 Why?
15
+
I started in January. At first, I just wanted to get through it in Python — a collection of scripts to store solutions. Then I added per-file unit testing. Then I started doing the challenges in different languages, and it evolved from there. Now it’s basically a code dojo for me, where I’m free to pick a task and write it up in a bunch of languages.
13
16
14
-
The 90 days worth of interview preparation on hackerrank. Public so that others may witness the learning and re-awakening of well rested neural pathways and the creation of new ones.
17
+
I’ll be very pleased if I complete these challenges by the end of 2025 in four languages: Python, Elixir, Go, and TypeScript. The aim is to get a nice 25% language distribution across the repository and to demonstrate competence in basic project layout, standard libraries, testing methodologies, and — most importantly — low-complexity solutions.
15
18
16
-
I'll working through the challenges in Python and then I'll be starting from scratch in Go, Elixir and TypeScript. Maybe even rust. I didn't start out with this aim, but that's how I ended up. By the start of week five of doing them in Python I decided to use the challenges as a means of supporting my learning in other languages.
19
+
For example, many challenges can be solved easily with an `O(n^2)` approach, but HackerRank will timeout when you submit inefficient code. That’s a great forcing function — you’re not allowed to be lazy.
17
20
18
-
I don't think these challenges will make me a better programmer in themselves, but the act doing each one, in multiple languages probably will.
21
+
## 🧱 Structure
19
22
23
+
The project is structured by **weeks**, not by language. That is: none of the projects follow idiomatic layouts for their respective languages.
20
24
21
-
## 🧱 Structure
25
+
Each week has a folder named `w1`, `w2`, etc. Inside each is a `tc` (_test cases_) folder, which contains test files in a very specific format. For example, here’s the test case data for a made-up challenge where you’re given two integers and must sum them. Arguments are separated from expected output by two blank lines:
22
26
23
-
As I go back through the each week, there will be a directory called testcases and in each will be a textfile containing the documented `stdin` and the expected output. Hackerrank isn't consistent between returning values and printing them out, so my code here will always default to returning values as it makes testing much less finicky.
27
+
```plaintext
28
+
1 2
24
29
25
-
Until I'm back to week five the structure will be over the place, but once I've been through each week in Go it'll get cleaner.
30
+
3
31
+
```
26
32
27
-
The format for the test cases is stdin inputs seperated by newlines and then the expected output seperated by two newlines.
33
+
This format ensures each challenge across all languages consumes the same input/output.
28
34
29
35
## 📅 Three Months?
30
36
31
-
Unlikley I will get through these in six months let alone three, so I'm not binding myself to any timeframe. Learning takes time and one of the things I am focused on right now is taking my programming up a level that I always aspired to when I saw it in others - to be language agnostic.
37
+
This course was meant to be three months long, but I’m not treating it that way. Technically, you’re supposed to use HackerRank’s interface to author your code — but that’s a horrific experience.
32
38
33
-
I'm not the best programmer on Earth, but I think I have the potential to be a pretty good one.
39
+
If I finish all the challenges in four languages by the end of 2025, I’ll be very pleased.
34
40
35
-
## Idiomaticity 😱
41
+
## 😱 Idiomaticity
36
42
37
43
(_I made that word up_)
38
44
39
-
This repository is a mixture of a number of languages and I've prioritised coexistance of languages at the expense of any one languages typical project layout. For example the Elixir stuff isn't in a typical mix project. It was more important to the intention of what I'm doing here to have the languages side by side, so you can see similarities and differences.
45
+
This repository is a mix of several languages, and I’ve prioritized their coexistence over idiomatic project layout. For example, the Elixir code isn’t structured like a proper Mix project — same with TypeScript, Python, and Go.
46
+
47
+
The point is to compare approaches side by side, not to build polished, standalone apps.
40
48
41
-
Obviously, I keep whatever idoimatic language specific skills I possess in my approach to writing the code.
49
+
That said, I still try to write idiomatic code within each language’s norms.
42
50
43
51
## 🤖 LLM usage
44
52
45
-
None of the code in this repository has solutions written by AI. You'll just have to take my word for that. In some solutions I used AI to reason about things and to discuss approaches, but all of the code is mine.
53
+
### Code
46
54
47
-
My approach to using LLM's and AI is to treat them like a teaching assistant who knows a lot but isn't always right. They're a great tool for learning and helping you understand a thing, but they are not (_in my humble opinion_) suitable for production output in most contexts.
55
+
None of the challenge solutions are directly written by AI. I do use LLMs while coding — they’re great scaffolds for learning.
48
56
49
-
Also, this is about learning and using LLM's for solutions doesn't help me - at all. It only pushes the barrier to learning further away from me.
57
+
### Documentation & Comments
50
58
59
+
Most comments were written by me and then passed through an LLM to make them more succinct. I tend to be overly wordy — LLMs are great at "neutral speak".
51
60
52
-
## Quality & Assurance
61
+
62
+
## ✅ Test & Quality
53
63
54
64
### Elixir
55
65
56
66
There are two quality checks ran on the challenges - tests and static analysis.
57
67
58
-
Tests are handled with ExUnit and are ran as follows:
68
+
Tests are handled with ExUnit:
59
69
60
70
```bash
61
71
mix test w*
62
72
```
63
73
64
-
Static analysis is done with dialyzer and is ran as follows:
0 commit comments