"He spent too long attempting to solve the first problem that we barely had any time to do any coding. Though he had strong comms, and was very pragmatic. Sadly this isn't enough for me to pass him." — company name withheld

INTRO

This article is a reflection on the sort of front-end and algorithmic challenges I've encountered in my interviews so far at big and aspiring to-be big, technology companies, which have included Amazon, Google, JPMorgan, and Shopify.

It's not the first time I've interviewed at these companies, but it was the first time I completed interview rounds with them.

This reflection aims to decide where to channel my hugely limited resource, my time, to improve my likelihood of success at further interviews. Specifically, to help inform what challenges I choose to curate for my #30DaysOfReactComponents and #130DaysOfDSA challenges.

So if you're curious to know what sort of questions I've been asked, how I've approached interviewing, and my opinion on the various interview processes and how to prepare, read on.

"Unfortunately following some consideration, the team are not looking to take your application forward due to a lack of sufficient demonstration of the technical depth required." — company name withheld

HUNTING FOR INTERVIEWS

MARKET ANALYSIS

The tech market is really hot right now (first quarter of 2022) and big tech companies are hiring like crazy, with recruiters seemingly on overdrive.

Therefore the real problem from the get-go was not whether I would get interviews, but, how not to take on too many interviews concurrently that I got burned out without time to do anything else, such as grow myself, and grow my consultancy.

Tip💡: When looking for roles on Linkedin, set your location to the job market you're interested in.

Tip💡: If you're looking for remote US roles, you typically need an incorporated company so set this up ahead of time.

CV DESIGN

With my market analysis in mind, I created a very narrow and specific one-page CV targeting front-end react roles and decided to send out applications in batches of 20 - 30.

I had two companies in mind when creating my CV — Google and Shopify. And accepted that given I was just starting, I would fail most of my interviews, but the important thing would be to learn from them towards my Google and Shopify interviews.

APPLICATION POLICY DESIGN

I created a personal policy: "NO MORE NO-NAME STARTUPS," which my accountability group (bless them) kicked against strongly. They advised instead to get something, anything, asap! (In retrospect, they were right).

But I created this policy because I felt I'd seen enough of how startups work at the early stages and wanted to see more of how startups are run when they've made a name for themselves and their products are widely adopted. I also thought that landing a big tech role would offer better job security (laughs in 2022 4th quarter and ongoing 2023 big tech layoffs) against a repeat of the sort of layoff I'd just experienced.

Of course, this "NO MORE NO-NAME STARTUPS" policy expired as my savings runway started to expire, but before then I wanted to push myself to get what I wanted, and very importantly, to avoid like covid any startups that weren't solving challenging problems because stagnation was still very high up there at my greatest career fears list. So much so that two years before this layoff, I had already resigned from my first software engineering role out of university with nothing lined up to prevent stagnation.

APPLICATIONS

Following the previous steps, I sent out my first batch of applications towards the end of January. I also reached out to my best friends, mentors, and the most helpful people in my network letting them know I'm on the market and asking for their help.

Currently, those efforts have worked well enough in terms of converting to the interviewing stage that I only needed two to three major application cycles.

Tip 💡 : Reach out to people. Remember, people are kind and truly helpful if you let them know how to help, especially if there's something in it for them, even if it's as ephemeral as feeling nice about themselves.

Tip💡 : Linkedin is my preferred platform for finding recent job openings and reaching out to recruiters. If you keep your Linkedin active with content, recruiters reach out in a volume proportional to the "relevant" content you put out. This is how I believe I got my Google opportunity, by being active on LinkedIn, and a Google recruiter reaching out. Other than that maybe someone put in a word.

Tip💡: Circular is also proving to be a source of high-quality leads compared to the noise of LinkedIn.

Tip💡: When you make an application to a company, find the company on LinkedIn, look for employers of the company and filter for recruiters. Network with the recruiters to let them know you just made an application. This helped me get my Shopify application past the gatekeeping software.

Tip💡: For targeting small startups, find tech communities on Discord and Slack and view the free job boards they have there. Small startups typically don't pay for agency help and fancy job boards unless they're struggling to fill important roles, so you won't find their openings on places like LinkedIn or Circular during the early stages of them just starting to look for a person to fill the role.

TRACKING INTERVIEWS

I kept track of my applications using this google sheet so that I could learn what to do more of and what wasn't working.

This is super important because as you can see with NordCloud, the last note says to reach out in the summer when the company can sponsor skilled worker visas. These are the sort of opportunities which get missing in the heat of the moment if you don't keep track.

Tip💡: Be DESPERATE for feedback. Well, in job hunting NEVER be or appear desperate, but you get what I mean, take feedback seriously so you can fine-tune your process.

MARKET FEEDBACK

The CV I used has had a reasonably high conversion rate into interviews of about 4% - 7%. Most of that has come from mid-level roles which as a subset probably have had about a 20% conversion rate, while the conversion rate for senior-level roles is near 0%.

This market feedback has reinforced my prior learning — that a majority of tech recruiters for FAANG-type companies will only consider moving my application forward for a senior role if I had already accumulated about 8 years in total or 4 more years of the same quality of my current technical experience.

This gatekeeping seems to be even more stringent for glitzy startups like Webflow, Monzo and Stripe when compared to big corporations. Rejections are swift at these startups, and I think this has to do with their senior talent-to-product ratio likely being lower than at big corporations. I don't think they can afford to bring on talent who do not have strong and correct opinions, along with the skills, to take their products to the next level. Doing so would jeopardize the value per time per product they get from their existing pool of senior talent if the incoming talent pool presents too much of a mentorship sinkhole.

Finally, unlike big corps and glitzy startups, recruiters for much smaller less glitzy startups seemed to want to push me in some shape or form for senior roles at the startups they were recruiting for, to which the team members, after having had a look at my CV would say, no, they want someone more senior with more experience.

I think this has to do with the reality that recruiters for much smaller startups are not in-house, and are more motivated by commissions than by getting good fits. I quickly learned not to waste too much of my time with such recruiters when I could see that the opportunities they were pushing me for were not a match. E.g why would you push a front-end focused engineer for a DevOps role?

"The team thought you demonstrated strong leadership principles but wanted to see more technical complexity" — company name withheld

WHAT INTERVIEWS HAVE LOOKED LIKE

Interview types I've experienced fell into one of these categories:

• Leadership principles a.k.a behavioural interviews

• Data structures and algorithms

• React components

• Systems design

LEADERSHIP PRINCIPLES A.K.A BEHAVIOURAL INTERVIEWS

These have taken various forms. From a CTO having a casual one-hour chat with me, to the more standard 10 - 30 min formal tell me about yourself screening interviews at JP Morgan, Toptal and Google. All the way to Amazon's drawn-out repeated leadership principles interviews.

They typically follow the form:

• Tell me about a complicated problem you solved

• Tell me about a time when you delivered beyond expectations

• Tell me about a time when you had to act quickly with limited information

• Walk me through your CV

Whatever the form, I've prepared for these by reflecting on my varied experience and penning down over 15 examples of instances where I've demonstrated strong technically relevant leadership.

And during the interviews, I've always tried to check that the interviewer follows along with me and that I'm providing the information they're looking for by explicitly asking them at regular intervals, questions such as:

• Did that answer your questions

• Do you want me to go more in-depth in any particular area

Also, resources I've loved for these are:

• link to amazon mock interviews (will update to include later)

• link to video about don't get down levelled (will update to include later)

Tip💡: Use interview prep sites like pramp.com and interviewing.io to get used to speaking with people in an interview format

Super Tip 💡: Practice with a friend in person.

DATA STRUCTURES AND ALGORITHMS

All interviews involved some DSA problems. 4/6 companies surfaced graph problems that require proficiency with these algorithms specifically:

• UnionFind (1 question)

• BFS

• DFS (3 questions)

• Dijkstra's Shortest Path (2 questions)

Other than these:

• Arrays (2 questions - 1 sort, 1 flat list, 1 merge (sum time series))

And finally

• One linear programming problem (Microsoft).

Javascript

• check javascript types

React components

• flexbox - centring problems

• hooks - the optimal way to implement hooks

• promises - implement delays

• event listeners - hook into scroll event

Feedback

• for arrays and lists, go through merging strategies

• for react, read documentation line by line and understand the whys of everything

• replicate a challenging project and try to understand why

Backend

• Database indexing

For the uninitiated, the popular opinion around using DSAs to screen for coding ability is that it's unnecessary. But while there are cases when it is unnecessary, e.g small startups really struggling to find talent, I think it's an invaluable screening phase for big corporations struggling to screen hundreds of applicants per role, or startups actually solving extremely difficult problems who need people that are meticulous about their software engineering craft.

In my opinion, just like the GRE, proficiency in DSAs measures more than just coding ability, it gives strong indicators of motivation, discipline and intelligence (specifically the intelligence needed to acquire complex knowledge), all of which a candidate who is successful at breezing through the DSA screening phase would need in abundant quantities.

Unfortunately I don't (yet) have a winning formula for acing DSA interviews, but a great motivating resource I reference for guidance is Ayomide's reflection on getting into Google

particularly these sub-sections under preparing for interviews the right way:

• Fundamentals

• Resilient, Spaced Practice

Ayo's points, specifically about spaced practice, also called spaced repetition, reminded me of how I learned my first 500+ characters in Mandarin and convinced me that far more important than my solid understanding of these structures, is my ability to recall them and recall the common algorithms in which they're used quickly and fluidly.

"As you can see Dozie, we're not going to be able to progress further as you didn't finish this problem within the 15-minute timeframe" — name withheld

LIES FROM THE PITS OF HELL

I've learned that no matter how much they believe otherwise, big tech hiring will always prefer a candidate whose thinking process is thorough AND who manages to solve the problems given CORRECTLY within the given time limit, so far they do not have bad qualities to disrecommend them. So please do not believe anyone and fall into a false sense of security when they tell you "we simply want to see how you think."

Luck comes into play when not many people solve correctly, and a candidate is one of the few with a thorough thinking process, plus other qualities to recommend them. Even then, I believe the process will favour the candidates who solved most correctly, or most tenaciously, within the shortest timeframe.

Anyway, if back flipping were coding, here's what it feels like interviewers have been looking for while interviewing at big corps:

"Ghosted on me without feedback for a month+ and got back with an email saying try again" - Google

Tip💡: Never take it personally. It really is just a market where you're trading skills for money. The trick is to identify what skills to learn and how to demonstrate them sufficiently to get a deal.

CONCLUSION

Keep applying, keep developing your skills and keep learning what to do better.

My break came when I sunset my "no more no-name startups" policy and moved my focus to target small startups. I got an offer about 3 weeks after this switch. And I couldn't help but think, imagine how at peace I and my bank account would have been if I'd made this switch much earlier, well before spending 6 months applying at big tech companies.

The honest answer... if I didn't make that initial attempt at getting the roles I ideally want, I don't think I would have the motivation I currently have now to go at it again or as good an understanding as I have now of the areas I need to improve at.

I also wouldn't have had the time to explore and conclude that I wouldn't find Webflow consulting motivating or rewarding. Regarding this, I learned through technical writing that I don't enjoy nonscalable craftwork as a career. By this, I mean producing unique pieces of items that can only be sold once - case in point, technical articles, which is also what I would be doing if I were creating Webflow sites for clients. I realised it would be a huge waste of my time when, instead, I could build products that scale easily with only further marginal input from me using my software engineering skills. And yeah, I just don't enjoy the idea of non-incremental work. My brain just switches off, so one Webflow site today, another tomorrow, another the next day... I realised I would be bored and frustrated out of my effing mind by the lack of linear progression in complexity.

Still... it's always nice to not be too long out of a job, so while these were valuable insights, I don't advise my future self to take a long-winded route in bouncing back from a layoff.

It's a tool for building UI components that promises developers the ability to develop components independently of one another and without the need to have mock data in a database.

_{Image showing the different states of an airbnb calendar component in StoryBook ^[1]}

In practice this means no need to spin up a local development environment, nor jump through hoops such as log in, select an option, click that button, just to see the real version of a component and all the states it can have.

Storybook accomplishes this using stories and story args, where a story is, well, a story of all the rendered states a component can have. While args are how we pass data to a component in a story without the need for a database or jumping through hoops

Furthermore, Storybook works with the major frontend libraries like React, and Vue, as well as frameworks like Angular.

Why read this

As a developer I've experienced the pain of having to work with React components which should have separate concerns getting so entangled together they become impossible to make changes to without breaking one another. As well as very hard to compose using one without needing the other. So when I first heard of Storybook I immediately wanted to check it out!

However, I never got around to setting it up for use in a project because the getting started curve always seemed a bit too much for my time constraints.

Now, I've finally decided to check it out by following it's documentation and tutorials, and to share the opinion I form on its usefulness for other developers who've still not had time to check it out themselves.

The Getting Started Curve

Getting started took about as long as I always thought it would... about 30 - 40 minutes.

Installation

The actual installation, which is really only designed to work within an existing project, takes maybe 5 - 10 minutes, and the rest of the getting started time is spent absorbing the concepts and design principles behind Storybook.

Design Principles Behind StoryBook

Storybook's core principle is component driven design, and I encourage anyone who's unfamiliar with this principle to have a look at the resource^[4] they provide for it.

Component driven design is not a new concept in software engineering nor front-end development, and it certainly wasn't invented in 2017 ^[2].

HTML itself for instance is basically a bunch of components which get composed to form larger components. While React's core principle of composition rests on component driven development ^[3].

Yet, there is value in checking out the resource they provide to see how the concept of component driven development is made explicit. Discouraging the idea of looking at the building blocks of websites as pages, and instead making it clear that front-end building blocks are much smaller.

It should leave you encouraged as a developer to ask [of components] is this the smallest building block to this new component I want to create.

As well as informed of the existence of the Component Story Format, which is the recommended way to write the stories used in Storybook

Is Storybook Useful

I think it depends on what you or your organisation needs. On whether the relevant project

• requires building its own component library,
• converting a custom design system to a component library,
• using an existing open source component library,
• possibly requires building on top of pre-existing components,
• or definitely does not require building any new components.

Having time bound myself to go through just the introductory section of the StoryBook documentation and spin up a simple component, it's unrealistic to say I've formed a correct opinion on StoryBook's usefulness,

however, here is my opinion, formed from exploring the showcase projects on StoryBook, and going through accounts from people who've used it.

StoryBook is probably not useful for the vast majority of front-end developers who rely on pre-existing component libraries with little to no new complex component development being done.

The showcase projects I saw using StoryBook had used it to effectively document what seemed like their entire component libraries. Audi, Capgemini, Codecademy, and Shopify. These companies created a space for front-end developers using their component libraries to see what components are available and how they should look in all their relevant states.

So unless you're building your own component library and want a way to do something similar, or you've already built your first 1 - 3 new components which you want to document and ensure have clear separation of concerns, and think you'll still need to build more, you probably don't need StoryBook.

However, it's definitely a tool I'll see myself including in my project if there's ever uncertainty about whether or not I'll be needing to build new components, just so that it's set up and ready to go as a replacement for the all too common components folder.

Conclusion

Use StoryBook if your project:

• requires building its own component library,
• converting a custom design system to a component library,
• or possibly building on top of pre-existing components from open source component libraries.

Don't bother if your project:

• will limit itself entirely to an existing component library.

All that said, happy coding 🥳

Attribution

Cover image from uxpin

If a sequence X has m symbols then the number of possible subsequences of X is 2^m — CLRS, Introduction to Algorithms

Intro

In this article I'll be showing how to count using any ordered sequence of symbols, which I'll claim is useful when generating all subsequences of that ordered sequence.

This may seem obtuse, not useful, and as though it would never come up in a real world setting, so to motivate this subject I'll simply note that a real world use case is in generating subsequences of DNA sequences,

which is a specific instance of generating subsequences of strings or more broadly, sets of values, which is something software engineers can find themselves needing to do often.

Why read this

During my morning reading of Introduction to Algorithm, I came across the quoted claim from earlier,

If a sequence X has m symbols then the number of possible subsequences of X is 2^m — CLRS, Introduction to Algorithms

but it didn't seem intuitive to me and I felt a more intuitive value for the total number of X's ordered subsequences would be m! (m factorial) .

If like me you look at 2^m but don't think it's an intuitive value for the total number of ordered subsequences of X, then you may like this article.

Why 2^m and not m!

Simply put, m! would give us the number of times we can rearrange all m symbols in the sequence of X. The very fact that we're rearranging breaks the sequencing of the symbols, and so we can quickly discount this number.

Okay, but why not m²?

To which I would say fair point, because, given a sequence X, and two empty boxes A and B, each having m slots, we can generate two ordered subsequences by repeatedly picking a symbol from X, and placing in either box A or box B while preserving symbol order.

From which it's easy to think that box A and B can each take on m possible values, and given that there are just two boxes, the total possible values these can represent is m².

And easier still to mistakenly extrapolate that value m² to be the total number of subsequences of X.

Unfortunately, it's wrong to say that A and B can each take on m possible values. I think it's more correct to say they can each take on m combination m/2 values, which resolves to some factorial.

Which using Wolfram Alpha, we can see grows really quickly to become much larger than m for sequence lengths as small as 15.

So we can conclude that it's also wrong to think that m² gives us the number of ways in which we can form two sub sequences out of X.

So why 2^m

Let's focus on what 2^m means in terms of counting.

It means we have m possible values and each can take on only 2 states.

In other words, it means if we had a binary number sequence like 1 1 (read as 1, 1, not 11), then 2^m, which in this case equals 2² = 4, represents the total number of subsequences we can derive from the sequence " 1 , 1 ".

Which are

0: " , " otherwise represented in binary " 0 , 0 "

1: " , 1 " otherwise represented in binary as " 0 , 1"

2: " 1 , " otherwise represented in binary as " 1 , 0 "

3: " 1 , 1 "otherwise represented in binary as " 1 , 1 "

Okay, how does that help us?

We'll use that to help us count in binary using any ordered sequence of symbols by following these three steps:

1. Take a sequence of ordered symbols
2. Represent all possible states for each symbol
3. Count!

1 - Take a sequence of ordered symbols

Given the sequence is ordered, we can easily replace the binary symbols with any symbols of our choice. So let's take a simple sequence " D , K "

And note that when generating a subsequence, each symbol in the original sequence can take on only one of two possible values. The symbol value itself, or no value at all.

Side note: with quantum computing, the number of possible states each symbol can take on expands to three, but thank goodness we don't have to worry about writing quantum programs just yet.

2 - Represent all possible states for each symbol

Each symbol has two possible states in a subsequence, itself or no value at all. Let's represent them for " D , K " as such:

• D: D or !D
• K: K or !K

This way, for any new symbol N we can simply use !N to represent it's no value state.

3 - Count

Now that we have our representations, let's use them as though counting in binary.

0: " , " otherwise represented as " !D , !K"

1: " , K " otherwise represented as " !D , K"

2: " D , " otherwise represented as " D , !K "

3: " D , K " equally represented as " D , K"

and in this way, when we eventually reach the original sequence, we will have generated every possible subsequence along the way, which for "DK" are

"", "K", "D", and "DK"

Conclusion

Ordered subsequences are really just binary numbers with different symbols, so I hope this has been fun to read, and has shown how given any ordered sequence, when trying to generate all possible ordered subsequences we can simply think of doing this as counting up to a binary number represented by the original symbol sequence 😊

Attributions

• Image gotten from this DNA sequencing article

Try as we might, we won't always know what a type should be at every given point in time. In these situations it's important that we choose a suitable way to represent such a type which is both safe and broad enough. This is where any, unknown and never come in.

Primer

Recall that with Typescript we have these assignability rules for the any type.

1. Any type is assignable to the any type.
2. The any type is assignable to any other type.

Keep these in mind as we move on to talk about any, unknown, and never in terms of assignability rules.

The rules for any

The any type obeys the two rules from our primer, but it's worth noting that the second rule isn't completely true, because the any type is not assignable to a type of never.

The rules for unknown

The unknown type obeys only the first rule:

1. Any type is assignable to the unknown type

but not the second rule, because we can only assign the unknown type to another unknown type or the type any.

The rules for never

The never type obeys only the second rule:

1. The never type is assignable to any other type

but not the first rule, because we can never assign any other type to the type never, not even the type any.

Which to choose

Which type to choose depends on what you're doing.

1. Are you migrating a JavaScript codebase to TypeScript?
2. Are you expecting an unknown type?
3. Are you expecting a function to never run?

1. Are you migrating a JavaScript codebase to TypeScript?

Then keep the any type handy to tell the type checker to ignore some types while you perform your migration -- this seems to be the main reason any was created in the first place^[3].

In essence, use the any type when you are sure you want to ignore type checking on a variable.

Other than this, I personally don't see a strong use case for any in a TypeScript codebase, given how dangerous it can be in allowing errors seep through from one function to another.

2. Are you expecting an unknown type?

In cases where a type is unknown, it's advisable to use the unknown type and avoid the use of any. The main reason for this is because 'any' effectively silences the type checker when used, causing errors such as undefined to sneak in.

Instead, prefer unknown. The beauty of using 'unknown' to represent an unknown type is that when we try to access the properties of an 'unknown' type, the type checker reminds us that we're trying to perform a dangerous operation.

Now, the very fact that we're trying to access a property of an unknown type means we now know something about that previously unknown type. So a warning from TypeScript at that point is a great reminder to update our unknown type with the details we now know about it, before trying to access it.

3. Are you expecting a function to never run?

As for never, it doesn't really help when dealing with migrations or values of unknown types, but it is the perfect type to use when we know a function will never run or never return anything.

This is different from void, in that we can expect a void function to return even after performing operations with no side effects or return values.

However, a never function will never return... it might throw an error, run infinitely, or simply represent code that will never be reached.

Conclusion

1. Are you migrating a JavaScript codebase to TypeScript? Keep any handy.
2. Are you expecting an unknown type? Prefer using the unknown type.
3. Are you expecting a function to never run? Reach for the never type.

Interesting areas of reference

1. What is Type Theory
2. What is a Bottom Type
3. Why does any exist
4. Why never exists

This article assumes you have a basic familiarity with the concept of asymptotic runtimes, typically talked about using big O notation. And it also assumes a familiarity with recursive functions and trees.

Motivation

Recursive functions can be hard to reason through when thinking about their runtime analysis. It's also not always clear how each additional recursive call affects the total runtime of a recursive function.

To help with this, this is a short reference article noting models to use when thinking about recursive functions, building from explanations on the topic in Cracking the Coding Interview.

The models

Picture a tree, sort of like a family tree:

and a list, very much like an array:

A recursive function with only direct recursive calls will create a call stack that looks like one of these two models, which can be studied as data structures in their own right. It will always start with a parent node, and branch out or down into child nodes, and each node will end up doing a fixed amount of work.

To determine the runtime of the recursive function, the basic idea is to:

1. use these models to help determine the number of nodes that will exist in the call stack.
2. determine how much work each node in the tree or list will do.
3. sum up all the work done by every node to give the total work that will be done by the recursive function.

1. Use # of direct recursions to choose model

By the number of direct recursions we mean the number of statements in the function's body where the function calls itself.

A recursive function with two direct recursions creates a tree that resembles a perfect binary tree,

while one with just one direct recursion creates a tree that resembles a list.

We'll call this number, the number of direct recursive calls z. And we can have recursive calls with z > 2 such as:

2. Determine number of nodes in a model

When z = 1

If z=1 then we know we can use a list to model the call stack. In which case the number of nodes in the list will be the number of times the recursive function was called. Now here's a challenge:

How many times will the function, recurse, be called starting with n = 5?

recurse(n) {
  if(n===1) return
  recurse(n-1)
}

recurse(5)

When you figure out what that number is, let's call it the depth of our tree, that will be the total number of nodes we'll have.

When z > 1

If z >1, we know we'll have a tree. But even though it's typically straightforward to figure out how many times our function will be called, again, let's call this the depth of our tree, it's not always so straightforward to figure out how many nodes exist in the tree, especially when the depth is very large.

Here's another challenge. What's the depth of the tree formed when we call recurse(3).

recurse(n) {
  if(n===1) return
  recurse(n-1) // z > 1 because recurse calls itself 2 times
  recurse(n-1)
}

recurse(3)

I'll help out this time. The depth is 3. Here's a representation of one line of execution on the call stack to show how it's 3.

But this doesn't give us the full picture to help determine how many nodes will exist in total. Here's the full picture:

Take note of the pattern that evolves as a function of the number of direct recursions, z. In this example, the number of direct recursions in recurse is 2, z=2.

Note the pattern:

• depth 1: z^(0) nodes
• depth 2: z^(1) nodes
• depth 3: z^(2) nodes

When we substitute in z=2, this gives

2^0 + 2^1 + 2^2 = 7

nodes in total.

Thankfully, this is a common summation pattern that can be expressed as

The sum from n = 0 to n-1 of 2^n is (2^n) - 1

More generally, the sum from n=0 to n-1 of some number P^n is ((P^n) - 1)/(P - 1)

It's important to note the general case, noting that the sum becomes some constant c * P^n. This is important because it tells us that if we try to get the exact number of total nodes in a tree with z == 3 using (3^n) - 1 we'll get a wrong answer. But we're not looking for exact.

As long as asymptotic runtimes are concerned it's alright to say when z === 3, we have O(3^n) nodes in the call stack even though the actual total is lower. This is because we ignore constants and lower power terms when working with big O.

Which leaves us with the conclusion that when z > 1 and we know the depth of the tree, the total nodes in the tree can be upper bounded asymptotically by:

3. Sum up work done

Typically, we're looking at a fixed amount of work done in each node, corresponding to O(1) or O(n) or O(logn), e.t.c

In which case our big O runtime can be surmised as:

z^depth * runtime_per_node

For example, here are the corresponding upper bounds for recurse functions by z, where each node does O(1)

• z = 1 => 1^n * O(1) = O(1)
• z = 2 => 2^n * O(1) = O(2^n)
• z = 3 > 3^n * O(1) = O(3^n)

and if recurse did O(n) work per node as in

recurse(n) {
  if(n===1) return
  for each item i in n {
    n = n+1
  }
  recurse(n-1)
}

then those runtimes become:

• z = 1 => 1^n * O(n) = O(n)
• z = 2 => 2^n * O(n) = O(n2^n)
• z = 3 > 3^n * O(n) = O(n3^n)

Sometimes, like in merge sort and binary sort, each subsequent node is doing significantly smaller and smaller amounts of work, so much so that the naive upper bound derived from this approach is actually much larger that it really is, albeit correct as an upper bound. Just not very useful.

In these cases it pays to be knowledgeable of the master method.

Conclusion

Given a recursive function with z direct recursive calls, and a depth, d, where each node does O(w) work, the runtime can be upper bounded by O((z^d) * w).

However, take care when each subsequent node is doing a significantly smaller amount of work, as that upper-bound can typically be more tightly bound to a linear or super linear runtime using the master method, as is the case in merge sort and binary search where naive upper bounds of O(n^2) and O(n) respectively, can be tightly bound to O(nlogn) and O(logn) respectively.

Thought references

Naive merge sort and binary search analysis

With merge sort z = 2, because there are only 2 branches in each call, the depth = logn, because each branch gets n/2, and work done by each node is n, because we merge n items worst case in each node. In total we get 2^logn nodes x O(n) work per node = n x n = O(n^2).

With binary search z = 2, because there are only 2 branch statements in each call, the depth = logn, because each branch gets n/2, and work done by each node is O(1), because we simply do a size comparison in each node. In total we get 2^logn nodes x O(1) work per node = n x 1 = O(n).

Corrections to naive merge sort and binary search analysis

In reality, each node in merge sort does work that's a logarithm of n, giving us O(n nodes * log n work per node). While in binary search it's a mistake to think that there are always 2 recursive calls from each node. Even though there are two recursive statements, in each node only one of those statements is ever executed, leaving us with a list instead of a tree, and a runtime equal to the depth, logn.

... it’s interesting that you can express something like “an array of even length” using a TypeScript interface.

Vanderkam, Dan. Effective TypeScript . O'Reilly Media. Kindle Edition.

Intro

I want to start by saying I think it's really cool how JavaScript arrays can contain elements of different types. And it's even cooler that Dan has a plausible example of when we would want to use this feature and how to type such an array if we do use this feature. So let's dig in.

The example

Say we have a Lisp-like language defined in JSON

12
"red"
["+", 1, 2]  // 3
["/", 20, 2]  // 10
["case", [">", 20, 10], "red", "blue"]  // "red"
["rgb", 255, 0, 127]  // "#FF007F"

In this example, each array represents a function call, where the first element is the name of the function, e.g +, and the following elements are parameters to the function.

Our goal is to write type declarations for these inputs to make sure the inputs conform to a well-defined specification.

For motivation, note that the Mapbox library^[1] uses a system like this to determine the appearance of map features across many devices, so it's likely we'll come across similar libraries such as Mapbox whose JSON inputs we'll need to type.

For reference, this example is gotten from item 34 of the book, Effective TypeScript.

The process

Quite similar to regular development, Dan suggests adopting a test driven process, and I suggest reading the chapter to see the evolution of passing the test cases, but I want to focus on just the step that caught my interest.

Define test cases

Dan kicks off the process with these test cases, noting the expected outcomes in comments. As the process evolves, we check the output our typescript checker gives us against our expected outcomes.

const tests: Expression2[] = [
  10,
  "red",
  true, // true is not assignable
  ["+", 10, 5],
  ["case", [">", 20, 10], "red", "blue", "green"],  // Too many values
  ["**", 2, 31],  // Should be an error: no "**" function
  ["rgb", 255, 128, 64],
  ["rgb", 255, 0, 127, 0]  // Too many values
];

Vanderkam, Dan. Effective TypeScript . O'Reilly Media. Kindle Edition.

At step 3 of the process we're able to allow strings, numbers, and arrays starting with known function names, with the following type definitions.

type FnName = '+' | '-' | '*' | '/' | '>' | '<' | 'case' | 'rgb';
type CallExpression = [FnName, ...any[]];
type Expression3 = number | string | CallExpression;

const tests: Expression3[] = [
  10,
  "red",
  true,
// ~~~ Type 'true' is not assignable to type 'Expression3'
["+", 10, 5],
  ["case", [">", 20, 10], "red", "blue", "green"],
  ["**", 2, 31],
// ~~~~~~~~~~~ Type '"**"' is not assignable to type 'FnName'
  ["rgb", 255, 128, 64],
  ["rgb", 255, 0, 127, 0]  // Too many values
];

But the next step is the most interesting to me:

What if you want to make sure that each function gets the correct number of arguments?

Progressively define more accurate types

Here's the solution with progressively more accurate types, with my inline explanations.

type Expression4 = number | string | CallExpression;
// Read this as takes a number OR string OR CallExpression

type CallExpression = MathCall | CaseCall | RGBCall;


type MathCall = [
  '+' | '-' | '/' | '*' | '>' | '<',
  Expression4,
  Expression4,
];
/**
This expects an array of length 3, where the first element is

one of the characters in the union, and subsequent elements

are of type Expression4, which can be a CallExpression. 

Given CallExpression can also be a MathCall,

this makes this a recursive type,

where MathCall can point back to refer to itself.
**/

interface CaseCall {
  0: 'case';
  1: Expression4;
  2: Expression4;
  3: Expression4;
  4?: Expression4;
  5?: Expression4;
  // etc.
  length: 4 | 6 | 8 | 10 | 12 | 14 | 16; // etc.
}
/**
This expects an array of length 4 OR 6 OR 8 OR 10  e.t.c,

where the first element is 'case', and subsequent elements

are of type Expression4.
**/

type RGBCall = ['rgb', Expression4, Expression4, Expression4];

const tests: Expression4[] = [
  10,
  "red",
  true,
// ~~~ Type 'true' is not assignable to type 'Expression4'
  ["+", 10, 5],
  ["case", [">", 20, 10], "red", "blue", "green"],
// ~~~~~~                                ~~~~~~~
// Type '"case"' is not assignable to type '"rgb"'.
//          Type 'string' is not assignable to type 'undefined'.
  ["**", 2, 31],
// ~~~~ Type '"**"' is not assignable to type '"+" | "-" | "/" | ...
  ["rgb", 255, 128, 64],
  ["rgb", 255, 0, 127, 0]
  //                   ~ Type 'number' is not assignable to type 'undefined'.
];

What I found interesting here is that using recursive types, we can express the idea of a function calling other functions, e.g an addition function call, calling a subtraction operation ["+",["-", 5, 1],4].

And combined with the use of an interface, in this instance, CaseCall, we can express the idea of "an array of even length," using the length property.

I found it a brilliant use of simple operations to "almost" effectively model the complex array types we should expect.

I say almost because, even though the test cases come back positive against our expectations, the difficult to read error messages such as:

// Type '"case"' is not assignable to type '"rgb"'.

suggest that perhaps we should prefer a less accurate type than we've strived for. Dan gives more reasons for this preference in the chapter so again I suggest reading it.

For the record

["case", [">", 20, 10], "red", "blue", "green"],
// ~~~~~~                                ~~~~~~~
// Type '"case"' is not assignable to type '"rgb"'.
//          Type 'string' is not assignable to type 'undefined'.

comes about because this is an array of length 5, and so it cannot be of type CaseCall which only expects even lengths. Therefore the type checker assumes it's of type RGBCall.

Interestingly, when I try to define RGBCall as length 4, the type checker then assumes it's a MathCall

And if I continue along that path and fix MathCall to a length of 3, it concludes the expression cannot be a CallExpression, showing how powerful the length specification is when typing an array.

Conclusion: Prefer incomplete types to inaccurate types

The item containing this lesson concludes that we should avoid such complex types if they result in confusing error messages, and I think it's a really good point to note if you agree with Dan when he says the TypeScript's language services are as much a part of the TypeScript experience as type checking.

Dan also leaves us with the following re: the types from above.

The complexity of this type declaration has also increased the odds that a bug will creep in. For example, Expression4 requires that all math operators take two parameters, but the Mapbox expression spec says that + and * can take more. Also, - can take a single parameter, in which case it negates its input. Expression4 incorrectly flags errors in all of these:

const okExpressions: Expression4[] = [
  ['-', 12],
// ~~~ Type '"-"' is not assignable to type '"rgb"'.
  ['+', 1, 2, 3],
// ~~~ Type '"+"' is not assignable to type '"rgb"'.
  ['*', 2, 3, 4],
// ~~~ Type '"*"' is not assignable to type '"rgb"'.
];

Happy typing 🥳

Links

[1] - Mapbox Library

I left off session IV with a PR I said I'd come back to. It had 4 failing tests waiting on incoming tech debt to fix.

When I came back to it I just didn't like the idea of merging in a PR with failing tests... in real life no reviewer would let me, so let's continue session IV till we have all our tests passing.

Fixing our first failing test

Let's start with this case

      {
        name: 'one minute after, TO HAVE BEEN called',
        dateString: '2022-02-19T16:31Z',
        clockTick: 4000,
        dayExpected: 6,
        callsExpected: 4,
      },

Here, if the app crashed and restarts one minute after the cron job should have run, we still want the cron job to run. We want it to do this by checking if it's scrapped all the available data on Leetcode, and to run a scrape for any dates that haven't been scraped.

We haven't hooked up a db yet to store Leetcode data which we'll check against, but we can pretend we have one with a mock.

Initial attempt at a mockDb

Here's my initial attempt to think about a mockDb:

export class TasksService {
  private readonly logger = new Logger(TasksService.name);

  _called = undefined;
  _contestDate = undefined;
  _mockDb = undefined;

  constructor(contestDate: Date, mockD?: { string: boolean }) {
    this._called = 0;
    this._contestDate = contestDate;
    this._mockDb = {
      '26-02-2022': true,
    };
  }

  @Cron('* 30 4 * * sun')
  handleWeekly(): void {
    this.scrapeContestData();
  }

  @Cron('* 30 16 * * sat')
  handleBiWeekly(): void {
    console.log('today', this._contestDate.toUTCString());
    if (!this.checkDataExists(this._contestDate)) this.scrapeContestData();
  }

  scrapeContestData(): void {
    this._called += 1;
  }

  checkDataExists(key: Date): boolean {
    const ISOFomat = key.toISOString();
    return this._mockDb[ISOFomat.substring(0, ISOFomat.indexOf('T'))];
  }
}

The idea is that on instantiation of TasksService, I pass in my DB string and the index of the scraped data we want to find, so that TasksService can check whether a complete entry for that contest already exists.

Dealing with Dependency Injection

The first problem I'll face with this is injecting those constructor dependencies contestDate: Date, mockD?: { string: boolean }. If you've been following, you'd have noticed that NestJs has so far handled our dependency injection for our tests.

I need to figure out where to place these dependencies so that NestJs can automagically pick them up and inject them into the TasksService constructor when it's creating a new instance of TasksService.

The alternative is that I'll have to figure out how to do this imperatively, which is yeah, not a good idea, as that would mean potentially having to orchestrate the entire instantiation process manually, making sure that I instantiate classes needed further down the pipeline first, and so on and so forth. Better to leave this to an IoC container! If you want to learn more about dependency injection and IoC containers, I've written about dependency injection here.

Digging through NestJs Docs on Dependency Injection

Let's head back to the docs to figure out how NestJs does DI. There's an entry on how Dependeny Injection is done in NestJs which looks exactly like what we're looking for, so let's try that out.

I create a DataService class that will imperatively pull in the required info

@Injectable()
export class DataService {
  contestDate = undefined;
  mockDb = {
    '26-02-2022': true,
  };
}

I then use this class as a dependency in TasksService

...
import { DataService } from './data.service';
...


@Injectable()
export class TasksService {
  private readonly logger = new Logger(TasksService.name);

  _called = undefined;
  _contestDate = undefined;
  _mockDb = undefined;

  constructor(private dataService: DataService) { //<-- dependency injection
    this._called = 0;
    this._contestDate = this.dataService.contestDate;
    this._mockDb = this.dataService.mockDb;
  }

...

Now hopefully, we can mock out DataService when we need to for our TasksService tests. Let's try that!

Fixing issues with our mock approach

A moment later we're getting 15 failed tests, and when I try to start the app I get lovely red errors, so something's not right!

Looks like it's telling us to add DataService as a provider to our TasksModule

@Module({
  providers: [TasksService, DataService], // <-- added DataService
})
export class TasksModule {}

That seems to do the trick.

So back to our tests.

We're still getting 15 failed tests but It looks like the exact same problem, so let's see what happens when we add DataService as a provider to our tests.

    const module = await Test.createTestingModule({
      imports: [
        {
          module: AppModule,
          imports: [ScheduleModule.forRoot(), TasksModule],
          providers: [TasksService, DataService], //<-- added DataService here
        },
      ],
    }).compile();

Note: I noticed later on that adding DataService in this way really didn't do anything. I'm still not sure why at this point it seemed to do something.

Only 5 failing tests now and a whole bunch of undefined errors! We started off with only 4 failing so we definitely broke something but we'll figure it out.

Very quickly we can see that the undefined errors are because contestDate is undefined in the DataService class, but we'll leave that as it is because we're going to mock it in the tests anyway.

@Injectable()
export class DataService {
  contestDate = undefined; //<-- reason for undefined errors
  mockDb = {
    '26-02-2022': true,
  };
}

Mocking a NestJs Service

Let's get around to mocking our DataService. I don't remember exactly where, but I recall seeing a useValue pattern in one of the test examples, so I'm just going to search for useValue in the NextJs docs, and... found it!

According to the docs:

The useValue syntax is useful for injecting a constant value, putting an external library into the Nest container, or replacing a real implementation with a mock object. Let's say you'd like to force Nest to use a mock CatsService for testing purposes.

And this sounds like just what we need, so let's try it out!

A few moments later I've wired up a mockDataService

  const mockDataService = {
    contestDate: new Date(),
    mockDb: {
      '26-02-2022': true,
    },
  };

  beforeEach(async () => {
    const module = await Test.createTestingModule({
      imports: [
        {
          module: AppModule,
          imports: [ScheduleModule.forRoot(), TasksModule],
          providers: [
            TasksService,
            {
              provide: DataService,
              useValue: mockDataService,
            },
          ],
        },
      ],
    }).compile();

    app = module.createNestApplication();
  });

But we're still getting undefined issues, although, it looks like these have reduced in number.

I'm not sure why this is happening, but I'm more interested in my next problem:

Using a Dynamic mockDate per Test

I want to dynamically set the contestDate (later renamed to mockDate) per test, but the way I've set up my tests limits me to setting only one mock before all tests. How can I fix this? I decide I'll focus on each test case one at a time to spot a pattern for how to do this.

Starting with the highlighted test that is now failing when it used to be passing. Recall 5 tests now fail instead of just 4 we began with.

Recalling our error messages with the undefined errors, it's clear that our mock isn't being applied in some cases

I initially have a hunch it has something to do with the way we're getting our TasksService instance:

        const service = app.get(TasksService);

But it doesn't. The clue to what's wrong comes when I try to use the mock pattern in the TasksModule itself, and that works beautifully.

const mockDataService = {
  contestDate: new Date(),
  mockDb: {
    '2022-02-26': true,
  },
};
@Module({
  providers: [
    TasksService,
    {
      provide: DataService,
      useValue: mockDataService,
    },
  ],
})
export class TasksModule {}

If this is the case, then the pattern I've chosen for mocking in my tests is not the right one, so I first of all remove everything in my tests that does not make a difference, and that leaves me, surprisingly, with the realization that to create a TestingModule for this series of tests all I needed was my AppModule.

Using overrideProvider to correctly mock our DataService

Furthermore, after digging through the docs I find that when doing e2e testing (as we're doing here really) there's a pattern for overriding providers with mocks using the overrideProvider method.

  beforeEach(async () => {
    const module = await Test.createTestingModule({
      imports: [
        {
          module: AppModule, //<-- Only need to import AppModule
        },
      ],
    })
      .overrideProvider(DataService)
      .useValue(mockDataService)
      .compile();

Using this pattern finally allows me to mock the DataService module predictably, and clears all our undefined errors.

Getting rid of our beforeEach in favour of test.each

Once mocking was sorted, I pretty much went into the zone and stopped my real time documenting. During this period this question came up when I got back to solving the problem of dynamic mockDates:

How do we pass parameters to Jest's beforeEach hook?

I love the way it's answered in this stackoverflow question. We don't need to. The only reason I'm using a beforeEach hook is to keep things DRY (don't repeat yourself). So instead of complicating things, I move the beforeEach code into the test.each code block, which accomplishes the same DRY goal, but with the benefit of allowing me to pass dynamic mockDates.

And that's pretty much it. We end up with the code in this PR and 15 passing tests,

after implementing new methods in our TasksService to cater for the test cases that were failing.

import { Injectable, Logger } from '@nestjs/common';
import { DataService } from './data.service';
import { Cron } from '@nestjs/schedule';

@Injectable()
export class TasksService {
  private readonly logger = new Logger(TasksService.name);

  _called = 0;

  constructor(private dataService: DataService) {
    this.onStartUp(
      this.dataService.leetcodeDb.keys,
      this.dataService.mockDb.keys,
    );
  }

  @Cron('* 30 4 * * sun')
  handleWeekly(): void {
    this.scrapeContestData();
  }

  @Cron('* 30 16 * * sat')
  handleBiWeekly(): void {
    if (
      this.dataService.leetcodeDb.lastBiWeeklyKey === undefined ||
      !this.dataExistsInDb(
        this.dataService.leetcodeDb.lastBiWeeklyKey,
        this.dataService.mockDb.keys,
      )
    )
      this.scrapeContestData();
  }

  scrapeContestData(): void {
    this._called += 1;
  }

  dataExistsInDb(key: Date, mockDb: string[]): boolean {
    const ISOFomat = key.toISOString();
    const mockDbKeySet = new Set();

    mockDb.forEach((key) => mockDbKeySet.add(key));

    return mockDbKeySet.has(ISOFomat.substring(0, ISOFomat.indexOf('T')));
  }

  onStartUp(leetcodeDb: string[], mockDb: string[]) {
    const mockDbKeySet = new Set();

    mockDb.forEach((key) => mockDbKeySet.add(key));

    leetcodeDb.forEach((key) => {
      if (!mockDbKeySet.has(key)) {
        this.scrapeContestData();
        console.log(key);
      }
    });
  }
}

We also end up with a clunky looking DataService ... interface, which I'm sure will change as I learn from database patterns, such as the repository pattern, suggested in Nest's documentation.

Next Session

In the next session we'll hopefully start pulling in data from Leetcode and storing it in our DB of choice. I'm deciding to stick with my initial choice of a Postgres Db and to learn from whatever pain points I encounter if I've made the wrong choice.

Attributions

Thanks to Marco Santarossa for the cover image.

We ended the last session by getting our weekly cron tests passing. This session is about getting the biweekly tests passing.

How to schedule bi-weekly cron jobs

To get our tests passing our jobs will need to run every two weeks, and they'll need to do this even though the app is stopped and restarted, so far the cron time clocks in. And if for some reason the job couldn't run at the specified time we want it to retry.

But I very quickly got stuck on how to configure a bi-weekly schedule and posted a question on stackoverflow hoping to get some good ideas

Unfortunately, based on the friends I reached out to not having simple answers to this, and the fact that my stackoverflow question is still unanswered days after, it seems like this isn't a trivial problem or simply isn't possible with the cron specification, so it looks like I'm going to tradeoff having a fully automated bi-weekly cron job just so I don't get stuck in the weeds on a problem that doesn't really help achieve my project goal.

Last ditch research

Just making sure there isn't something obvious I missed, I check through @nestjs/schedule's convenience enum CronExpressions which contains regularly used patterns, but bi-weekly isn't on there.

I also find another nest-schedule module with a bit more functionality like the ability to specify max retries.

But after a time-box of about 30 minutes expires and no new information, I'm ready to move on.

The plan to get our bi-weekly tests passing

I have two main options I'm considering now:

A - generate the specific dates on which the biweekly job should run for at least a year in advance. Tech debt here being the need to continuously generate new dates or come back to fully automate this process.

B - Just run it every week, but don't run if the data we want to scrape is already in the db. Tech debt here being the work further down the pipeline needed to check our db for the info we need before our tests pass.

Given plan B's tech debt relies on work that was already going to come in I'm going with B.

Getting what tests we can passing for now

A few moments later we have one failing test which is going to keep failing till our tech debt is covered.

    test.skip('a week after Feb 19 at 4:30PM, scrapeContestData to NOT BE called', async () => {
      const service = app.get(TasksService);
      clock = sinon.useFakeTimers({
        now: new Date('2022-02-26T16:30Z').valueOf(),
      });
      await app.init();
      clock.tick(3000);
      expect(new Date().getDay()).toBe(6);
      expect(service._called).toBe(0);
    });

We also have two or more tests that don't really test what they should be testing. Here's an example of one:

    test('one minute after, TO HAVE BEEN called', async () => {
      const service = app.get(TasksService);
      expect(service._called).toBe(0);
      clock = sinon.useFakeTimers({
        now: new Date('2022-02-19T16:30Z').valueOf(),
      });
      await app.init();
      clock.tick(60000);
      expect(new Date().getDay()).toBe(6);

      expect(service._called).toBeGreaterThan(0);
    });

With this test, the intention really is... say our app was down and it restarted one minute after our cron time clocked in, we still want our job to 'run,' then transition to a 'have run' state, which we can check against.

However, instead of initializing our app one minute after the cron time to simulate a restart after the cron-time has passed, we are initializing it exactly at the cron time, so we're not actually testing the case we want to test here. I'm going to go ahead and make these and similar tests fail pending when the tech debt to get them passing is covered.

With that done, we have all the tests we can get passing for now all passing. And that pretty much wraps it up for this session.

We're moving onto the next session with 4 failing tests which we'll need to fix.

--------------------|---------|----------|---------|---------|-------------------
File                | % Stmts | % Branch | % Funcs | % Lines | Uncovered Line #s 
--------------------|---------|----------|---------|---------|-------------------
All files           |   88.37 |      100 |    87.5 |   84.84 |                   
 src                |   80.76 |      100 |      75 |      75 |                   
  app.controller.ts |     100 |      100 |     100 |     100 |                   
  app.module.ts     |     100 |      100 |     100 |     100 |                   
  app.service.ts    |     100 |      100 |     100 |     100 |                   
  main.ts           |       0 |      100 |       0 |       0 | 1-8               
 src/tasks          |     100 |      100 |     100 |     100 |                   
  tasks.module.ts   |     100 |      100 |     100 |     100 |                   
  tasks.service.ts  |     100 |      100 |     100 |     100 |                   
--------------------|---------|----------|---------|---------|-------------------
Test Suites: 1 failed, 1 passed, 2 total
Tests:       4 failed, 12 passed, 16 total
Snapshots:   0 total
Time:        7.359 s

Some refactoring and a pull request

I mentioned in the previous session that our tests could do with a for loop, since they all share the same structure, so I'm going ahead to do that quickly.

A couple of moments later and now we have just the one test, and an array of different cases. Using Jest's test.each method came in handy for this.

test.each(testCases)(
      '$name',
      async ({ dateString, clockTick, dayExpected, callsExpected }) => {
        const service = app.get(TasksService);
        expect(service._called).toBe(0);
        clock = sinon.useFakeTimers({
          now: new Date(dateString).valueOf(),
        });
        await app.init();
        clock.tick(clockTick);
        expect(new Date().getDay()).toBe(dayExpected);
        expect(service._called).toBe(callsExpected);
      },
    );

Our first PR

With that done I'm making our first PR to our main branch. Prior to this I've simply pushed directly to main but I want to come back to have a look at this code to see if there's anything obvious that needs changing before I merge it in.

Our next session

In the meantime I'm going to re-evaluate my decision to use PostgresDB over MongoDB for what will essentially be mostly json data.

Attributions

Cover Image: Thanks to Chuck Groom for surfacing it, and Vincent Dénie for creating it.

I ended part one by saying:

In terms of optimizations, it'll be much faster to scrape contest data and cache it for O(1) look ups. If I do create a UI this is the approach I'll take. Of course that'll require jobs that periodically scrape the leetcode site each time a contest is out. Unfortunately this added complexity is the reason I've shelved putting up a UI.

In part II I explore implementing this optimization by building out a UI starting out with a rough architecture diagram

I decided to build this using a Postgres DB, NestJs for the backend, the React Library for the front-end, and to host it on AWS. At the time of writing this, I'll be biasing for an MVC approach if that's possible with NestJs, otherwise I'll simply host my React based front-end on vercel, probably building it with Create React App or NextJs.

Creating a cron job to scrape Leetcode contest data

First session - Getting familiar with Nest

It's my first time using Nest so there's going to be a bit of learning curve.

Looked at Nest's documentation to get started: https://docs.nestjs.com/

Stopped when I spun up a working hello world app

Second session - Pulling in a cron module

Skipped to the scheduling section in Nest's documentation, because the first thing I want to build is a cron job that regularly scrapes the Leetcode contest data on a weekly basis.

Again, the nest documentation was helpful. Skimmed through this info, then had a look at their example code

tasks.service.ts

@Injectable()
export class TasksService {
  private readonly logger = new Logger(TasksService.name);

  @Cron('45 * * * * *')
  handleCron() {
    this.logger.debug('Called when the second is 45');
  }

  @Interval(10000)
  handleInterval() {
    this.logger.debug('Called every 10 seconds');
  }

  @Timeout(5000)
  handleTimeout() {
    this.logger.debug('Called once after 5 seconds');
  }
}

With NestJs it seems the idea is that we have modules, modules have controllers and controllers depend on services. Therefore services are like the workhorses where most of our implementation details will live, and controllers plumb services together? We'll see.

I stopped when I got the example code working locally

Third session will be writing unit tests for the scheduler I want to build

Third Session - Sketching out unit tests

To get started with the unit tests I start by sketching out an idea of what I want to achieve

tasks.controller.spec.ts

describe('scrapeContestData', () => {
  describe('weekly', () => {
    test.todo('Feb 13 at 4:30AM, scrapeContestData TO BE called');

    test.todo(
      'a day after Feb 13 at 4:30AM, scrapeContestData to NOT BE called ',
    );

    test.todo('a week after Feb 13 at 4:30AM, scrapeContestData TO BE called');

    test.todo(
      '2 weeks after Feb 13 at 4:30AM, scrapeContestData TO BE called ',
    );

    test.todo('one minute before ,should to NOT BE  be called');

    test.todo('one minute after, TO BE called');

    test.todo('one hour before ,should to NOT BE  be called');

    test.todo('one hour after, TO BE called');

    test.todo('one year later, TO BE called');
  });

  describe('biweekly', () => {
    test.todo('Feb 19 at 4:30 PM, scrapeContestData TO BE called');

    test.todo(
      'a day after Feb 19 at 4:30PM, scrapeContestData to NOT BE  called ',
    );

    test.todo('a week after Feb 19 at 4:30PM, scrapeContestData TO BE called');

    test.todo(
      '2 weeks after Feb 19 at 4:30PM, scrapeContestData TO BE called ',
    );

    test.todo('one minute before ,should to NOT BE  be called');

    test.todo('one minute after, TO BE called');

    test.todo('one hour before ,should to NOT BE  be called');

    test.todo('one hour after, TO BE called');
  });
});

The idea being that when I invoke a certain function or class method, it will either call scrapeContestData or not, depending on what the time is.

At this point I'm not entirely sure this is the correct way to think around testing the cron module I added in session 2, but it's a start.

So let's see how to flesh out these tests by thinking about it a bit.

From session 2 we know that the code which runs the cron jobs is bootstrapped in main.ts, and when the cron time clocks in, the log statement is printed, therefore any function we want to run should live within the cron handlers in our TasksService class.

Great! This makes it clearer that to check if functions in our cron handlers run. We simply need to mock TasksService and mock the date as well, run it (how?), then run an expect to have been called on the functions in our cron handlers.

Here's our TasksService class incorporating the idea of a scrapeContestData method:

tasks.service.ts

@Injectable()
export class TasksService {
  private readonly logger = new Logger(TasksService.name);

  scrapeContestData(): void {}

  @Cron('45 * * * * *')
  handleCron() {
    this.scrapeContestData();
    this.logger.debug('Called when the second is 45');
  }

  @Interval(10000)
  handleInterval() {
    this.scrapeContestData();
    this.logger.debug('Called every 10 seconds');
  }

  @Timeout(5000)
  handleTimeout() {
    this.scrapeContestData();
    this.logger.debug('Called once after 5 seconds');
  }
}

If I were strictly following TDD I shouldn't be updating this class just yet, but oh well!

Now let's pop over to the tests to see if we can mock this class and implement at least some of our tests. I'll be relying heavily on this example test code to get my bearings:

app.controller.spec.ts

import { Test, TestingModule } from '@nestjs/testing';
import { AppController } from './app.controller';
import { AppService } from './app.service';

describe('AppController', () => {
  let appController: AppController;

  beforeEach(async () => {
    const app: TestingModule = await Test.createTestingModule({
      controllers: [AppController],
      providers: [AppService],
    }).compile();

    appController = app.get<AppController>(AppController);
  });

  describe('root', () => {
    it('should return "Hello World!"', () => {
      expect(appController.getHello()).toBe('Hello World!');
    });
  });
});

A couple of minutes later....

We arrive at a reasonable looking test structure and our first failing test 🥳 🥳

tasks.controller.spec.ts

import { Test, TestingModule } from '@nestjs/testing';
import { TasksService } from './tasks.service';

const TasksServiceMock = {
  scrapeContestData: jest.fn().mockImplementation(() => {
    return;
  }),
};

describe('TasksService', () => {
  let tasksService: TasksService;

  beforeEach(async () => {
    const moduleRef: TestingModule = await Test.createTestingModule({
      providers: [
        {
          provide: TasksService,
          useValue: TasksServiceMock,
        },
      ],
    }).compile();

    tasksService = moduleRef.get<TasksService>(TasksService);
  });

  describe('weekly', () => {
    test('Feb 13 at 4:30AM, scrapeContestData TO BE called', () => {
      expect(tasksService.scrapeContestData).toHaveBeenCalled();
    });
   ...

Writing this test made me realize that for our TasksService class, we can directly name our cron handler scrapeContestData. So in our next session I'll focus on fleshing out all the tests and refactoring our TasksServiceClass in a TDD approach.

Fourth Session - Getting our cron tests passing

Part 1: Getting our Cron Tests Passing in NestJs 🎉

Part 2: Taking on Tech Debt to Handle Failing Bi-Weekly NestJs Cron Tests🎉

Part 3: Making use of Mocking and Dependency Injection to get NestJs Tests Passing 🎉

Project Discontinued

I decided to discontinue this project for two reasons. The first is that the time box I gave myself to complete this (end of March has elapsed) and the second is that I discovered Leetcode's virtual contest feature, which is essentially the feature this project set out to build.

Image links to Leetcode Journey - How to solve 1600+ LeetCode questions in one year?

Once I realised this pre-existing feature achieved my needs and given I wasn't planning to improve on it in anyway, I couldn't justify continuing this project.

However, I hope the the articles so far are helpful for people looking to work on a NestJs project, and that the Leetcode data scraping endpointthat I put up is useful to other people.

I got into practising DSAs daily back in 2020 when I was preparing to job hunt -- shortly after resigning from my previous job with nothing squared up.

I went through Stanford's course on DSAs on coursera and loved every bit of it. Then I walked through about 3 personally picked problems each day for maybe a month or two, keeping problem notes on Github, and not really tracking any metrics but focusing on truly understanding what I was doing.

However the first time I put that practice to the test with a Microsoft code assessment I came in at the bottom 36^th percentile. It was really disheartening looking at those problems I could solve, especially the graph problems, but knowing I wasn't moving fast enough to solve them optimally and correctly.

Anyway, shortly after that I got an offer for a fully remote role which I took so I never really bothered to reflect and improve on my practice process. Until now.

Since my tweet I've taken part in one contest and have been wondering how best to get back into practice. Do I refresh my theory first? Which platform should I use? What language do I use? e.t.c e.t.c. But most importantly, HOW do I practice -- what do I track?

Well yesterday I finalized on tracking speed of completion with the goal being to get into the top 10 percent (90th percentile) on Leetcode contests. And as with any competitive sport I need to constantly know where I stand against other players so I can appropriately track progress.

Unfortunately leetcode holds contests at most only once a week, so I decided to use past contests problems, time myself, and see where I would have placed based on my completion time if I had taken part.

Why not just do this manually?

Leetcode already ranks competitors, and it'd be super easy to just find out what rank falls within the top 10% within each competition and look at how long that person took to compare against my completion time. But for at least once in my life I wanted to be like every developer ever:

Spend 10 hours automating a task that will take 1 min to do manually.

And very importantly write about it 🤡 . (I recently joined an accountability group where we each have to write 1000 words a day and I need stuff to write about 😭 😭 )

Initial attempt

Research Findings

Leetcode returns contest data in pages of 25 results each. Getting all this data requires paginating through hundreds of pages.

I noticed the get request they use to get this page data doesn't require authentication, but it does have pagination enforced, so I decided I'd start with simply pulling in data from all pages of a contest.

Package Structure

I opted to create a simple yarn package and pull in axios and typescript, while writing my output to a local file.

Build and run process

I initially ran the script using two commands:

> yarn tsc app.ts
> node app.js <file-name>

but I quickly got tired of that and combined these into one yarn start command:

...
  "scripts": {
    "compile": "tsc app.ts",
    "start": "yarn compile && node app.js"
  },
...

So now I just run yarn start.

First draft of data fetching

The idea here was simple: while we haven't found a user who didn't make a submission, go through each contest page starting from the first one and push to an array containing all user's records with the records found on each new page.

const axios = require('axios');
const fs = require('fs');

interface ranker {
  rank: string;
  finish_time: number;
}
const competitors: ranker[] = [];

async function getUsers(url: string): Promise<ranker[]> {
  try {
    const response = (await axios.get(url)) as { data: { total_rank: ranker[] } };
    return response && response.data && response.data.total_rank;
  } catch (error) {
    console.error(error);
  }
}

async function buildCompetitors() {
  let res: ranker[];
  let page = 0;
  do {
    res = await getUsers(
      `https://leetcode.com/contest/api/ranking/weekly-contest-276/?pagination=${page}&region=global`,
    );
    competitors.push(...res);
    console.log(`https://leetcode.com/contest/api/ranking/weekly-contest-276/?pagination=${page}&region=global`);
    console.log(process.argv[2]);
    fs.writeFile(process.argv[2], JSON.stringify(competitors), (err) => {
      if (err) throw err;
      console.log('file saved');
    });
    page++;
  } while (res.find((val) => val.finish_time === 0) === undefined);
}

async function main() {
  await buildCompetitors();
}

main();

I let this run and went to bed, then came back to an error informing me that finish_time never gets to zero.

Okay fine, the error wasn't THAT polite:

(node:52369) UnhandledPromiseRejectionWarning: TypeError: Cannot read property 'find' of undefined
    at /Users/nnadozieokeke/leetcode-analysis/app.js:82:29
    at step (/Users/nnadozieokeke/leetcode-analysis/app.js:32:23)
    at Object.next (/Users/nnadozieokeke/leetcode-analysis/app.js:13:53)
...

but looking at it, it's really straightforward to see that res is only undefined if we've exhausted all possible objects, therefore the while condition is never true.

Figuring out why finish_time is never 0

Initially, when inspecting Leetcode's network requests I noticed the objects in each page had a finish_time property, and I just assumed this will tend to 0 and that partly informed my initial approach. But as I just stated above, it doesn't.

And try as I might, I couldn't figure out how to parse a single finish_time value to the table's corresponding Finish Time. Curious to know if anyone figures this out (Please comment). One thing I noticed is that the finish_time values increment as though counting seconds and this helped me change tact.

Rather than decode the time format Leetcode uses, I decided I'd find the value corresponding to a Finish Time of 00:00:00, then use that to convert other values to HH:MM:SS format by simply finding the difference in values.

Finding the finish_time value corresponding to 00:00:00

This value is typically on the first page with an object with score value === 0. So this reduces the problem to a search problem: find the first page with a score value of 0.

Of course we could search each page one at a time, but anyone into DSAs knows there're faster non O(n) algorithms for this problem, and I chose to use a recursive divide and conquer approach.

async function findLastPage(page = 0, step = 100): Promise<number> {
  let res: ranker[];
  page = page === 0 ? step : page;
  if (step === 0) return page + 1;
  console.log(`Searching from page: ${page}`, `In steps of: ${step}`);

  while ((res && res.find((val) => val.score === 0)) === undefined) {
    res = await getCompetitors(
      `https://leetcode.com/contest/api/ranking/biweekly-contest-69/?pagination=${page}&region=global`,
    );
    page += step;
  }

  return findLastPage(page - step * 2, Math.trunc(step / 2));
}

Using this, a search for biweekly-contest-69 gives a last page of 397 which is correct. Logs:

$ tsc app.ts
> Searching from page: 100 In steps of: 100
> Searching from page: 300 In steps of: 50
> Searching from page: 350 In steps of: 25
> Searching from page: 375 In steps of: 12
> Searching from page: 387 In steps of: 6
> Searching from page: 393 In steps of: 3
> Searching from page: 396 In steps of: 1
> 398

To be honest, I'm not sure if it's always correct because I really just went with the flow using feedback from my logs, but spot checks against 5 contests found the right page so I'm going with it.

Completing the percentile analyser

Alright, at this point with a working search function I felt I had the main tool I needed to get the insight I was looking for. In pseudo code here's the plan I followed:

1. Find the page with the first score of zero ( I assume all people who didn't hand in a solution with scores of 0 did not participate)
2. Retrieve the last place user's object to get the rank number and base finish_time. Here's what that looks like:

User in last place: { contest_id: 567,
  username: '_yash1_',
  username_color: null,
  user_badge: null,
  user_slug: '_yash1_',
  country_code: '',
  country_name: null,
  rank: 8633,
  score: 0,
  finish_time: 1632018600,
  global_ranking: 0,
  data_region: 'US' }

I use the finish time here as the reference point for the competition, and find the difference of all other times from this point to determine how long other users took.

I also use their rank to calculate on demand what ranks will fall within the top 10, 20, 30th... percentiles.

1. When I know what rank to look for depending on the percentile I'm interested in, I do another search for the object containing that rank.
2. Once that object is found, based on the time the user took, I'm able to tell what finish_time would have been required to fall within that rank's percentile.

The final code includes a bit more functionality, and it's available on github for anyone to play around with. I thought about adding a UI but tbh, I really just want to focus on increasing my percentile ranking right now so I've shelved that idea for now.

Thoughts and Optimizations

First thought is PLEASE DON'T judge my spaghetti code as a reflection of how I code for prod 😭 😭.

In terms of optimizations, it'll be much faster to scrape contest data and cache it for O(1) look ups. If I do create a UI this is the approach I'll take. Of course that'll require jobs that periodically scrape the leetcode site each time a contest is out. Unfortunately this added complexity is the reason I've shelved putting up a UI.

Other thoughts: I wish leetcode made this data available as an api for free -- I really only see it benefitting their community if developers can create on top of what they've built.

Repo Link

Leetcode Percentile Analyzer