Skip to content

Instantly share code, notes, and snippets.

View ankibalyan's full-sized avatar

Ankit Balyan ankibalyan

View GitHub Profile

What Hiring Should Look Like

This is definitely not the first time I've written about this topic, but I haven't written formally about it in quite awhile. So I want to revisit why I think technical-position interviewing is so poorly designed, and lay out what I think would be a better process.

I'm just one guy, with a bunch of strong opinions and a bunch of flaws. So take these suggestions with a grain of salt. I'm sure there's a lot of talented, passionate folks with other thoughts, and some are probably a lot more interesting and useful than my own.

But at the same time, I hope you'll set aside the assumptions and status quo of how interviewing is always done. Just because you were hired a certain way, and even if you liked it, doesn't mean that it's a good interview process to repeat.

If you're happy with the way technical interviewing currently works at your company, fine. Just stop, don't read any further. I'm not going to spend any effort trying to convince you otherwise.

Everything I Know About UI Routing

Definitions

  1. Location - The location of the application. Usually just a URL, but the location can contain multiple pieces of information that can be used by an app
    1. pathname - The "file/directory" portion of the URL, like invoices/123
    2. search - The stuff after ? in a URL like /assignments?showGrades=1.
    3. query - A parsed version of search, usually an object but not a standard browser feature.
    4. hash - The # portion of the URL. This is not available to servers in request.url so its client only. By default it means which part of the page the user should be scrolled to, but developers use it for various things.
    5. state - Object associated with a location. Think of it like a hidden URL query. It's state you want to keep with a specific location, but you don't want it to be visible in the URL.

Bundling Design Systems/Component Libraries

First of all you need to decide who will be your target consumers based on the following:

  1. They have the same environment(webpack config, babel config) setup as you where you built your design system(this is mostly possible if you use monorepos/same configs where all the teams share the same environment).

  2. They don't have the same environment which is the case when you work in bigger teams and you want to distribute your design system as any other npm package which is already built and can be used directly.

If your use case falls under case no. 1 then you can just compile the source babel src -d build and leave the bundling to the consumer projects tools(webpack/rollup)

@MWins
MWins / project-ideas01.md
Last active July 27, 2024 19:39
Back end Projects - list

Project Ideas

Ok. I'm going to list off some ideas for projects. You will have to determine if any particular idea is good enough to include in a portfolio. These aren't creative ideas. They likely already exist. Some are way too advanced while others are simplistic.

I will recommend to post any project you make to github and make a github project page for it. Explain in as much detail as possible how you made it, how it can be improved etc. Document it.

If you pick an advanced idea, setup a development roadmap and follow it. This will show some project management skills.

Another piece of advice for those who are design challenged. Use different front end frameworks and use different themes for those frameworks to provide appealing designs without looking like yet another bootstrap site.

@siddharthkp
siddharthkp / reactivconf-2017-proposal.md
Last active February 25, 2024 10:06
Building applications for the next billion users
@vasanthk
vasanthk / System Design.md
Last active July 27, 2024 18:36
System Design Cheatsheet

System Design Cheatsheet

Picking the right architecture = Picking the right battles + Managing trade-offs

Basic Steps

  1. Clarify and agree on the scope of the system
  • User cases (description of sequences of events that, taken together, lead to a system doing something useful)
    • Who is going to use it?
    • How are they going to use it?

Folder Structure

Please note

While this gist has been shared and followed for years, I regret not giving more background. It was originally a gist for the engineering org I was in, not a "general suggestion" for any React app.

Typically I avoid folders altogether. Heck, I even avoid new files. If I can build an app with one 2000 line file I will. New files and folders are a pain.

@balupton
balupton / README.md
Last active June 7, 2021 16:00
Node.js Best Practice Exception Handling