WORST ON-SITE INTERVIEW of my career.

Interviewers were trying to find fault in my code and knowledge, and turned out to be wrong about half the things themselves! WASTED SEVERAL days. Highly unprofessional, probably even unethical.

1. Was contacted by their HR about the lead position in the Tripod SDK team (Flickr derivative).

2. Phone screen went very well (coding question: find closest common ancestor in BST), and I established great rapport with the manager. The role seemed very interesting.

3. Then they asked me to do a coding assignment which they claimed would take 4 hours. It actually took 12+ hours to do. It was obvious from the start that it was much bigger than 4 hours, but I still did it because I was that interested in the role. Am I slow? See for yourself: Write an Android app that: i) Searches Flickr for images whose metadata matches a string. ii) Parses the search results, constructing URLs based on multiple size criteria and fetching those images from their CDN. This requires understanding their API docs and using multiple APIs. iii) Shows the images in an infinite scrolling view (involves repeating the above search-fetch image steps as the user keeps scrolling, maintaining scroll state, etc. – not trivial). iv) Implements swipe-to-refresh on top of the RecyclerView. v) Has a LightBox mode that opens when the user clicks an image, showing a full-screen version. vi) Lightbox mode has a Download button which fetches the ORIGINAL size image from Flickr (which needs a separate API call and more doc reading and coding). vii) Lightbox mode has an "Open in Flickr" button. viii) Handles orientation changes well in all cases. ix) A bunch of other features that were not minimum required and which I didn't bother with. x) All of the above should be well architected, have good UX, handle multithreading well, etc., etc.

4. I wrote it, made a bunch of hacks and compromises in the code for the sake of reducing coding time, and clearly documented these shortcuts, indicating how they should be done in production. I tested the code, tested UX. It works buttery smooth, works for ALL scenarios I tested, handles orientation, etc., etc. It just. Works. Well. On submitting the code, I got rejected with ZERO feedback.

5. I then emailed them asking for feedback and explaining my design goals. They then "re-considered" and asked me to alternatively do another phone screen and come for a longer on-site. I agreed but still pressed for feedback on my code.

6. I got totally vague and lame feedback like "ViewPagerAdapter handling of the items" and "some minor leaks" – those are the exact words. It looked more like someone evading saying anything at all for fear of making it obvious that they had made a hasty judgment about code they didn't like or understand.

7. The 2nd phone screen went great (again).

8. I went to the on-site, in which the 1st session was an hour of code review with a panel of 3 devs plus the manager. Somewhere in the first 20 minutes of that, one dev (asking most of the questions) claimed "the code won't work if the user presses the back button and comes back..." I demo'd that case in the app (obviously they hadn't even run the code), and it worked perfectly fine.

9. Then, further down, he made a claim that it wouldn't handle a rare corner-case scenario well and spent the next ten minutes arguing back and forth about it, blatantly telling me "No, it won't save instance data" / "No, the bundle will be null," etc. Hardly a manner to conduct an interview in. I was almost certain he was wrong again (later checking the docs online confirmed it). Since I realized my entire interview outcome hinged on being judged on little pet items like these, I did argue back and got increasingly flustered in the process, and finally had to concede that I MAY not know enough about that scenario...

10. Next, he seemingly found a problem in handling another rare scenario (system killing an app under memory pressure) – which again I explained would work totally fine, except that the app would re-fetch 100s of KB of data from the net (you see that as an issue? A single image is MBs of data).

11. By the end of this round, it became pretty clear to me that this interview was not about assessing me but more about finding reasons to reject me (probably since I'd earlier criticized their cursorily dismissive code review process).

Find the first common ancestor of a BST.