Forem: Mostafa Gaafar

Learnings That Landed Me Jobs @ Amazon & Meta With No CS Degree

Mostafa Gaafar — Tue, 31 May 2022 18:20:28 +0000

As someone that has a non Computer Science college degree and did not have a strong background in algorithms, I always dreaded problem solving interviews and didn't think I'd be able to get a job at FAANG companies. I'm sure a lot of you are in the same position, so this article is a summary of my learnings in the past few years that enabled me to work at 2 of these companies.

I will focus on problem solving questions here as this was the hardest part for me to master through trial and error. I may follow up with articles on system design and behavioral questions later.

This will be a concise guide to help you pass the interview with minimal effort. I won't ask you to read lengthy books, and this article won't necessarily help you become a better engineer, but my aim is to help you do your best in algorithms interviews.

Disclaimers

This article is based entirely on my experience as candidate, not on any inside knowledge of interviewing processes. It's based on my experience interviewing at Amazon, Meta (Facebook), Google & Apple, but I imagine it's applicable to many large tech companies.
Do your own research on the company and team before your interview. Some companies hold online sessions to help you prepare for interviews which are very useful to learn about the specifics of a certain company.

1 Before the interview

1.1 Get the interview, obviously

When you're applying at big tech companies, you are more likely to get an interview round if an employee refers you for the job. I experienced applying online on my own and getting no reply at all, and then applying with the exact same CV through a referral and getting a call within days.

If you know someone at the company, don't hesitate to ask for a referral. Most people will help if you ask, and they may get a bonus if you are hired. If you don't know someone personally, you can try to build more connections through online forums or meetups. You can also reach out to recruiters or managers who are hiring directly on Linkedin.

1.2 Build algorithms foundation

If you don't have a strong background in algorithms (like myself), you need to start with the basic concepts and common algorithms. Your goal here is to be familiar with topics like sorting, searching, array/string manipulation, stacks, queues, hash tables, trees, basic graph traversals.

There's plenty of courses online for this. I personally refer to Princeton Algorithms Course Part 1 & Part 2

Part 1

Coursera https://www.coursera.org/learn/algorithms-part1
Youtube https://www.youtube.com/watch?v=9diDWV-fOnE

You need to know most of the algorithms in part 1, but focus on the more optimized solutions like quicksort & merge sort

Part 2

Coursera https://www.coursera.org/learn/algorithms-part2
Youtube https://www.youtube.com/watch?v=0qF7tPSQdCg and https://www.youtube.com/watch?v=6TW3JSVEJQE

You only need a few topics from part 2, like graphs and tries

There's also a cheat sheet from the course here https://algs4.cs.princeton.edu/cheatsheet/

Your goal is to understand the basic ideas from the course, then you will practice more coding when you start solving problems. Try not to take more than 1-2 months covering this course.

1.3 Practice problem solving

There are a lot of websites to practice coding problems, but what I found most useful is Leetcode which has a paid feature that shows you the exact questions that were asked at a specific company, and also can sort by most commonly asked questions, so you can practice with the most likely & realistic questions eg: https://leetcode.com/company/amazon/

The Leetcode premium plan is $35/months and you will only need it for 1-2 months when you are preparing. If this is too expensive in your local currency or you are a student, you can reach out to Leetcode and ask if they have discounts for your case. Lots of tech companies will happily offer a special discount even if they don't advertise it publicly.

It’s important to cover as many problem ideas as you can, even if you think about a problem for a few minutes then jump to see the solutions. Don’t think too long about problems marked “hard” or dynamic programming problems as they aren’t likely to show up in the interview, just check the solution and move on. Try to code 1 problem every study session and think about a few other problems then read their solutions. Practice to think out loud and narrate the solution as you code.

There's a good statistical likelihood that you won't pass the interviews on your first try, or that you will interview again in ~2 years if you get hired. So you should keep notes of all the problems you read with their links and their high level solution. This will save you a lot of time when you prepare for the next interview as you will start by going through these problems and refresh your memory instead of starting from scratch.

Also, this nice site will send you a random algorithms problem every day https://www.dailycodingproblem.com/

In the final review days before the interview, review the code for the common algorithms like depth first search, breadth first search, tree traversals with different order & binary search

1.4 Debug your code WITHOUT RUNNING IT

This is the single most important tip in this whole article. When you're practicing with something like Leetcode, it's very tempting to run your code immediately and see which cases fail and try to guess what went wrong. This is likely what you do when writing code daily, you write some code and run it to see if it works. This is the worst thing you can do when preparing for interviews.

In a problem solving interview, you usually won't be able to run your code, and interviewers expect you to be able to review your code and spot any bugs. Think of it as reviewing a pull request and trying to find issues with it. You should try to find all bugs and edge cases BEFORE running the code, as you will do in the actual interview. Your goal is to pass all test cases on the first run. More details on how to do this below.

1.5 Practice interviewing

The best practice for interviews is interviews. Try to interview more often. Do not wait 4-5 months to prepare before an interview. You will learn more from failing an interview than any preparation, and most companies allow you to apply again after 6-12 months.

If you have an important interview at a company you like, try to arrange 1-2 interviews at other companies (with a similar process) before it as practice. This way you will be less stressed about the important interview and if you end up getting multiple offers you will be in a better place to negotiate.

Even if you aren't actively looking to move, it's useful to interview every 1-2 years. This will help keep your interviewing skills sharp, and if you get a better offer it can help you negotiate a raise or promotion if you decide to stay.

If you can't easily get interviews at multiple companies, there are online services to set up mock interviews with experienced interviewers and get their feedback. I haven't tried these services so I can't recommend any of them. If you have a recommendation, please leave a comment with it.

2 In the interview

2.1 Before coding

Most companies switched from whiteboards to a code editor for coding interviews. If you have a choice, I recommend using a text editor as it’s much easier and faster to modify your code than on a whiteboard.
If you have a choice of which programming language to use, choose the one you’re most comfortable with. You want to focus on solving the problem, not remembering syntax. If you know multiple languages, choose one that’s faster to write. For example: manipulating lists and maps is easier in JavaScript or Python than Java.
Ask questions to clarify the problem and confirm your understanding.
Ask about the input & output formats, and valid ranges.
Mention any assumptions you make (don’t assume trees are binary search trees or balanced).
Draw/solve the problem verbally with some examples to validate your ideas.
Mention non-optimum solutions briefly but try to come up with a more performant solution before starting to code.
Mention the expected space & time complexity of your solution and if there are bounds on complexity, eg: if you must check all array items the complexity can't be lower than O(n). Make sure you include any steps like sorting or copying lists in the complexity.
Think about possible preprocessing scenarios that can optimize the overall solution, like sorting an array before traversing.
Some problems can be optimized by mutating the input, ask the interviewer such a solution is acceptable.
Don’t start coding until you and the interviewer feel good about the solution.

2.2 During coding

Outline the skeleton of the solution with comments, this prevents you from forgetting a step and helps the interviewer follow along.
Write correct code, not pseudo-code. Minor syntax mistakes are usually not a problem.
Apply all best practices of the language you use. Show the interviewer that you can write clean, maintainable code.
If you’re using an uncommon language or one that the company does not use, explain any advanced language features you use that the interviewer may not be familiar with.
Split your code to smaller functions with expressive names to clarify intent and make it easier to test. You may not need to implement some small functions if the interview says they aren’t important, which can save you some time.
Explain your solution and decisions as you code. Think about which alternative provides a more accurate solution, is this solution opinionated or generic?
Leave a // TODO for input validation and other non-critical steps if you don’t want to spend time on them initially. The interviewer will notice your attention to these details.
Use clear & expressive variable names to help the interviewer understand and help yourself avoid mistakes. Instead of names like i or j, use something like currentBookIndex
Use variables for array access to clarify intent, eg: currentCell = grid[rowIndex][columnIndex]
Think about early return conditions and optimizations.
For most problems, the solution should not be too long or too complicated. If your code exceeds ~30 lines and has several if/else branches, try to rethink it.
When stuck, think out loud and try to draw your thoughts on paper. Listen to the interviewer if they provide hints, they won't trick you.
Mention any limitations or potential optimizations. You can leave comments to revisit them if you have time later.

2.3 After coding

This is the critical part. Most people think they are done after coding the solution and don't pay attention to these steps. I personally failed multiple interviews just because I was too tired or too hasty to follow them properly

Run through the code verbally. Read the actual code you wrote carefully, not what you think you wrote. Forget that you wrote the code and examine it like it's garbage code that some idiot posted on Stack Overflow. You are biased to think that your own code is bug free and it takes effort to train yourself to interrupt this bias. If you can't find 1-2 bugs, then you need to try harder.
Look for specific parts of code that tend to cause bugs like: off by one errors in loops, math calculations, recursion exit conditions, what if a loop has no elements, what if a stack/queue becomes empty, what if input is null, empty input array, array of 0/1/2 items, input with duplicates, 0 or negative numbers, ...
Verify that space & time complexity match what you expect.
Ask the interviewer if you should come up with test cases for the code. List test cases with all different scenarios as if you are writing unit tests for your code.
Ask the interviewer if you should trace the code with a test case. Choose a small but non-straightforward test case to trace and debug your code on paper/board. Go through the code line by line keeping track of variable values and look for any bugs and modify your code as needed.

Final remarks

Problem solving interviews require some specific skills which may not always be relevant to your actual job. You need to train for these skills and understand that it might take a few tries to get it right.

If you fail, remind yourself that these interviews are not a great measure of your skill as an engineer which is impossible to measure in an hour. It doesn't matter how many times you fail as you only need to make it once. Learn from your failure and document all questions you encounter in interviews or practice to help you prepare better next time.

I Built a Site for the Best Coding Fonts

Mostafa Gaafar — Tue, 14 Apr 2020 15:11:26 +0000

I'm always looking for a coding font that looks great with my favorite editor theme and language. Searching for coding fonts has been a pain since there is no way to see how a font will look until you download and install the font, then change your editor to use it.

Enter Dev Fonts

devfonts.gafi.dev is a list of the best coding fonts I could find around, along with an interactive preview where you can change the preview theme, code language, or the code sample for the preview.

My current favorite font is Cascadia Code. What is yours?

The source code for the site is on github

PRs for missing fonts are welcome, check the notes here

7 Exciting New JavaScript Features You Need to Know

Mostafa Gaafar — Mon, 05 Aug 2019 15:08:46 +0000

This article has been translated to Japanese by @rana_kualu here https://qiita.com/rana_kualu/items/ee7694aa1cd4ae7f4483

JavaScript (or ECMA Script) is an evolving language with lots of proposals and ideas on how to move forward. TC39 (Technical Committee 39) is the committee responsible for defining JS standards and features, and they have been quite active this year. Here is a summary of some proposals that are currently in "Stage 3", which is the last stage before becoming "finished". This means that these features should be implemented in browsers and other engines pretty soon. In fact, some of them are available now.

1. Private fields `#`

Available in Chrome & NodeJS 12

Yes, you read that right. Finally, JS is getting private fields in classes. No more this._doPrivateStuff(), defining closures to store private values, or using WeakMap to hack private props.

Here's how the syntax looks

// private fields must start with '#'
// and they can't be accessed outside the class block

class Counter {
  #x = 0;

  #increment() {
    this.#x++;
  }

  onClick() {
    this.#increment();
  }

}

const c = new Counter();
c.onClick(); // works fine
c.#increment(); // error

Proposal: https://github.com/tc39/proposal-class-fields

2. Optional Chaining `?.`

Ever had to access a property nested a few levels inside an object and got the infamous error Cannot read property 'stop' of undefined. Then you change your code to handle every possible undefined object in the chain, like:

const stop = please && please.make && please.make.it && please.make.it.stop;

// or use a library like 'object-path'
const stop = objectPath.get(please, "make.it.stop");

With optional chaining, soon you'll be able to get the same done writing:

const stop = please?.make?.it?.stop;

Proposal: https://github.com/tc39/proposal-optional-chaining

3. Nullish Coalescing `??`

It's very common to have a variable with an optional value that can be missing, and to use a default value if it's missing

const duration = input.duration || 500;

The problem with || is that it will override all falsy values like (0, '', false) which might be in some cases valid input.

Enter the nullish coalescing operator, which only overrides undefined or null

const duration = input.duration ?? 500;

Proposal: https://github.com/tc39/proposal-nullish-coalescing

4. BigInt `1n`

Available in Chrome & NodeJS 12

One of the reasons JS has always been terrible at Math is that we can't reliably store numbers larger than 2 ^ 53, which makes it pretty hard to deal with considerably large numbers. Fortunately, BigInt is a proposal to solve this specific problem.

Without further ado

// can define BigInt by appending 'n' to a number literal
const theBiggestInt = 9007199254740991n;

// using the constructor with a literal
const alsoHuge = BigInt(9007199254740991);

// or with a string
const hugeButString = BigInt('9007199254740991');

You can also use the same operators on BigInt as you would expect from regular numbers, eg: +, -, /, *, %, ... There's a catch though, you can't mix BigInt with numbers in most operations. Comparing Number and BigInt works, but not adding them

1n < 2 
// true

1n + 2
// 🤷‍♀️ Uncaught TypeError: Cannot mix BigInt and other types, use explicit conversions

Proposal: https://github.com/tc39/proposal-bigint

5. `static` Fields

Available in Chrome & NodeJS 12

This one is pretty straightforward. It allows having static fields on classes, similar to most OOP languages. Static fields can be useful as a replacement for enums, and they also work with private fields.

class Colors {
  // public static fields
  static red = '#ff0000';
  static green = '#00ff00';

  // private static fields
  static #secretColor = '#f0f0f0';

}


font.color = Colors.red;

font.color = Colors.#secretColor; // Error

Proposal: https://github.com/tc39/proposal-static-class-features

6. Top Level `await`

Available in Chrome

Allows you to use await at the top level of your code. This is super useful for debugging async stuff (like fetch) in the browser console without wrapping it in an async function.

If you need a refresher on async & await, check my article explaining it here

Another killer use case is that it can be used at the top level of ES modules that initialize in an async manner (think about your database layer establishing a connection). When such an "async module" is imported, the module system will wait for it to resolve before executing the modules that depend on it. This will make dealing with async initialization much easier than the current workarounds of returning an initialization promise and waiting for it. A module will not know whether its dependency is async or not.

// db.mjs
export const connection = await createConnection();

// server.mjs
import { connection } from './db.mjs';

server.start();

In this example, nothing will execute in server.mjs until the connection is complete in db.mjs.

Proposal: https://github.com/tc39/proposal-top-level-await

7. `WeakRef`

Available in Chrome & NodeJS 12

A weak reference to an object is a reference that is not enough to keep an object alive. Whenever we create a variable with (const, let, var) the garbage collector (GC) will never remove that variable from memory as long as its reference is still accessible. These are all strong references. An object referenced by a weak reference, however, may be removed by the GC at any time if there is no strong reference to it. A WeakRef instance has a method deref which returns the original object referenced, or undefined if the original object has been collected.

This might be useful for caching cheap objects, where you don't want to keep storing all of them in memory forever.


const cache = new Map();

const setValue =  (key, obj) => {
  cache.set(key, new WeakRef(obj));
};

const getValue = (key) => {
  const ref = cache.get(key);
  if (ref) {
    return ref.deref();
  }
};

// this will look for the value in the cache
// and recalculate if it's missing
const fibonacciCached = (number) => {
  const cached = getValue(number);
  if (cached) return cached;
  const sum = calculateFibonacci(number);
  setValue(number, sum);
  return sum;
};

This is probably not a good idea for caching remote data as it can be removed from memory unpredictably. It's better to use something like an LRU cache in that case.

Proposal: https://github.com/tc39/proposal-weakrefs

That's it. I hope you're as excited as I am to use these cool new features. For more details on these proposals and others that I didn't mention, keep an eye on TC39 proposals on github

7 Reasons Why JavaScript Async/Await Is Better Than Plain Promises (Tutorial)

Mostafa Gaafar — Mon, 29 Jul 2019 00:26:45 +0000

Async/await was introduced in NodeJS 7.6 and is currently supported in all modern browsers. I believe it has been the single greatest addition to JS since 2017. If you are not convinced, here are a bunch of reasons with examples why you should adopt it immediately and never look back.

Async/Await 101

For those who have never heard of this topic before, here’s a quick intro

Async/await is a new way to write asynchronous code. Previous alternatives for asynchronous code are callbacks and promises.
Async/await is actually just syntax sugar built on top of promises. It cannot be used with plain callbacks or node callbacks.
Async/await is, like promises, non-blocking.
Async/await makes asynchronous code look and behave a little more like synchronous code. This is where all its power lies.

Syntax

Assuming a function getJSON that returns a promise, and that promise resolves with some JSON object. We just want to call it and log that JSON, then return "done".

This is how you would implement it using promises

And this is how it looks with async/await

There are a few differences here

Our function has the keyword async before it. The await keyword can only be used inside functions defined with async. Any async function returns a promise implicitly, and the resolve value of the promise will be whatever you return from the function (which is the string "done" in our case).
The above point implies that we can’t use await at the top level of our code since that is not inside an async function.
await getJSON() means that the console.log call will wait until getJSON() promise resolves and print its value.

Why Is It better?

Concise and clean
Look at how much code we didn’t write! Even in the contrived example above, it’s clear we saved a decent amount of code. We didn’t have to write .then, create an anonymous function to handle the response, or give a name data to a variable that we don’t need to use. We also avoided nesting our code. These small advantages add up quickly, which will become more obvious in the following code examples.
Error handling
Async/await makes it finally possible to handle both synchronous and asynchronous errors with the same construct, good old try/catch. In the example below with promises, the try/catch will not handle if JSON.parse fails because it’s happening inside a promise. We need to call .catch on the promise and duplicate our error handling code, which will (hopefully) be more sophisticated than console.log in your production-ready code.

Now look at the same code with async/await. The catch block now will handle parsing errors.
Conditionals
Imagine something like the code below which fetches some data and decides whether it should return that or get more details based on some value in the data.

Just looking at this gives you a headache. It’s easy to get lost in all that nesting (6 levels), braces, and return statements that are only needed to propagate the final result up to the main promise.

This example becomes way more readable when rewritten with async/await.
Intermediate values
You have probably found yourself in a situation where you call a promise1 and then use what it returns to call promise2, then use the results of both promises to call a promise3. Your code most likely looked like this

If promise3 didn’t require value1 it would be easy to flatten the promise nesting a bit. If you are the kind of person who couldn’t live with this, you could wrap both values 1 & 2 in a Promise.all and avoid deeper nesting, like this

This approach sacrifices semantics for the sake of readability. There is no reason for value1 & value2 to belong in an array together, except to avoid nesting promises.
This same logic becomes ridiculously simple and intuitive with async/await. It makes you wonder about all the things you could have done in the time that you spent struggling to make promises look less hideous.
Error stacks
Imagine a piece of code that calls multiple promises in a chain, and somewhere down the chain, an error is thrown.

The error stack returned from a promise chain gives no clue of where the error happened. Even worse, it’s misleading; the only function name it contains is callAPromise which is totally innocent of this error (the file and line number are still useful though).
However, the error stack from async/await points to the function that contains the error

This is not a huge plus when you’re developing on your local environment and have the file open in an editor, but it’s quite useful when you’re trying to make sense of error logs coming from your production server. In such cases, knowing the error happened in makeRequest is better than knowing that the error came from a then after a then after a then …
Debugging
A killer advantage when using async/await is that it’s much easier to debug. Debugging promises has always been such a pain for 2 reasons
1. You can’t set breakpoints in arrow functions that return expressions (no body).
  
  Try setting a breakpoint anywhere here
2. If you set a breakpoint inside a .then block and use debug shortcuts like step-over, the debugger will not move to the following .then because it only “steps” through synchronous code.
  
  With async/await you don’t need arrow functions as much, and you can step through await calls exactly as if they were normal synchronous calls.
You can await anything
Last but not least, await can be used for both synchronous and asynchronous expressions. For example, you can write await 5, which is equivalent to Promise.resolve(5). This might not seem very useful at first, but it's actually a great advantage when writing a library or a utility function where you don't know whether the input will be sync or async.

Imagine you want to record the time taken to execute some API calls in your application, and you decide to create a generic function for this purpose. Here's how it would look with promises

You know that all API calls are going to return promises, but what happens if you use the same function to record the time taken in a synchronous function? It will throw an error because the sync function does not return a promise. The usual way to avoid this is wrapping makeRequest() in Promise.resolve()

If you use async/await, you won't have to worry about these cases because await allows you to work safely with any value, promise or not.

In Conclusion

Async/await is one of the most revolutionary features that have been added to JavaScript in the past few years. It makes you realize what a syntactical mess promises are, and provides an intuitive replacement.

Concerns

Some valid skepticism you might have about using async/await is that it makes asynchronous code less obvious: Our eyes learned to spot asynchronous code whenever we see a callback or a .then, it will take a few weeks for your eyes to adjust to the new signs, but C# had this feature for years and people who are familiar with it know it’s worth this minor, temporary inconvenience.

Follow me on twitter @imgaafar

This article was originally published on Hackernoon

Forem: Mostafa Gaafar

Learnings That Landed Me Jobs @ Amazon & Meta With No CS Degree

Disclaimers

1 Before the interview

1.1 Get the interview, obviously

1.2 Build algorithms foundation

Part 1

Part 2

1.3 Practice problem solving

1.4 Debug your code WITHOUT RUNNING IT

1.5 Practice interviewing

2 In the interview

2.1 Before coding

2.2 During coding

2.3 After coding

Final remarks

I Built a Site for the Best Coding Fonts

Enter Dev Fonts

7 Exciting New JavaScript Features You Need to Know

1. Private fields #

2. Optional Chaining ?.

3. Nullish Coalescing ??

4. BigInt 1n

5. static Fields

6. Top Level await

7. WeakRef

7 Reasons Why JavaScript Async/Await Is Better Than Plain Promises (Tutorial)

Async/Await 101

Syntax

Why Is It better?

In Conclusion

Concerns

1. Private fields `#`

2. Optional Chaining `?.`

3. Nullish Coalescing `??`

4. BigInt `1n`

5. `static` Fields

6. Top Level `await`

7. `WeakRef`