WORST ON-SITE INTERVIEW of my career - interviewers trying to find fault in your code/knowledge and turning out to be wrong about half the things themselves ! WASTED SEVERAL days. Highly unprofessional, probably even unethical... 0) Was contacted by their HR about the lead position in the Tripod SDK team (Flickr derivative) 1) Phone screen went very well (coding question: find closest common ancestor in BST) & I established great rapport with manager & role seemed very interesting 2) Then they asked me to do a coding assignment which they claimed would take 4 hrs. It actually took 12+ hours to do & was obvious from start that it was much bigger than 4 hrs but I still did it 'cos 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-fetchImage 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 and this shows a full screen version of image 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 & 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 3) I wrote it, made a bunch of hacks/compromises in 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. 4) I then mailed 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. 5) 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 judgement about code they didn't like / understand. 6) The 2nd phone screen went great (again) 7) I went to the onsite, in which the 1st session was an hour of code review with a panel of 3 devs + the manager. Somwehere in the first 20 mins of that, one dev (asking most of the questions) claimed "the code won't work if user presses the back button & comes back..." - I demo'd that case in the app (obviously they hadn't even run the code) and it worked perfectly fine. 8) Then further down he made a claim that it won't handle a rare corner case scenario well and spent the next ten mins arguing back-n-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) and 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... 9) 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) 10) 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).