The title of this article is the question I have been asking myself for a while now. I am working right now at a decent place but not happy with the kind of work I am doing on a daily basis. This made be wondering how can I jump to a higher package and at the same time do something relevant and meaningful in terms of contributing to something that actually makes an impact in the real world.

I tried a lot of things I was naturally interested in like LLM Inference, low level distributed programming in rust, but all of these things are niches and unfortunately the interview processes of these niches are not actually what you learn. So for examples for an llm inference optimisation role you won’t be asked to implement an optimised inference engine or any parts of it, these interview are usually to access you on how smart you are in general, meaning you strongly can you think about a problem and then come up with a solution and counter question your own solution and improve and iterate over it until you reach the most optimised solution. This sounds very similar to this kind of thinking is one thing we all hate in CS ( at least this is my assumption ) is DSA. Yes, Data structure and algorithms but not exactly your college placements average DSA questions, I am talking about the codeforces like problems which actually make to think about a problem rather than trying to learn 20 patterns and reusing them again and again in different problems. The reason a came to this conclusion was this article.

In this article Seb went through more than 1000 LinkedIn’s of people working at anthropic right now and the most common thing he found out was, majority of them came to anthropic from Google, meta, OpenAI, Deep mind, Jane street, Stripe etc. They were either working there or had some internship at anyone of these companies and these are the companies operating at an scale which is extremely big.

Now given all of this information ask yourself a question, how do people get into these companies ? and then ask again who are the people which stay at the top in these companies. The answer to both of these questions are the people who are actually interested in CS, who have an curiosity to really understand and build products. Another thing that was common among them was their codeforces rankings mostly 2900+. Here we have our answer, I am honestly not sure what is it about doing and solving these problems that train your brain to think faster and smarter than an average human and that is the exact skill your are paid $300K for. So a very clear roadmap for anyone is rather than trying to get into these AI labs directly one should try and get into the companies these labs are hiring from and then making a switch would just be easy for you. But getting into these companies which are known for their amazing infra and tech is a few hundred codeforces grinds away.

More than an article this is more of a roadmap I am writing for myself. I will start doing codeforces and start spending some amount of time everyday learning what is actually useful. Starting with clearing up the basics. These are my thoughts and what I think is worth doing in this brutal job market.

So, private key management can be done in a few ways, I will take you through the most popular three approaches platform like exchanges or a platform like Tiplink uses. The main problem that we are trying to solve is there should be no single point of failure i.e there should be no way that in the entire system there is a single authority that needs to be trusted to keep the private key safe. The transactions should be as trust less as possible and at the same time being robust.

Multi-Signatures (Multi-Sigs)

The name of this approach gives away a lot of information about what it would be about and how will it actually work. Let’s suppose there is a Exchange A which have a fat wallet with 50M USDT, now with this approach every time a user would want to withdraw whatever amount of asset they choose and the user gives in their wallet address to which they want to take the asset in, there will be multiple people involved which will sign a single transaction for transferring the X amount the user wants to withdraw and until all the people involved in the multi-sig has signed the transaction the user would not get there asset back. So, this reduces the very obvious loop hole of storing the private key of the fat wallet with so much money in a single place, there can be different types of multi-sigs like 3/5 or 10/20 i.e if at least 3 out of 5 (total no. of people in the multi-sig) signs the transaction the transaction will actually go through we would not need all the 5 people to sign the transaction. But this approach is also not the best one to use when dealing with so much volume like an exchange like Coinbase would do.

Shamir Secret Sharing

This approach is a similar one but a little non human involving. In this scenario, we have a private key and use an algorithm known as shamir secret, which divides the private key into multiple parts which does not resonate with each other. So, the algorithm does not work by straight up dividing the 32 bytes into 3 equal parts rather it uses some algorithms which make up the number of parts which are completely random to the human eye, but when combined together can you get back the same string that was divided back. Just like the multi-sigs there are also 3/5 or 10/20 etc. shamir secrets meaning you can also derive the result using only 3 of the 5 total parts.So, the way the platform would use this is, they will on the user signup crete this private key and after applying the algorithm store these parts in different servers across the world, and then whenever there needs to be a transaction we fetch all the parts and combine them to generate the private key again and proceed with the transaction. Now the main problem we were trying to solve remains the same, there is still a point where the private is accessible to any engineer in that company and they are get that out and drain all the money without getting identified, so in this case as well there is an assumption that the developer will not do something like this.

Here is a implementation of this algorithm. Shamir Secret

MPC (Multi Party computation)

This is the final and most efficient approach that will actually solve the problem we mentioned at the starting. In here there are again multiple servers involved, but unlike the Shamir Secret Sharing approach the private key is never reconstructed at any point of time. Instead, each server only has a share of the private key and all the servers together collaboratively sign the transaction without ever revealing or combining the actual private key into a single place.

So, let’s suppose there are 5 servers involved in this MPC setup. Whenever a withdrawal request comes in, each server independently performs a small cryptographic computation on its own share of the key and sends the result to the other participating servers. These computations are then combined mathematically to generate a valid signature for the transaction. The important thing here is that no single server ever knows the full private key and even during the signing process the actual key never exists in one complete form anywhere in the system.

This completely removes the single point of failure problem that we discussed earlier. Even if one server gets compromised, hacked or an engineer somehow gains access to it, they still cannot move funds because they only have a meaningless fragment of the key. To actually steal funds, an attacker would need to compromise multiple independent servers at the same time which becomes significantly harder in practice.

This is why most modern large scale crypto platforms and institutional custody providers are moving towards MPC based wallet infrastructure. It gives the security benefits of decentralisation while still allowing platforms to provide a smooth user experience without forcing users to manually manage seed phrases or private keys themselves.

Today we are going to talk about useRef hook, the almost most commonly used hook but still not a lot of people are clear about it’s actual use case. Well one of the reason for that is we are almost vibe coding our way through everything so who cares. Okay, it’s time to get technical now. We are going to build a video player while to go through the actual real world use case of this hook. Imagine you are given this task in an interview of a 100k job and this is the last round, so if you pass you get the job. It’s a do or die situation for you, so we gotta pass this no matter what. Let’s go.

To start we would need to initialize a react app for this, I am going to start with the extreme basics, so let’s run this command and start.

npm create vite@latest

It would ask you a few choices, so just go through them and start a react + typescript app. Okay, so to start we need to add a video tag and render that.

import React, { useState } from 'react'
import './App.css'

function App() {
  // This will be in the future used to update the state of the video element from anywhere 
  // -without triggering a re-render
  const videoRef = React.useRef(null)

  return (
    <div>
      <video ref={videoRef} width="400"
        src="https://www.w3schools.com/html/mov_bbb.mp4"
        style={{ display: "block", marginBottom: 12 }}
      />
    </div>
  )
}

export default App

Now, if you run this and go to the 5173 port on your browser, you will see a video playing. So a very basic next task in a video player is a play/pause button. Now if you are aware about the useState hook and someone asks you to build this play/pause button the first thought in your mind will be using this hook. But the problem with useState is that it re-renders the application whenever the value stored in it changes and the other problem is you cannot store any DOM element in it. useState only supports storing data and unfortunately a DOM element is not actually data. So, we need something else to store the DOM element of this video tag, so that whenever someone clicks on a button we are able to change the state of this video tag.

import React, { useState } from 'react'
import './App.css'

function App() {
  const [isPlaying,setIsplaying] = useState(false);
  
  const videoRef = React.useRef(null)
  
  const togglePlay = () => {
    if(isPlaying) {
      videoRef.current.pause()
    } else {
      videoRef.current.play()
    }
    setIsplaying(!isPlaying);
  }

  return (
    <div>
      <video ref={videoRef} width="400"
        src="https://www.w3schools.com/html/mov_bbb.mp4"
        style={{ display: "block", marginBottom: 12 }}
      />

      <button onClick={togglePlay}>
        {isPlaying ? "PAUSE" : "PLAY"}
      </button>
    </div>
  )
}

export default App

If you have a look at the code we added, it is just a button which is triggering a function and in that function we first check what is the current state of the video i.e if it is playing or it is stopped and then accordingly update the state to the opposite value, now this is where the videoRef is useful to us. Because one of them most useful thing about this useRef is that it does not trigger re-renders no matter how much the value of it is changed, and also just in case there is a re-render that state of the useRef stays the same across the re-renders.

Now, let’s implement another feature in our video player, a mute/unmute button. Now, for this we essentially do not require a useRef but things get tricky when the user have a volume slider as well in this button (which is a required feature). So, suppose the user mutes the video and at that moment the volume was 0.5, but when the user unmute the volume should be able to get back to the same amount. So, we need a way to remember what was the last volume at which the user muted so that we can set the volume to that same amount i.e we need a way to store a value and it should not change across re-renders until the value is explicitly changed. This is where again the useRef is used.

import React, { useState } from 'react'
import './App.css'

function App() {
  const [isPlaying,setIsplaying] = useState(false);
  const [isMuted,setIsmuted] = useState(false)
  const [volume, setVolume] = useState(1);

  const videoRef = React.useRef(null)
  const lasVolRef =  React.useRef(volume)

  const togglePlay = () => {
    if(isPlaying) {
      videoRef.current.pause()
    } else {
      videoRef.current.play()
    }
    setIsplaying(!isPlaying);
  }
  
  const toggleMute = () =>{
    if(isMuted) {
      videoRef.current.muted = false;
      setVolume(lasVolRef.current)
    } else { 
      videoRef.current.muted = true;
      setVolume(0)
    }

    setIsmuted(!isMuted)
  }


  const handleVolumeChange = (e) => {
    videoRef.current.volume = e.target.value
    setVolume(e.target.value)
    lasVolRef.current = volume
  } 

  return (
    <div>
      <video ref={videoRef} width="400"
        src="https://www.w3schools.com/html/mov_bbb.mp4"
        style={{ display: "block", marginBottom: 12 }}
      />
       
      <input
        type="range" min={0} max={1} step={0.05}
        value={volume}
        onChange={handleVolumeChange}
      />

      <button onClick={toggleMute}>
        {isMuted ? "MUTED" : "LISTEN"}
      </button>

      <button onClick={togglePlay}>
        {isPlaying ? "PAUSE" : "PLAY"}
      </button>
    </div>
  )
}

export default App

Again, as you can see we used two useState to store the current state because we need to show that on the frontend so, these should update the values.

So, this is how useRef is useful in maintaining a state across re-renders. Some other usecases of this would be when you want highlight the search bar when someone opens a modal, for this usecase as well you would need to store the DOM element of this input tag as well (the search bar).

Here is a link to the completed component: Github

Leave a comment

Share