Android – Picasso vs UniversalImageLoader vs Glide vs Fresco

Someone asked a question on Stackoverflow the other day about the existence of so many image libraries in Android .

Since this is a pretty opinionated topic, I made a table to represent what I thought about the libraries based on personal experience of having used them or working with people who used them

Screenshot 2015-04-16 19.42.09

(Click on the image for better visibility)

Its interesting to note that Fresco seems to be a new library that is doing some interesting optimizations to memory use and could be worth checking out.


Cheryl’s breaking the internet

Recently this 5th grade olympiad question from Singapore went viral


This is pretty difficult agreed for a fifth grader – but being an olympiad puzzle its meant to be difficult and challenging but smart kids can solve it. I wonder why adults are making a fuss out of this one ?

Well it took me about 3 minutes to solve and the solution follows, so solve it before you proceed to the solution bit


Lets break it down statement by statement


May 15, 16, 19

June 17, 18

July 14, 16

August 14, 15 17

  • Albert says – I don’t know when Cheryl’s birthday is but I know that Bernard does not know too
  1. The first part of the sentence is moot(is it?). Albert cant know yet when told just the month because there are too many variables. The second part is critical
  2. How does Albert know Bernard does not know too? They way to think about this is that for Albert to be confident that Bernard does not know, he must have eliminated cases where Bernard would have to know. What are those cases?
  3. Those cases are essentially if Cheryl had told Albert May or June which means Cheryl had said 18 or 19 to Bernard. In which case Bernard could definitely know.(With me?). But since Albert definitely knows(suspension of the belief that everyone lies) it cant be May or June or 18th or 19th, hence these are eliminated.

Days Left: 

May 15, 16, 19

June 17, 18

July 14, 16

August 14, 15 17

  • Bernard says – At first I don’t know when Cheryl’s birthday is, but I know now
  1. Again another assumption here is that all three are really math savvy. So when Albert hints Bernard doesn’t know he has also figured out the above . Now lets assume Cheryl had said 14 to Bernard, in which there was no way Bernard could have known when the birth month is. But since Albert’s hint about Bernard knowing the date is confirmed, Cheryl couldnt have said 14 to Bernard. Hence eliminating July and August 14th.
  2. The dates left are July 16, August 15, 17 . Now here’s the thing, Bernard has figured out the answer from this clue itself! This is the slightly tricky bit –> He knows the date i.e. 15th, 16th or 17th. Doesn’t matter which month for him really now, because they are all unique.


May 15, 16, 19

June 17, 18

July 14, 16

August 14, 15 17

  • Albert: Now I know too
  1. Remember Albert knows the month. For Albert to say this he has deduced the date given the month.  For Albert to know, the month has to be July, because if Cheryl had told him, “August,” then he would still have two possibilities: Aug. 15 and Aug. 17.
  2. Hence Albert also figures out the answer

Which is JULY 16

Here’s the much tougher unsolvable variant, a similar problem called Sum and Product. I wonder if this will break the internet?

Two mathematicians S and P are discussing two unknown integers, both greater than 1. S knows only the sum of the numbers, whereas P knows only their product.:

S: “I see no way you can determine my sum.”

P (after a suitable delay): “That didn’t help me. I still don’t know your sum.”

S (after another delay): “Now I know your product.”

What are the two numbers?

SO link:

Quick interesting questions

  • Why did this particular problem go viral? There are a ton of obscure olympiad problems for lower grades?
  • Why are adults finding it hard to solve this problem?
  • How long did this take you to solve?

Interview engineers like a reverse bloom filter

Hiring is hard. Hiring great engineers is harder. But cleaning up bad engineering work from bad hires is the worst!

If you are an engineering manager like me, its your responsibility to hire engineers and generally set the bar very very high for candidates. The most obvious well known trick is to hire people smarter than you(The whole A’s hire A+’s, B’s hire C’s thing). But many a times, especially in startups or service companies, due to high pressure demands, this bar can go down and there is nothing worse.

There a lot of the times engineers can be false positive -i.e. they come across as brilliant in the interviews. Many a times this is because engineers are extremely well prepared specifically for interviews(having gone through the thousand of resources available online, the data set of available questions,unheard of yet, is bound to get smaller)

So , interviewing has to model a bloom filter in reverse

Background on a bloom filter:

During the process, you are probably involved in a couple of rounds with the interviewee, but in general its your engineers who interview potential candidates. Engineers understand engineering terms better. Hence we should be modelling the process and communicating to the engineer similarly.

Bloom filter.svg
Bloom filter” by David Eppstein – self-made, originally for a talk at WADS 2007. Licensed under Public Domain via Wikimedia Commons.

A Bloom filter is a space-efficient probabilistic data structure, conceived by Burton Howard Bloom in 1970, that is used to test whether an element is a member of a set. False positive matches are possible, but false negatives are not.

The idea is that a query for an item returns either “possibly in set” or “definitely not in set”. Elements can be added to the set, but not removed (though this can be addressed with a “counting” filter). The more elements that are added to the set, the larger the probability of false positives. Plus a bloom filter is a great data structure particularly if you are using strong caching mechanisms. Hence you’d do good getting your engineers to learn a swanky data structure while they interview other candidates.

How does this apply to interviewing:

Applying this to an engineering candidate is interesting. You have to be biased towards false negatives, false positives should not make it. Ala a reverse bloom filter, which could say a candidate should be looked at as  “Great but wont make it” and not “OK should make the cut” or False negatives are possible but false positives aren’t.  Essentially this says, its OK to lose very very good engineers who don’t make the cut(but certainly are great), but its absolutely not ok to hire bad eggs on a false curve. The cost and time spent on training and cleaning up behind these engineers can get exponentially higher than the time spent carefully interviewing candidates and selecting the right one. 

Might be a convoluted way to think about it,  but it’s worked so far for us. 🙂

Comments welcome. Ok maybe instead of a reverse bloom filter I could have said a lossy hash table or a LRUCache or even a direct mapped cache. But they don’t sound as catchy 🙂


16 Things

Andreessen Horowitz

We don’t invest in themes; we invest in special founders with breakthrough ideas. Which means we don’t make investments based on a pre-existing thesis about a category. That said, here are a few of the things we’ve been observing or thinking about; we’re especially grateful to our founders/companies, and the entrepreneurs we meet with everyday, for their insights here…

[For other trends we’ve covered already elsewhere, please see our series on mobile eating the world (with lots of charts!), you bet your SaaS, and government x tech.]

View original post


Engineering management Lessons so far- part 1

Engineering management is hard. Mostly because programmers who turn managers start to treat people like code, and this not so good article on TechCrunch will tell you that is good, but it isn’t. Code is predictable. People are not.

Some key lessons so far
1.) You cannot lead a cavalry if you think you look funny on a horse: Self confidence is key

2.) Respect and leadership are privileges earned hard but lost quickly – Don’t lose it if you can help it, burn out the fire’s as quickly, if you cant.

3.) Ability to manage conflicts is key- data driven is the only way

4.) Every engineer on your team needs to constantly know what to do next

5.) You HAVE TO BE UPDATED On technology/code/processes and continue to be CODING – cant stress this enough, or you are the guy the developer’s say “Hey manager, we are about to finish this module and pull a late night, can you order some pizza’s for us” to.

6.) As tough as it might be, you cannot lower the hire bar – Absolutely zero tolerance, because bad hires come bite you back in the rear.

7.) You can employ carrot or stick method in certain situations – but caveat emptor

Thats what I have so far. Ill be updating this and have some sort of a value list as I experience more of engineering management.

I’ve enjoyed reading this piece and this piece on Engineering management, there are a lot of very valuable key lessons to take from them, so I suggest you read up on those if you are in this black art of engineering management