Hey @shawngao think the if check at the start isnt required.
if (s == null  s.length() == 0) return 0;
Soumyadeep Chakraborty
@soumyadeep2007
Pursuing Masters in Computer Science  Stony Brook University
Posts made by soumyadeep2007

RE: Java solution, 8 lines, extendPalindrome

Java solution with explanation [O(n) time and O(n) space]  HashSet
Java solution with explanation [O(n) time and O(n) space]  HashSet
Find duplicate by storing nos in a hashset.
To find the missing no we find the sum of the nos and the difference b/w the sum and the sum of the first n natural nos.
The missing no is the duplicate + difference.public class Solution { public int[] findErrorNums(int[] nums) { Set<Integer> set = new HashSet<>(); int repeating = 1; int sum = 0; for(int num : nums) { boolean added = set.add(num); if(!added) { repeating = num; } sum += num; } int error = nums.length * (nums.length + 1) / 2  sum; int[] result = new int[2]; result[0] = repeating; result[1] = repeating + error; return result; } }

Java memoization solution with explanation  O(nlogn) solution
Sort the array, then find the longest chain starting at each array index from left to right. Imp thing is to make sure we call chain for each array index and not just the first one. As it might be the 1st one can have a very big b value.
Suppose we have [1,20],[2,3],[4,5]. If we simply take the chain value starting from the 1st index (chain:[1,20]) we get 1.
But if we take the chain value starting from 2nd index (chain: [2,3],[4,5]) we get 2. Thus there is a need to max over all the possible
max chain values.public class Solution { public int findLongestChain(int[][] pairs) { Arrays.sort(pairs, new Comparator<int[]>() { @Override public int compare(int[] o1, int[] o2) { int cmp = o1[0]  o2[0]; return cmp != 0 ? cmp : o1[1]  o2[1]; } }); int[] memo = new int[pairs.length]; int result = 1; for(int i = 0; i < pairs.length; i++) { result = Math.max(chain(pairs, i, memo), result); } return result; } private int chain(int[][] pairs, int index, int[] memo) { if(memo[index] != 0) { return memo[index]; } int max = 0; for(int i = index + 1; i < pairs.length; i++) { if(pairs[index][1] < pairs[i][0]) { max = Math.max(chain(pairs, i, memo), max); } } memo[index] = max + 1; return memo[index]; } }

RE: Don't return null for functions returning collections/iterables
@derek18 Yep, hell of a book that..

UnsupportedOperationException  a necessary evil?
In the Java world, we often run into an UnsupportedOperationException when we deal with certain class hierarchies. It manifests when an implementation of an interface method (abstract method) does not want to implement that method! This is often outrageous as the client of the super type has no idea that the operation is not supported by one of its subtypes which may cause it to fail unexpectedly  a blatant violation of The Principle of Least Surprise!
interface A { void f(); } class AImpl implements A { void f() { throw new UnsupportedOperationException(); } } class AClient { void doStuff(A a) { a.f(); //if AImpl is passed in here, we will encounter the exception! } }
Why then does the subtype agree (by the implements/extends keyword) to implement the method in the first place? We find this typically in wide interfaces (ones with lots of operations) such as that of Collection where certain operations may not apply to all subtypes. As is stated in the official API doc, certain implementations of Collection (immutable collections) may actually not support Collection.remove() or even Collection.add() for instance (eg. Collections.emptyList() returns such a collection). In such cases, these methods throw this exception.
Is there a way around this? What if we argue that wide interfaces aren't desirable and to do away with them? Given below are some ways:
We could have two different inheritance trees with narrower bases : one for MutableCollection and the other for ImmutableCollection. This would lead to loads of classes/interfaces such as MutableList, ImmutableList, MutableMap, ImmutableMap and so on. Now this is just one dimension : immutability. What if we want to add a dimension : tolerance for nulls?! Going down this road we would end up with even more classes and interfaces! (MutableListWithNull, MutableListWithoutNull, ......) The no of classes/interfaces will increase exponentially with each dimension! That is some nightmare!
Also, what if some client code wants to use a functionality generic to both inheritance trees described above? Say a client simply wants to iterate over a list. Now the client is forced to have two code sections to process separately a MutableList and an ImmutableList > a complete annihilation of polymorphism as now the client must know about subtype details it does not care about! 
We could leave the implementations of nonapplicable methods blank in the subclasses! Great! No exception! Isn't this better? Well its a hell of a lot worse! This is an even worse violation of The Principle of Least Surprise! Here the client would not even be notified that the operation failed!
Therefore, in some cases the supposedly evil UnsupportedOperationException is necessary!


Simple Java solution  sliding window
public class Solution { public double findMaxAverage(int[] nums, int k) { int sum = 0; for(int i = 0; i < k; i++) { sum += nums[i]; } int maxSum = sum; for(int i = 0, j = k; j < nums.length; i++, j++) { sum = sum  nums[i] + nums[j]; maxSum = Math.max(sum, maxSum); } return ((double) maxSum) / ((double) k); } }

Simple Java solution  stack
The idea is simple  Use a stack to mimic a function call stack. Stack top will always yield the currently executing fn.
Also keep track of the currently exec function's start/restart timestamp.public class Solution { public int[] exclusiveTime(int n, List<String> logs) { int[] result = new int[n]; Stack<Integer> stack = new Stack<>(); String[] log0 = logs.get(0).split(":"); stack.push(Integer.parseInt(log0[0])); int currExStartTS = Integer.parseInt(log0[2]); for(int i = 1; i < logs.size(); i++) { String[] logi = logs.get(i).split(":"); int logi_fn = Integer.parseInt(logi[0]); int logi_ts = Integer.parseInt(logi[2]); if(logi[1].equals("start")) { if(!stack.isEmpty()) { //check if there is no currently executing fn int currFn = stack.peek(); result[currFn] += logi_ts  currExStartTS; } currExStartTS = logi_ts; stack.push(logi_fn); } else { int endedFn = stack.pop(); result[endedFn] += logi_ts  currExStartTS + 1; currExStartTS = logi_ts + 1; } } return result; } }

Don't return null for functions returning collections/iterables
Usually when a method returns a collection and the method has no result to return, we have two options:
Return null: This results in breakage of client code if it doesn't check for that null.
public List<Order> getOrders() { //.. } . . List<Order> orders = getOrders(); for(Order order : orders) { //NullPointerException here if getOrders returned null! System.out.println(order); }
So the client will be forced to write:
if(orders != null) { //guard for(Order order : orders) { //NullPointerException here if getOrders returned null! System.out.println(order); } }
Return an empty list: Client code will not break and no need to introduce a guard! Much cleaner code! So the below code will suffice:
List<Order> orders = getOrders(); for(Order order : orders) { System.out.println(order); }
Best way to return an empty list is to return one that is immutable by returning
Collections.emptyList()
from the concerned function.Note: The above example dealt with lists but you can extend this discussion to anything that is a Collection/Iterables.