What do employers look for when hiring junior scala devs?

I had an interview where I implemented a merge sort algorithm in the laziest way possible (I had a "merge" method and a "mergeSort" method and the "merge" method just returned "(list1 ++ list2).sorted"). After that my interviewer asked me what I would like to work on and I said "the lambda architecture with Scala Streaming and Spark".

Right now my goal is to take apart (this codebase)[https://github.com/miguno/kafka-storm-starter]. I don't know Kafka, Spark, or Storm (beyond like what they tell you on YouTube/Wikipedia). I've run into this problem before - eating, taking apart, and building on a code base that I know nothing about. I started by reading the output of the test cases and the output of running it. I think maybe next I'll do the Kafka example in the Kafka docs and then one little spark streaming tutorial and one little spark tutorial. Then I'll read http://www.michael-noll.com/blog/2014/05/27/kafka-storm-integration-example-tutorial/ and then I'll insert a bunch of break points and stack traces into kafka-storm-starter to get an idea of the flow of the logic. Once I have all that down I think I can start taking apart and re-using the project.

How do you eat an elephant like https://github.com/miguno/kafka-storm-starter if you didn't know anything other than the language it was written in?

Back to the original topic, if I had completely reverse engineered a few lambda architecture examples but couldn't implement a merge sort, a lot of companies would have stopped at the pathetic merge sort attempt. To tell you the truth, the only reason I could do it between five and ten minutes is because I had an IDE to look up the ++ function and I could check the Wikipedia page for merge sort and also I was allowed to use my library for print debugging. Without those things my chances of implementing something that I haven't seen in four years within a short period of time is pretty slim.

/r/scala Thread Parent