[WK9-T] Mock coding interview, Warming up for open source contribution

1. Waking up

I woke up pretty early today! Woke up at like 7am ish just because my brother got up early for school and he asked where his belt was. I was forced to wake up but I couldn't sleep because I suddenly started watching webtoon for like an hour. Then I took a shower, and started working. So glad there's an option to work from home :D.

 

Yesterday was holiday (I think it was Waitangi day). I drove to city with my girlfriend, and went to karaoke to sing for like an hour. That was pretty good and she sings soooo well! Anyways, it was first relatively long distance drive, and I got pretty tired afterwards so I was able to sleep pretty quickly.  

 

Also, today a really smart person that I know from an year above who's working for faang now mock interviewed me. It was a pretty nervous experience despite knowing who they were. Some main feedbacks were:

 

Before interview

1. look at the interviewer when you talk to the interviewer (apparently i looked like I was staring into the screen)

2. prepare 5 min question for the interviewer (interviewer introduces him, so better pay attention to that)

 

During technical interview

3. write pseudocode as comments before diving in (like, very short comments per line though, max 7 words per line (so it would mostly be variable name because variable is what drives most of the code anyways). spend time here to minimise time spent later when changing up code. also this pseudocode gives interviewer chances to intervene and give help

4. confirm inputs. 'just confirming, inputs can be null root, perfect binary tree, or incomplete correct?'. you can draw out too (on google docs lol)

5. pseudocode everything before writing any code.

(// main returns boolean

// it also traverses through layers

// current

 

// child functions

// current

// traverses through nodes in layer)

6. Ensure good readability of code, good naming of variables and functions, no chunky if statements if they can be reduced.

IF STUCK: don't panic and draw out a diagram and reason through without code. Hopefully that makes me less nervous

 

After writing code

7. ask for more input, test edge cases

8. if you have time, do more pedantic tests (go through specific cases)

 

Deep dive into Leetcode medium, look at answer if needed and apply the technique to other similar questions. 1 hour every day, do weekly interview sesh with friends.

2. How to open source like a pro

I just used that title because it's eye-catchy. Anyways, here's why I needed to do this.

 

Context: There's an accessibility issue with a third party component that we are using. Specifically, keyboard focus on carousel won't stop the autoplay, whereas we would want it to pause when the carousel gets a focus. This is the open source component (carousel) I'm referring to. 

To do: 

- Pull that carousel repository to my machine, and link it as a dependency to a demo application

- Make the desired change and make a pull request

 

**Note: Currently, our application makes a use of version 2.2.7, but the carousel repo's master is on 3.something, and there's a 'version2' branch that's the closest to the version we are using (v2.3.8).

• I need to firstly see that v2.3.8 works with our current application. To confirm this, I just need to change dependency's version and run yarn, yarn build, yarn start, then see that nothing breaks.

2.1 How are projects linked? (ft. node_modules)

Here's a very simplified, minified view of how npm manages modules and how we can import functions etc from node modules. 

 

First of all, the bottom line is that node_modules contain folders, each of which is a self-contained source folder. 

 

When we do something like:

import Accordion from '@material-ui/core/Accordion'

There's a folder under node_modules: node_modules/@material-ui/core/Accordion.

 

Wait but Accordion is a folder. How does it export a functional component (Accordion)? Well that's because it has package.json that points to index.js file. This index.js file exports the Accordion function, and that's why node understands what it means to 'import' Accordion from a folder. 

 

Going up a level, when we have package.json that looks like this (of course there isn't such):

{
    "dependencies": {
    	"@material-ui/core": "1.1.1"
    }
}

it downloads the folder @material-ui/core from npm (which is sort of like github where source codes are uploaded to), and puts it under node_modules. There you go, there's the magic!

 

This means it should not be a surprise that we can add a local repository as a dependency, as long as that repository is a folder and it has package.json whose 'main' points to index.js, which exports functions etc from the source folder. This is how it works:

{
    "dependencies": {
    	"@material-ui/core/Accordion": "file:../../Accordion"
    }
}

 

2.2  Local repository as dependency

Now that we got a precursor out of the way, let's get into the core of our problem.

 

I need to make changes to the carousel repository in the local machine, and be able to see the changes it causes to how carousel behaves in our application demo. 

 

react-material-ui-carousel

 

This is the structure of the open source carousel repository. Note that the name of the folder (react-material-ui-carousel) is the npm package name (hence dependency name).  

Note that the files under dist are identical to files under src. When you run `npm run build` (after running npm install of course), then npm will handle all the depedencies and package them with the source code to create an equivalent set of self-contained files equivalent to src + node_modules. 

 

react-material-ui-carousel/package.json (simplified)

{
    "name": "react-material-ui-carousel",
    "version": "2.3.8",
    "main": "dist/index.js",
    "module": "dist/index.js",
    "scripts": {
        "start": "react-scripts start",
        "build": "NODE_ENV=production && npx rimraf dist && npx mkdirp dist && npx babel ./src --out-dir dist --copy-files"
    },
}

Takeaways: 

1. `npm run build` will output a build under a folder called 'dist' (ignore fancy rimraf mkdirp stuff)

2. dist/index.js is the file that exports the carousel, and is the main entry to this program. We know dist/index is the same as src/index.js after building. By looking at src/index.js below, we can confirm that index.js indeed exports Carousel.

3. 'main': 'dist/index.js' means that dist/index.js exports all the components that should be externally visible. when other projects access this folder, they will see package.json, and see that 'main' is dist/index.js, which should export components they need.

    IMPORTANT: the same mechanism applies for any node modules! look at their folder structure, each node module has package.json whose main field points to index.js that exports all the classes / functions that can be imported.

 

react-material-ui-carousel/src/index.js

import Carousel from './components/Carousel';

export default Carousel

...

sorry I just made you sleep

 

2.3 Ok what's the process?

I feel like I got distracted writing that stuff above and I couldn't be bothered polishing everything up, so I'll rather write steps that needs to be taken for this case of open source.

 

To test that local repository can be connected as a dependency

1. Pull the open source repository (will call it repo from now on)

      The repo should be a folder that contains package.json, whose "main" field references index.js that exports functions you need

2. In the application that uses the repo as dependency, remove that dependency line and on the terminal do:

`npm install --save <relative path>/<to>/<the repo>`

3. confirm that your application works (by npm start or yarn start)

 

Make changes

1. Make changes to the repo

2. npm build on the repo that index.js exposes the changed file

3. Do npm i (or yarn) on the application so that the local repository dependency is updated

4. confirm that your application works (by npm start or yarn start)

 

Contribute to the open source

1. Fork a branch and make a pull request