Scala interview questions • Hacker News Board

Re: Scala interview questions

#21

Post by pc86 » Wed, Apr 05, 2017, 7:08 PM UTC

RandomOpinion wrote: post #20

pc86 wrote: post #17

Earlier quoted context omitted.

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 f…

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".

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.

Re: Scala interview questions

#22

Post by harveywi » Wed, Apr 05, 2017, 8:11 PM UTC

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.

Re: Scala interview questions

#23

Post by frostirosti » Wed, Apr 05, 2017, 8:21 PM UTC

csneeky wrote: post #10

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.

You're kidding right? How much of your job is implementing hand rolled IO monads? I think it's very telling that you would hire someone who can understand IO monads but not understand the difference between traits and abstract classes.

How are code review with people like that? Where they implement their own logging system rather than using built in tools. That must be truly enlightening. Must be fun to maintain too. Especially when they do not understand or can even use the built in functionality of a language.

I think it's very telling that you think THIS of all things is the issue with interviews.

Re: Scala interview questions

#24

Post by frostirosti » Wed, Apr 05, 2017, 8:23 PM UTC

joneholland wrote: post #11

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.

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"

Re: Scala interview questions

#25

Post by rewrew » Wed, Apr 05, 2017, 9:14 PM UTC

pc86 wrote: post #17

alfalfasprout wrote: post #15

Earlier quoted context omitted.

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 f…

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 f…

You are not kidding! I hire front-end devs and candidates constantly and utterly lie about their HTML/CSS/JavaScript experience (I've had more than one them tell me when we spot it, "Well, it's just HTML and CSS"). We can weed out some via interview questions but for others it's not until we get to our a hands-on coding test (where we watch what they do in real time) that we can spot it. It's extremely frustrating and such a waste of time for us. They are allowed to look things up in our hands-on tests, as we're trying to replicate real-world enviornment, but it still lets us see overall if they can actually implement what we just talked about in our interview (otherwise the questions we asked are useless), and more importantly, if they told the truth about what they just said. The truth has become very important to me in evaluating candidates -- I'd much rather have people say "I don't know" than pretend they know something, and esp. in our fast-paced work environment, we just don't have time for people pretending to know something they don't. How I see it is if you're wiling to lie in an interview then I don't want to work with you. So the two have come together for me, and at least we have this red flag now that I simply will not hire people who lie in any capacity (and a great green flag when people are honest about what they do/don't know).

Re: Scala interview questions

#26

Post by pedrorijo91 » Wed, Apr 05, 2017, 10:40 PM UTC

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/

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.

Re: Scala interview questions

#27

Post by pedrorijo91 » Wed, Apr 05, 2017, 10:41 PM UTC

merb wrote: post #2

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

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!

Re: Scala interview questions

#28

Post by csneeky » Thu, Apr 06, 2017, 2:48 AM UTC

frostirosti wrote: post #23

csneeky wrote: post #10

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.

You're kidding right? How much of your job is implementing hand rolled IO monads? I think it's very telling that you would hire someone who can understand IO monads but not understand the difference between traits and abstract classes. How are code review with people like that? Where they implement their own logging system rather than using built in tools. That must be truly enlightening. Must be fun to maintain too.…

If curious I would have gotten the question with Try and Either wrong (because I forget), and I don't really use Scala Streams so I don't know without looking at the API doc. The others would have been fine for me but all of that is besides the point...

It was also not my point at all that an engineer that knows how to build a construct like an IO monad in Scala, but doesn't understand traits/abstract classes (which would be funny and hard to find I imagine) would be preferable to anyone else...

And furthermore, I agree that we live in a world where teams and projects get hosed by architect astronauts. But that isn't the point either...

The point, my angry friend, is nothing more than the observation that I, with my skill set, would do exactly what I said: Be unable to answer all those correctly in an interview, and in the process I would not have been asked anything that would flesh out many of the other skills I have. Skills relevant to the language in question and, arguably, more empowering to an organization than those listed.