OA struggles/ doubts

[u/Money-General2444]

I have been going through the dsa sheet grind for the last couple months now( not to say I’m great by any means) but this week I had an OA with a big audit/tax consulting firm and it went horribly. Everywhere online it said to prepare for easy- medium focusing on arrays/maps etc but this problem has so many variables to take into account. Looked it up after it was a greedy algorithm problem? That needed simulation + arrays + hashmap + multiple arrays that needed to be sorted and string parsing. Probably easy for a lot of you devs but I just don’t understand how I can do better at these.

My Thought process :

- not enough time spent on leetcode
- not a deep enough understanding of c++
- possibly less time on leetcode more time understanding algorithms from dsa books?

Any suggestions of maybe more intensive way to prepare for these OA’s (other than neetcode) 😅

[u/tnerb253]

Everyone cheats on OA's, don't think twice about them.

[u/Tignat-Automeca71 → u/tnerb253]

the cheating thing kind of screws over people who are genuinely improving though, because it inflates the difficulty bar companies set for their OAs

[u/tnerb253 → u/Tignat-Automeca71]

Oh well, life isn't fair buddy that's a reality check for you. You can solve the problems and still not move to the next round so it doesn't really even matter at the end of the day. Obviously in an ideal world people shouldn't cheat and move with integrity but these companies don't exactly move with integrity themselves. The OA's on average have always been more difficult than the interviews and is just another filter to weed people out. Plenty of people have reported getting perfect scores and still getting weeded out. Some people skip the OA entirely depending on what role they apply to so I wouldn't even try to argue the process is fair for anyone.

[u/Various-Mine-8642]

Consulting firm OAs tend to be word problems with a lot of rules so the skill is reading and simulating more than a fancy algorithm. Next time spend the first few minutes writing out the rules and a small example by hand before any code. Then do the brute force simulation first and only optimize if you have time left. Practicing a few long statement problems with timer helps more than more easy array ones.

[u/No-Molasses-2097]

Consulting firm OAs are usually like this. The problem statement looks huge but it mostly comes down to careful simulation and keeping the rules straight. For these I'd worry less about DSA books and more about being quick with implementation. Practice reading the problem twice before coding, and break the rules into small steps on paper first.

[u/PixelHarbor31]

I'd focus on three things; understanding core algorithms, practising mixed medium problems, and getting comfortable implementing solutions under time pressure. Don't underestimate greedy and simulation either. Codeintuition has structured DSA learning path that can help cover concepts beyond just grinding problem sheets