Stock performance app
Whenever I see a module named "utility", it always spells danger. It will almost always suffer bloat because one is easily tempted to put everything that's uncategorized into it and will be forgotten. Consider splitting it off while still early. It appears one is a string formatter, the other a console helper. Split them by that instead, much more meaningful.

Also, function names and variables occupy the same namespace. Defining a variable and assigning a named function is overkill. I prefer a just a function declaration over a function expression due to debugability because the names will appear in the stack trace.



var removeLeadingZero = function removeLeadingZero (strNumber) {
    if (strNumber.charAt(0) === '0') {
        return strNumber.substr(1);
    }else{
        return strNumber;
    }
};


Consider trimming the string prior to checking if the leading character is 0. A leading space could throw this function off. Additionally, this can be shortened to:

function removeLeadingZero(string){
  return string.charAt(0) === '0' ? string.trim().substr(1) 
                                  : string;
}




return ((endingPrice - startingPrice) / startingPrice) * 100;


Beware of JavaScript's precision when it comes to numbers. While this works for small applications or where precision isn't really important, it may throw you off when dealing with more complex calculations. You have been warned. 0.1 + 0.2 !== 0.3 in JS :D



var getUri = function getUri (stockObj) {

    return 'http://query.yahooapis.com/v1/public/yql?q=select%20*%20from%20yahoo'
        + '.finance.historicaldata%20where%20symbol%20%3D%20%22' 
        + stockObj.ticker 
        + '%22%20and%20startDate%20%3D%20%22' 
        + stockObj.startDate
        + '%22%20and%20endDate%20%3D%20%22' 
        + stockObj.endDate 
        + '%22&amp;format=json&amp;env=store%3A%2F%2Fdatatables.org%2Falltableswithkeys';
};


Since you said you used jQuery, consider using $.param to build the query portion of your url. It will do the proper escaping for you.



getStockData doesn't look complete, but if you want to be functional and all that, the function must return something. $.getJSON returns a Promise-like object which you can listen to for resolution/rejection. You can also parse and return in a resolve handler to do additional logic before handing it off to the caller. You can use this to restructure the data, do additional computations etc.

var getStockData = function getStockData (stockObj) {

    return $.getJSON(getUri(stockObj)).then(function (priceData) {

        var startDate = utility.formatForConsole(stockObj.startDate);
        var endDate = utility.formatForConsole(stockObj.endDate);
        var pricesArray = priceData.query.results.quote;
        var startingPrice = pricesArray[pricesArray.length - 1].Adj_Close;
        var endingPrice = pricesArray[0].Adj_Close;
        var percentChange = utility.getPercentChange(startingPrice, endingPrice);

       // Return all the needed data
       return {
         startDate: startDate,
         endDate: endDate,
         startingPrice: startingPrice,
         endingPrice: endingPrice,
         percentChange: percentChange
       };

    });
};

// Usage
yahooFinance.getStockData(stock).then(function(results){
  console.log(results.startDate);
});


A good practice is to push off anything UI-related nearer to the caller instead of anywhere in the API (unless the API is for rendering). Most of the time, your API will be just sending/grabbing/computing data and it's good that way. It makes it easy to test with lesser things to stub/mock.

Additionally, it's usually the caller that's nearer the UI. This is more apparent in frameworks like Angular, where API consumers reside in the controller, the last level of JS before the templates. API gets called in the controller, therefore the results should also end up in the controller.