5 ms·

Scala interview questions

61 points by sconxu 10y ago

merb 10y ago
Question two is outdated for Scala 2.12, a trait might be compatible with Java (but doesn't need to)
- pedrorijo91 10y ago
  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!
andr 10y ago
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 10y ago
  > 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.
  - mattnewton 10y ago
    Is this bizarre, or do a lot of systems work with xml, like rendering HTML pages or reading a legacy api? Is this that different a feature than JSX in react? I am not a scala developer but this seems not out of place for a language that powers web servers.
    - heavenlyhash 10y ago
      A lot of systems work with a lot of things. The question is what belongs in the compiler and core language, and why it's taking up time in my compile step -- this latter question being particularly fair game in the Scala ecosystem, with its almost-legendarily slow compile times. A tool to check that my XML is valid: great! Yes, please! Great; but that's not a language's job. Write a tool for it and invoke it in another step in your build process. Call it a linter because that's what it is: a linter is a process that checks other documents for correctness. Type inference for a language and XML grammar checking don't belong in the same process; they just don't. Only sadness and wasted (human, and machine alike) time can come of it.
      - saosebastiao 10y ago
        Compile times aren't really affected by the language/library distinction. Its not like the compiler is slower even if you don't use them. The compiler would be better without them, sure...but I see that as more of a potential bug surface area problem as opposed to compiler performance.
  - dragonwriter 10y ago
    > Scala has the most utterly bizarre priorities. This is from 2011, and in any case represents knowledge of Scala as it is, not Scala's priorities. In 2012, Odersky, discussing Scala's priorities going forward, pointed to XML literals as a language feature to ax for Scala 3, moving XML handling to libraries. https://groups.google.com/forum/m/#!topic/scala-language/PV4q6O1qIh8/discussion https://groups.google.com/forum/m/#!topic/scala-language/PV4...
  - atemerev 10y ago
    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 10y ago
      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.
csneeky 10y ago
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 10y ago
  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 10y ago
    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.
joneholland 10y ago
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.
- mrkgnao 10y ago
  They're still better than the x = x + (y+=(++x)) things I've encountered in school assignments. I've always wondered why knowledge of what ought to be akin to undefined behavior is a good thing, excepting "idioms" like do {...} while ((line = file.read()) != 0) which one no longer understands after a week away from the language robs you of a short-term mental model of the language's quirks and evaluation strategies and what-have-you.
- frostirosti 10y ago
  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"
mrkgnao 10y ago
lazy val x = { println("computing x") 3 } unsafePerformIO, unsafePerformIO everywhere...
harveywi 10y ago
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.
pedrorijo91 10y ago
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.

61 points by sconxu 10y ago

merb 10y ago

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

pedrorijo91 10y ago
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!

andr 10y ago

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 10y ago
> 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.
- mattnewton 10y ago
  Is this bizarre, or do a lot of systems work with xml, like rendering HTML pages or reading a legacy api? Is this that different a feature than JSX in react? I am not a scala developer but this seems not out of place for a language that powers web servers.
  - heavenlyhash 10y ago
    A lot of systems work with a lot of things. The question is what belongs in the compiler and core language, and why it's taking up time in my compile step -- this latter question being particularly fair game in the Scala ecosystem, with its almost-legendarily slow compile times. A tool to check that my XML is valid: great! Yes, please! Great; but that's not a language's job. Write a tool for it and invoke it in another step in your build process. Call it a linter because that's what it is: a linter is a process that checks other documents for correctness. Type inference for a language and XML grammar checking don't belong in the same process; they just don't. Only sadness and wasted (human, and machine alike) time can come of it.
    - saosebastiao 10y ago
      Compile times aren't really affected by the language/library distinction. Its not like the compiler is slower even if you don't use them. The compiler would be better without them, sure...but I see that as more of a potential bug surface area problem as opposed to compiler performance.
- dragonwriter 10y ago
  > Scala has the most utterly bizarre priorities. This is from 2011, and in any case represents knowledge of Scala as it is, not Scala's priorities. In 2012, Odersky, discussing Scala's priorities going forward, pointed to XML literals as a language feature to ax for Scala 3, moving XML handling to libraries. https://groups.google.com/forum/m/#!topic/scala-language/PV4q6O1qIh8/discussion https://groups.google.com/forum/m/#!topic/scala-language/PV4...
- atemerev 10y ago
  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 10y ago
    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.

csneeky 10y ago

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 10y ago
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 10y ago
  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.

joneholland 10y ago

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.

mrkgnao 10y ago
They're still better than the x = x + (y+=(++x)) things I've encountered in school assignments. I've always wondered why knowledge of what ought to be akin to undefined behavior is a good thing, excepting "idioms" like do {...} while ((line = file.read()) != 0) which one no longer understands after a week away from the language robs you of a short-term mental model of the language's quirks and evaluation strategies and what-have-you.
frostirosti 10y ago
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"

mrkgnao 10y ago

lazy val x = { println("computing x") 3 } unsafePerformIO, unsafePerformIO everywhere...

harveywi 10y ago

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.

pedrorijo91 10y ago

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.