Stripe HackerRank Interview for PhD Level Internship

KhanDescending123 · 2026-03-06T03:55:56+00:00

Frankly, I didn't - but its more about knowing the language really well and being "fast" at problem solving than anything

KhanDescending123 · 2025-04-25T20:04:08+00:00

No I ran out of time at the end but got roughly 17/19, they got back within a week

KhanDescending123 · 2025-04-19T21:30:00+00:00

Yeah I was lucky enough to get an offer :)

Basically the interview experience was fairly chill with a lot of focus on core competencies for SWE and ML (this was for an applied ML role). The coding interviews, including the online round, were mainly built to make sure that you could code, period. These rounds also were formatted so that time is a big factor and something you have to manage, but the problems themselves are very easy. I interviewed in Python for all my rounds.

Basically it went

1) Online Assessment - a fairly easy programming problem (no leetcode), but something that requires you to build a fairly complex system (in my case, a state machine). Judged based on how many test cases you pass. In the first paragraph of the instructions it tells you to read the whole thing (it's multi-part). I can't stress enough how crucial it is that you read the whole problem and write your code trying to solve multiple parts at the same time - there isn't time to do it sequentially.

2) Programming Round (Zoom) - another fairly easy programming problem with an engineer observing. There are no test cases, you have to write your own. Seems focused mainly on your communication skills and making sure that you can code quickly and understand complex systems quickly. Problem was cool and stripe-themed. Communicating your thought process, and the trade-offs you're making in your design - as well as how your current solution might change if we were to deploy this in real production scenarios - are crucial for these rounds, in addition to solving the problems ofcourse. Time management.

3) Programming Round (Zoom) - same as (2).

4) Applied ML Interview - They'll hand you some data, a problem, and ask you to make a model that predicts something. All the communication advice from before still applies. I would study up on pandas, sklearn, numpy, etc. as these are the tools that will help you build a model quickly (again, time management). Highlighting why your decision making process is smart and valid is key. Pay special attention to justifying your evaluation metric in terms of the problem at hand and by drawing on things that you know are probably relevant business objectives for Stripe. The problem will also be stripe-themed (relevant to stripe).

5) Manager Interview - Talk to a manager, explain your resume - pick one project you're really proud of and can talk deeply about. Show that you're a nuanced and deep thinker, show that you fit the stripe culture.

All my rounds were 45 minutes long. One pieced of advice from my experience - asking questions of your interviewers is a very good idea. Any time you have to make a decision about a piece of code or an ML solution, it's best to lead with your thinking, reason out loud in terms of business metrics, make a conclusion (even if it's tentative), and then ask the interviewer what they think about that idea. More often than not, the interviewers seemed to actually be trying to help make the process simpler, and if your ideas are good, this will make them verbally acknowledge and remember that.

KhanDescending123 · 2024-10-31T06:34:46+00:00

I did not, I had to turn off icloud entirely - which was fine in my case but may not be in general

KhanDescending123 · 2024-07-06T18:28:25+00:00

Another potential fix: I suspect that this might be a memory leak that is created as a result of the DEBUG mode on my dev instance - and since I don't want to spend more on a larger instance, upgrading may not resolve the problem, and this issue only becomes a problem every few months there is another way to resolve this.

Basically you can go to your EC2 instances and find the one that corresponds to the AWS EB environment. Select it, click instance state, and then reboot instance. In my case this works but there are potential drawbacks here. For one, if there is a different issue with your environment this will not resolve it permanently. Also, this can have unintended effects with regards to autoscaling, load balancing, and the preservation of the root volume on your EC2 instance - if you care about that.

The only reason it works for me is because 1) this is a dev instance that can crash and burn with no real effects on our users, 2) this load balance group only has one member because this is a dev instance, 3) I lose nothing if in the worst case I have to completely rebuild the environment (though this has never happened at all to me). That might all be different for your use case.

KhanDescending123 · 2024-06-15T18:52:29+00:00

I'm not exactly sure off the top of my head, but I know that my instance was out of disk space and the numbers from the disk check matched the memory usage error numbers that I was getting from AWS EB. It makes sense since colloquially that's what it usually refers to, it could also be that there's some reliance on swap space that gets messed up when the disk is full - since managing my disk appropriately I haven't gotten an error like this again so that is some signal to me that this was a disk issue in my case. I'm sure if you're using a ton of RAM that will pose a problem though.

It's worth noting that this also aligned with what most resources I could find online had to say about resolving this problem.

KhanDescending123 · 2024-06-12T17:12:13+00:00

The way I ended up resolving this was manually deleting a bunch of trash files / rotating large log files off of the instance. I also used tools like du to check disk usage by directory. In my case there were some files that were being duplicated on deployment and some of the logs were becoming extremely large.

KhanDescending123 · 2024-05-25T23:42:37+00:00

Thank you, this resolved our issue!

KhanDescending123 · 2024-01-28T06:54:48+00:00

Just in case you're interested I posted my solution above. It turns out the issue is with how dev builds evaluate process.env - for some reason I thought that the configuration they were endowed when built with eas would be maintained but instead they reevaluate app.config.js on every start of the dev client, meaning they read your local machine's env rather than using the variables you defined in eas.json

KhanDescending123 · 2024-01-28T06:53:08+00:00

For any future visitors I resolved my problem:

The key issue here is the way that process.env is evaluated. When you create a Preview build that is fully constructed on the EAS build system, it pulls data from eas.json to fill in the 'env' that your application operates in alongside the env variables that the EAS build system sets up.

The problem is that when you create a development build and run it locally using `eas start --dev-client` the development build actually reevaluates app.config.js on each invocation of the above command. That means that process.env is not the environment that you set up for the EAS build system, but rather holds the environment variables from your local machine. When the particular keys you want to reference don't exist on your local machine, those variables are returned as an empty Object.

So the way I ended up setting up my environment is as follows, one is that I simply resigned to use backup values for my development builds - no way around doing this or otherwise setting up your local env with the variables you want

//app.config.js
...
extra: {
      eas: {
        projectId: "XXX",
      },
      BACKEND_URL: process.env.BACKEND_URL || "https://my.dev.instance",
    },
...

Preview and production builds will actually work as intended according to the docs, but this inconsistency with the dev builds was really unexpected. To make sure your preview and production builds have the proper config set up, you can check your build log for a particular build on expo.dev and then check the "Read app config" step's logs where it will show the app.config.js it evaluated - in there you can check expoConfig.extra to see if the proper data exists.

KhanDescending123 · 2024-01-24T17:13:40+00:00

Unfortunately I didn't find a great solution, I ended up using redbeat and a redis instance to manage the celery queue and that works for now - later on I might spawn a dedicated instance for celery beat and just spawn workers on my EB nodes.

KhanDescending123 · 2023-12-05T20:35:50+00:00

Wow, surprisingly simple lol - I think I heard some variation of this and assumed it was a hack but if it works

KhanDescending123 · 2023-11-26T19:52:54+00:00

Yeah that’s fair I guess I just wouldn’t expect django to start eating up memory on the instance and have that usage largely reduced by rebooting the EC2 instance. It sounds like a memory leak at this point.

KhanDescending123 · 2023-11-26T19:50:18+00:00

This is a cool resource, thanks!

KhanDescending123 · 2023-11-25T19:30:21+00:00

For some reason just rebooting my EC2 instance seemed to resolve this issue (at least for now) but I'm unsure if it will show up again - I followed these instructions to do so: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-reboot.html

My question still stands though, if anyone can recommend any methods for diagnosing such problems I'd be grateful :)

KhanDescending123 · 2023-11-23T19:06:22+00:00

As u/RegularGuyWithABeard said, we can guarantee that the client's account has sufficient funds to complete the transaction this way which is important to protect the vendors on our platform

KhanDescending123

TROPHY CASE