Re: Advice on Suggesting Scala to a Java Company?
Oliver Ruebenacker <[email protected]>
| Newsgroups | gmane.comp.lang.scala |
|---|---|
| Message-ID | <CAA=X4OA5fDkCjn67tSDQ0NzF0c11cHUYymgm_SbJs18j=+nUXg@mail.gmail.com> |
Hello,
It is not so much about tact, but about strategy.
Hiring as I know it (software engineer in Boston area) consists typically
of three steps: (1) talk with recruiter (2) talk with hiring manager (3)
interview with hiring manager and assorted team members.
The recruiter is typically a not-quite-so-technical person who will
verify you fulfill the requirements, that you know what the job is about
and that you are motivated to do what you need to do.
The hiring manager is the right person to ask what they are about and why
they use the tools they use. But be very cautious: they want to know
whether you fit in. if you come across as having doubts about their tools,
they may very easily take this as an indication that you would not be happy
on that job.
While it often happens that a job description does not match the actual
job, in general, you should assume it does (and if it does not, I as a
candidate would consider that a red flag about how well that employer is
managed). So if you read in the job ad that they are looking for some one
to do X, Y and Z, you better be prepared that they really want you to do X,
Y and Z. It is possible they will change, and it is possible that they
won't.
In general, it is not so easy to argue that tools are somehow outdated
when they are under active development. To make a convincing argument why Y
is better than X, you would have to have detailed knowledge of both X and
Y. It is not enough to say, Y implements some neat ideas.
Best, Oliver
On Tue, Feb 24, 2015 at 12:37 AM, Clayton Wohl <[email protected]>
wrote:
> I am interviewing for several developer positions that are using more
> traditional Java development stacks including Java 6, Spring Beans, Spring
> MVC, Tomcat, Hibernate, etc. In 2015, doing new projects confined to these
> older frameworks seems less productive, I'd be less excited about it, and
> it might not be the best idea. There are other companies already using
> better tool chains, but these jobs have other desirable qualities, and it's
> worth asking how flexible they are on this issue.
>
> Can anyone offer advice for tactfully suggesting the possibility of Scala
> and associated Typesafe technologies such as Akka, Spray, and possibly
> Slick?
>
> Some employers may have already made their tool chain decisions and not be
> interested in other ideas and that is perfectly fine. But other employers
> may be open to suggestions and might agree with some benefits and this is a
> reasonable time to ask.
>
> To another programmer I would say the benefits of Scala are that it's a
> higher level, more elegant tool relative to base Java that allows
> developers to implement logic with less code that is more provably correct
> at a compiler level and lets you use more advanced frameworks. The
> advantage of Akka is easy to articulate. It's a concurrency framework
> centered around two ideas: non-blocking asynchronous concurrency and
> immutable message passing concurrency instead of shared state concurrency.
> And while you can do those without Akka, Akka provides a cleaner
> standardized framework for that style of programming. I can articulate one
> benefit of Slick over Hibernate: rather than express queries and data
> operations in untyped text strings (hsql), you use a compiler checked
> syntax. Beyond that, Slick looks much better than Hibernate beyond that,
> but I can not articulate further specific reasons (I've read the
> presentation slides of course)
>
> Can anyone add any other high level succinct advantages of Scala and
> associated technologies over Java/Spring/Hibernate?
>
> BTW, I am sure there are languages and tools other than Scala that are as
> good or even better, and while I'd be happy to join teams using those, I
> don't feel experienced enough in other technologies to champion them.
>
> --
> You received this message because you are subscribed to the Google Groups
> "scala-language" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> For more options, visit https://groups.google.com/d/optout.
>
--
Oliver Ruebenacker
Solutions Architect at Altisource Labs <http://www.altisourcelabs.com/>
Be always grateful, but never satisfied.
--
You received this message because you are subscribed to the Google Groups "scala-language" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
For more options, visit https://groups.google.com/d/optout.