Google Code Jam – Swift reading input

Leave a comment

Once of the frustrating things about getting started with Google Coding Competition questions was the lack of examples on how to read the file input in Swift.

Each question requires you to read input from the command line, and then print the answer in a specific format.

I created this cheat sheet to help me read this input in so I could get on with the question. It really comes down to this.

import Foundation

func readInput() -> Int {
    return readLine().flatMap { Int($0) }!

func readInput() -> [Int] {
    return readLine().flatMap { $0.split(separator: " ").compactMap { Int($0)} }!

func readInput() -> (Int, Int) {
    let inputs = readInput() as [Int]
    return (inputs[0], inputs[1])

func readInput() -> Double {
    return readLine().flatMap { Double($0) }!

func readInput() -> [Double] {
    return readLine().flatMap { $0.split(separator: " ").compactMap { Double($0)} }!

func readInput() -> (Double, Double) {
    let inputs = readInput() as [Double]
    return (inputs[0], inputs[1])

func readInput() -> String {
    return readLine()!

func readInput() -> [String] {
    let str = readLine()!
    return str.components(separatedBy: " ")

var t: Int = readInput()

for i in 1..<t + 1 {
    let nm: (Int, Int) = readInput()
    print("Case #\(i): \(nm.0) \(nm.1)")

Here is what my solution looks like to the Retype question of Google 2020.

import Foundation

func readInput() -> Int {
    return readLine().flatMap { Int($0) }!

func readInput() -> [Int] {
    return readLine().flatMap { $0.split(separator: " ").compactMap { Int($0)} }!

func readInput() -> (Int, Int, Int) {
    let inputs = readInput() as [Int]
    return (inputs[0], inputs[1], inputs[2])

let restartTime = 1

func worstCase(_ N: Int, _ K: Int, _ S: Int) -> Int {
    let firstLevels = K - 1
    return firstLevels + N + restartTime

func possibleCase(_ N: Int, _ K: Int, _ S: Int) -> Int {
    let firstLevels = K - 1 // 4
    let backward = K - S // 3
    let forward = N - S
    return firstLevels + backward + forward + restartTime

func bestCase(_ N: Int, _ K: Int, _ S: Int) -> Int {
    return min(worstCase(N, K, S), possibleCase(N, K, S))

var t: Int = readInput()

for i in 1..<t + 1 {
    let nks: (Int, Int, Int) = readInput()
    print("Case #\(i): \(bestCase(nks.0, nks.1, nks.2))")

Hope this helps. Good luck!

How to add IntelliJ Google Style Guide to IntelliJ


For some reason intelliJ doesn’t let you import code style guides.
Like the Java one I wanted to use from Google.

To import the style guide (intellij-java-google-style.xml) after cloning the repository, to this.

> cd ~/Library/Preferences/IntelliJIdeaXX
> mkdir codestyles
> cp /intellij-java-google-style.xml .

Fire up intelliJ, goto preferences, search for Coding Style, and you should see Google Coding style there.

Screen Shot 2015-08-07 at 2.19.55 PM

Links that help

Copy with care


I understand the desire to copy others. I do it all the time. I read an article about Facebook having no QA department, or see first hand how Spotify delivers projects with no Project Managers, and I can’t help but wonder how if they can do it, why can’t we do it here?

There’s just one problem. Copying others is never that simple.

When we see or admire what one company is doing, we are only seeing it through the lens of the end result. And not the underlying foundations that were setup to get them there.

Facebook can get away with not having a QA department because of the huge level of accountability they place on their engineers. Not to mention the insane level of talent.

Spotify doesn’t have formal Project Managers. But it empowers, and gives a level of autonomy and independence to it’s teams, so that teams are inspired to manage themselves.

For fun, this is the conversation I imagine trying to have with the Oil and Gas executive back home.

“OK. For next year we are going to try something new. No annual budgets. When Toronto asks us how much we are plan on spending, we will simply say we are going to spend whatever the cost is for us to work here this year. Our burn. That’s our budget. And in exchange for that they will empower us to do whatever it takes to meet the goals we have jointly agreed upon and laid out before us.”

Needless to say this wouldn’t fly.

But that’s my point. It wouldn’t fly because most companies won’t give the trust and accountability necessary to get the level of commitment and passion they see and read about in others. For their employees it will always be a job.

So am I saying we should give up, stop looking to others to inspiration, and just accept that we work for companies that will never give us the levels of autonomy, accountability, and independence we crave.

Hell no. Just remember. Not everyone wants this level of accountability. For many people work IS just a job. And trust is something that needs to be earned.

So keep reading. Keep studying. And keep looking to others. Just understand. What works at Apple, or Google, won’t necessarily work out of the gate at yours. Don’t get discouraged, keep trying to make where you work a better place, because at the end of the day, what other choice is there.

Joining Spotify


Well, after a whirlwind summer, I can proudly announce I have joined Spotify as an Agile Coach here in Stockholm Sweden. I just completed my first week, and before entering bootcamp I wanted to share some thoughts, observations, and comments from week one.

Surface observations

Spotify, for those of you who don’t know, is a music streaming company founded in 2006 which today has about 40M active users and 10M paying customers.

The best way to think about what they do is to imagine having access to all of iTunes for free. You don’t download the songs. They are streamed to you in real time on whatever device you happen to be listening. Then for $10/month you can get rid of the occasional add – this is called the premium service. Spotify competes with Google and Apple in the music service industry.

Being a music tech company Spotify has some pretty incredible engineering talent. They have music players, iOS/Android clients, embedded hardware in speaker systems, not to mention some enormous scaling issues for when it comes to streaming music to people anywhere, anytime around the world. Very strong engineering.

They are also the most mature Agile shop I have ever had the chance of working with. They have been innovating in the Agile space for some time. Most of their challenges are organizational. Like how do we scale this thing.

For a good video on Agile at Spotify watch this.


This being Sweden, there is a strong culture of building consensus (similar to Japan). But different also in that there very little formal hierarchy. Spotify stress autonomy, and empowerment at a level I have never seen before in a company of it’s size. Every team here truly is a startup and empowered (and expected) to make their own decisions and follow through.

So overall, a very high-level of self awareness, a great deal of maturity, but an understanding that they haven’t got it all figured out (despite the number of daily tours and requests they give to other companies visiting the office, and asking them how they do it). They answer of course is there is no one way – this just happens to be the Spotify way.

Great challenges

Working here is also like having a front row seat to one of the greatest battles our industry is going to see – who is going to dominate music. Going up against the likes of Google and Apple is no small thing. And Spotify is well aware of the challenges they face.

Organizational scaling, reduced friction, iterating fast, and discovering the future before others have real meaning here. There are going to be some real challenges. And I feel very fortunate to be a part of that.

Coming soon

For my friends and family back in Canada stay tuned. Spotify is coming! There were some regulations from the Canadian government that needed to be sorted out before Spotify could launch, that that being complete Spotify should show up sometime I hope this year.

So stay tuned. Sign up. And listen to the music.

Cheers – Jonathan


CEO Daniel EK Charlie Rose Interview

Personal blog of family life in Sweden

Why you may find your software lacking

1 Comment

On my drive to work this morning I was listening to the excellent Pragmatic Podcast interview with Miles Forrest interviewing Uncle Bob when Miles asked Bob:

Why is it that sites like Facebook can support so many features and can be so easy to use and yet the vast majority of software systems are so ridiculously complicated and can only support a few thousand concurrent users.

“This is a very good question.” chuckled Uncle Bob.

Uncle Bob went on to explain that when you bring the people building the software closer to the people needing it good things tend to happen. Basically, agile.

And while I wholeheartedly agree with Uncle Bob’s answer, I have a few other ideas why companies like Facebook, Google, and Amazon get software right while the vast majority of us (companies) seem to get it wrong.

1. Most companies don’t live and die by their software.

For the vast majority of companies out there software is a necessary evil.

Given the choice most would rather buy their software then have to build it themselves. This attitude and lack of software expertise means most companies don’t put their heart and souls into the quality of their software and system the way say Google would.

Because these companies don’t see their software as a competitive advantage, they treat it like a deprecating asset, and let it decay over time.

2. Too many rely on QA departments.

Did you know every engineer at Facebook supports 1.2M (that’s million) users on average and they do it all without a formal QA department?

They don’t wait for someone from QA to submit a bug. Every engineer takes direct responsibility for the code they produce and works closely with operations to ensure that what they ship works, and they to support it quickly when things go wrong.

Amazon does something similar. They call it the two pizza rule.

I am not saying most companies shouldn’t have QA departments (it’s probably a good idea for the vast majority of them to be there). What I am saying is that until they start thinking about how to write software such that they aren’t needed in the first place, they are going to continue to build lousy software.

3. Too many ship their org charts.

I once worked at a start-up that had no less then six segmented, vertically sliced silos of teams each responsible for a different portion of their application. Six teams for one product.

Shipping your org chart is natural for most companies. It means you don’t have to coordinate and talk to others. You are the master of your own little silo. And your bonus certainly isn’t contingent on someone else meeting their goals.

Microsoft is currently falling prey to this. As Ray Ozzie recently pointed out in his farewell address to the company, Microsoft runs the risk of being left behind unless they can get their act together and start shipping integrated products beyond the PC. The have to stop shipping their org chart.

4. Most don’t see the value of software talent.

I know this sounds obvious but the quality of your product is directly proportional to the talent of the people you have building it. This cliche is compounded x10 when it comes to software.

Contrary to popular belief software is more then just typing.

You don’t have to explain this to companies like Microsoft, Google, and Facebook. They are currently locked in a waging war for talent. Anyone doubting the impact a single developer can have should ask Google where GMail, Googletalk, and Googlenews came from.

Google Making Extraordinary Counteroffers To Stop Flow Of Employees To Facebook

So that next time someone asks you how Google can organize the worlds data, and your company can’t seem to push a single release of their software live, check the size of your companies QA department, see if your company is shipping their org chart, and ask yourself if you truly live and die by the quality of your software.

%d bloggers like this: