Screen:\nhttps://leetcode.com/problems/product-of-array-except-self/ \nhttps://leetcode.com/problems/top-k-frequent-elements/\n\nOn-site:\nhttps://leetcode.com/problems/valid-palindrome-ii -> followup  https://leetcode.com/problems/valid-palindrome-iii\nhttps://leetcode.com/problems/merge-intervals/ variation with 2 arrays of intervals merged into one\nhttps://leetcode.com/problems/nested-list-weight-sum/\nhttps://leetcode.com/problems/closest-binary-search-tree-value\n\nSystem design:\n5 billion people try to get 100k tickets to a concert at the same time. When a user gets a ticket it has 5min to validate the payment to an external system which is not of our concern, if time expires the ticket is back into the pool. No authentication involved. \n\nCoding was a breeze - questions were standard.\n\nOn Sys design (which was my main weakness) I think I got my main ideas right - multiple reservation servers behind load balancer  to handle the 5B, which also generate unique user id by sequencing and prepending server id; distributed queue towards processing server that updates a table in a relational db which assigns a ticket ID to a user and a timestamp; cron checks the timers and makes tickets eligible again; a late idea came to my mind to have a eligible tickets write-around cache for the reservation servers to decide if the user should be added to the queue or not; \nDidn\'t know to respond to the "how many servers are needed" question - back of the envelope is my weak point.\n\nNo resolution or feedback from the recruiter - this really sucks. \n\n\n\n\n\n

Screen:\nhttps://leetcode.com/problems/product-of-array-except-self/ \nhttps://leetcode.com/problems/top-k-frequent-elements/\n\nOn-site:\nhttps://leetcode.com/