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.
Scala interview questions
11–20 of 28 posts
Re: Scala interview questions
#12Earlier quoted context omitted.
> 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 t…
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!
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.
Re: Scala interview questions
#13 lazy val x = {
println("computing x")
3
}
Re: Scala interview questions
#14These are terrible. Not because they don't test knowledge of scala, but because language trivia is a terrible way to identify a quality candidate.
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)
Re: Scala interview questions
#15I 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.
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.
Re: Scala interview questions
#16I 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.
I can do both, but I also think that most of those questions are fairly relevant. I'd probably spend some time asking the applicant to translate between a map/flatMap to a for-comprehension block, and walk through their "monadic intuition".
But remember, Scala can be written in many ways. Some of us write Scala like Haskell-lite, and others write it like Java with less cruft.
Re: Scala interview questions
#17I 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.
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 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.
Re: Scala interview questions
#18I 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.
These questions don't seem all that unreasonable to me in and of themselves. I've barely used Scala and could answer a few of them. Several of them are prominent questions I immediately had the first time I read Scala code (e.g., the difference between classes and objects). I was able to guess at a few others from my Haskell knowledge. I have no doubt I'd encounter all the questions if I actually used Scala non-trivially.
With that said, I'm not sure if these questions are actually useful:
(1) They're pretty basic. Any good programmer could get up to speed with all these aspects of Scala in a week, possibly less. So you're not gaining anything by filtering candidates based on whether they already know this. In fact, you're wasting valuable interview time asking very low-value questions.
(2) If you really do need a Scala expert, these questions can't identify such a person.
Re: Scala interview questions
#19I 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.
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…
What is the difference between having people complete a project that's especially crafted to include "a nice number of data structures" that the candidate should be prepared to be grilled about -- and then just asking the question up front?
It seems to me that you'd at least have to forego most of the grilling bit - explaining why I made the design choice of using a list instead of a set (or the other way around), and what the tradeoffs and what-ifs are is just a roundabout way of asking "what is the difference between a set and list?" -- and if that's what you really want to know, skip the project and just ask that.
Re: Scala interview questions
#20Earlier 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…
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".