
Scala interview questions - sconxu
http://pedrorijo.com/blog/scala-interview-questions/
======
csneeky
I think it is very telling about the state of interviews in the tech world
when:

1\. I can NOT off the cuff answer those all correctly (at least not without a
little Googling).

2\. I can, largely off the cuff, implement an IO monad in Scala using higher-
kinded types and compose instances of them in a hand rolled non-blocking
server.

~~~
alfalfasprout
Rant Follows:

The state of interviews in tech is, for the most part, abysmal. You either end
up with language trivia which tells you nothing about somebody's ability to
reason about good solutions to problems _or_ you end up with some contrived
white-board problems that simply show you the candidate spent a decent amount
of time on leetcode/careercup/etc and nothing about their coding style, design
choices, etc.

I've found that the best compromise is a two layered approach. Offer a
straightforward collaborative coding question or hackerrank test to weed out
anyone that's clearly incapable of writing code. Then have them complete a
short project that you discuss with them at the onsite interview. Make sure
the project requires a nice number of data structures, etc. You can really
grill them about design choices, tradeoffs, what-ifs, etc. In my experience,
it becomes immediately obvious if they know what they're talking about. Sure,
it's extra work for a candidate. But in my experience anyone that actually
wants to work there seems to prefer it over fast-paced whiteboarding.

I remember two interview experiences at "big 4" tech companies where I was
given two fairly involved algorithmic problems and only 30 minutes where I
proceeded to write as fast as I could and finish with only minutes to spare,
despite knowing exactly what to do. Then I was grilled about SFINAE in C++.
The whole experience left a very sour taste in my mouth, despite the nice comp
they offered.

~~~
pc86
I help out with interviews at my employer and unfortunately we get a _lot_ of
applicants who just can't code. I'm tired of hedging around the topic, so I'll
come out and say it bluntly. We get people who say they are developers and are
outright lying. We're not looking for computer scientists, or engineers, or
anything of the sort. We're looking for people who can program and won't lie
about their skills right to our face.

When you have your 10th interview with someone applying for a senior front-end
job and they can't tell you how many columns are in Bootstrap, when Bootstrap
is on their resume and they made a point to bring it up in the interview, it
makes you question humanity. Unfortunately this is why you end up with
questions like "What is the difference between `unapply` and `apply`?" or "How
many columns are there in the Bootstrap grid?"

And unfortunately, especially in my geographic area, the majority of work is
done as an employee or a consultant under an NDA. Nobody is bringing a GitHub
profile with a solid green commit graph, nobody is coming with 45k rep on SO,
and nobody is coming with years of blogging content we can look at. That's not
necessarily a problem, especially if you've ever been in the same room as
someone who is _very_ proud of how many SO points they have, but it certainly
complicates interviewing.

So when you have a combination of (A) people who lie through their teeth to
get a job they are in no way qualified for; and (B) people with no public
technical profile to speak of, you end up with interviews full of trivia to
make sure they have a pulse and contrived whiteboard coding to make sure they
can understand the fundamentals. This is doubly hard if you're trying to
respect people's time and limit interviews to a brief phone screen + a
60-minute onsite interview. Some of the suggestions I've seen here about take-
home projects, consulting work, coming into the office for 2 paid weeks, or a
3-day long interview bonanza, are insulting.

~~~
RandomOpinion
I'll take the take-home project. Though I communicate fine otherwise, I
stutter miserably when an interviewer is staring at me while I'm trying to
whiteboard.

Be a little flexible; not everyone finds the same things "insulting".

~~~
pc86
I've done take-home projects as well, and I don't have a problem with them,
but I do understand why someone who may be looking for a 9-5 may not want to
spend their evening(s) or weekend doing a packet of stuff for an interview. I
don't want to exclude those people from being able to apply and be successful.

------
andr
Related: The levels of Scala knowledge, according to Martin Odersky[1]

[1] [http://www.scala-lang.org/old/node/8610](http://www.scala-
lang.org/old/node/8610)

~~~
heavenlyhash

      > Level A2: Intermediate application programmer
      > [...]
      > - XML literals
    

nope nope nope nope

I'm sorry; I really want to like novel languages, strongly typed language,
portable languages, and a bunch of other boxes that scala _does_ check. But
stuff like this... what?

This may be my most reddit-worthy comment in the history of Hacker News, but
sometimes you see a spade, and you just have to call it a spade. Scala has the
most utterly bizarre priorities.

~~~
atemerev
XML literals are now deprecated.

Which is too bad, in my opinion, as HTML is mostly XML, too, and they are
immensely useful for HTML templates in Scala.js environment (like React's JSX
on steroids). Who'd have guessed.

I can only hope that thanks to the amazing work of Eugene Burmako, we'll have
SQL literals, JSON literals, and whatever else, all properly typed, of course.
Now _that_ would be something!

~~~
saosebastiao
This is my perspective as well. These things probably shouldn't exist at the
language level, but with some thoughtful design, you don't need DSL grammar
and type checking in the language. You still can have it in libraries or
compiler plugins. The world would be better off, not worse off, having strong
static reasoning and compiler enforced safety with the various DSLs we use on
a daily basis: SQL, XML, Json, Protobuf, Regexp, etc., all the way down to
things like Drools Rules, Datalog, Graphviz, Yacc.

------
mrkgnao

      lazy val x = {
        println("computing x")
        3
      }
    

unsafePerformIO, unsafePerformIO everywhere...

------
joneholland
These are terrible. Not because they don't test knowledge of scala, but
because language trivia is a terrible way to identify a quality candidate.

~~~
frostirosti
This is the real answer! You can understand the abstract idea and not know the
trivia. If the person doesn't know scala, then they won't know these. Find
something they do know and expand on that or relate it to the scala and then
ask "So why would you use this"

------
pedrorijo91
Original author here.

this post was never a "memorize this and you will know scala" statement, or
that if you know those answers you will get a scala job. I simply found those
questions a while ago and decided to provide answers by myself as an exercise.
I do believe some answers may not be completely right (even completely wrong),
and others may be a starter for a nice and productive discussion.

Also, knowing the answer to these questions doesn't make someone a good/better
developer. These are just some small islands on the (scala) software developer
knowledge!

In my opinion these are somehow basic concepts (that will only be valuable
when applicable on 'real life' code), and there is a lot more to explore,
specially about the type system. To know more about the type system have a
look at this awesome article I found: [http://ktoso.github.io/scala-types-of-
types/](http://ktoso.github.io/scala-types-of-types/)

Unfortunately, these are questions often done in several scala-related job
interviews (I had my share. Coincidence or not, I never accepted an offer from
a company which did that kind of questions) :(

Feel free to provide feedback or discuss some topics.

------
harveywi
Those are generally pretty easy. Now ask me to recite all of the rules of
implicit resolution, and I will be stumped. That is probably the only part of
the language, other than delimited continuations, that I do not need to know
for day to day things.

------
merb
Question two is outdated for Scala 2.12, a trait might be compatible with Java
(but doesn't need to)

~~~
pedrorijo91
I didn't even remembered that detail. I read about it when scala 2.12 was out,
but unfortunately I still couldn't migrate any app to scala 2.12...

Thanks!

