R0 : Behavioural (Aced it)
R1 : delete even nodes from circular Linked List (Made mistakes but eventually solved it, many hints taken), swap nodes in pairs (did it with my eyes closed π)
R2 : Given a list of cards find the biggest straight in the cards (Interviewer was clumsy, her laptop lost charge and it took her 15-20 minutes to get started, I gave an unoptimized solution and then with a hint got to the optimal solution)
R3 : Design A Typeahead system (Luckily had studied it on Educative did my best here)
R4 : Build a MST, follow up built it without sorting the edges (Completely bombed π«π΅βπ«)
TC : 168k CAD
YOE : 7.5
#engineering #software #swe #google #faang #interview #sde #L5
Want to see the real deal?
More inside scoop? View in App
More inside scoop? View in App
blind
SUPPORT
FOLLOW US
DOWNLOAD THE APP:
FOLLOWING
Industries
Job Groups
- Software Engineering
- Product Management
- Information Technology
- Data Science & Analytics
- Management Consulting
- Hardware Engineering
- Design
- Sales
- Security
- Investment Banking & Sell Side
- Marketing
- Private Equity & Buy Side
- Corporate Finance
- Supply Chain
- Business Development
- Human Resources
- Operations
- Legal
- Admin
- Customer Service
- Communications
Return to Office
Work From Home
COVID-19
Layoffs
Investments & Money
Work Visa
Housing
Referrals
Job Openings
Startups
Office Life
Mental Health
HR Issues
Blockchain & Crypto
Fitness & Nutrition
Health Care & Insurance
Travel
Tax
Hobbies & Entertainment
Working Parents
Food & Dining
IPO
Side Jobs
Show more
SUPPORT
FOLLOW US
DOWNLOAD THE APP:
comments
In the OP's case, you'd want to use Prim's algorithm, not Kruskal's algorithm, to avoid pre-sorting the nodes.
Forget implementing this from memory, though, especially with optimal time complexity using Fibonacci heaps*. I'd honestly just tell the interviewer to grab the pseudocode out of Introduction to Algorithms, mainly to be cheeky. If someone is going to ask a question about a standard graph algorithm, then it should be permissible to talk about what to use and how it works without needing to implement it.
* Knowing my luck, I'd get an interviewer who would say "BuT fIbOnAcCi hEaPs ArE sLoW iN pRaCtIcE" and ding me for suggesting them without realizing that they're honestly better than all of the fancier heaps that came after.
I wouldn't expect a candidate to throw out something like that during an interview. If they did, though, then I'd be impressed enough to weight them as SH.
Honestly, the best way to prepare for these types of questions is just to know your audience. Look at what Google is doing with their products. Think about what types of problems they have to solve to deliver those products. If you do that, then you'll come up with a majority of the systems design questions that they could ask. You can then prepare enough in advance.
I hate leetcoding as a barrier for hiring. It's a terrible measure of someone's capability, as I've mentioned in other posts. I think it's a waste of time, especially if you've pushed production code that's used in a CMMI5 organization where lives are at risk if something goes wrong, have a well-established GitHub repository with our code, and so forth. But, right now it's part of the game. You might as well be good at playing the game and put yourself in the best position possible to negotiate.
Eventually, someone will get the bright idea that leetcoding and brain teasers are terrible and move on to something else that will, hopefully, be better.