Although I was more than qualified for a senior Ruby role, I was turned down because they felt I was interested more with Elixir. Have any of you experienced this? I don’t understand why a company would do this, shouldn’t they want engineers that are always looking to improve?
The smart places in my experience yes. I’d say you dodged a bullet. ^.^
Even taking the immutable aspects of elixir into Ruby code would still better it by making things easier to reason and less chance of bugs, they should have jumped on you. Knowing more languages is always better than fewer because each language can teach you something.
Business people can get caught up on results and stop prioritizing their employees’ professional development. I’ve known several CEOs in my life and I can tell you – it gets annoying dealing with 50+ tasks each day for years and years. At certain point they are like “we need X, Y and Z – if you don’t have it, no hard feelings but we don’t want you”.
They are protecting their interests, plain and simlpe. They might need somebody for a long-term project maintenance and development (say, 2-5 years) and when they realize you have more interest in a new language (and its technologies) they think you will abandon them when they need you the most. They are not very far from the truth IMO – I’ve seen plenty of devs (and I am one of them!) who eventually left jobs because they felt the technologies they wanted to work with aren’t allowed in the organization.
Please note that I don’t necessarily agree with either of those approaches. With regards to #1, I fully understand those CEOs but truth be told, it’s part of their job to also invest in their employees’ professional development; being tired or burned out means they have to take a vacation or quit, and not impede the people under them.
As for #2, you can’t really be mad at them. They are trying to serve their interests in the best short-term way possible. You and I agree long-term is the better approach, but this is not an universal truth all the time.
I’m disappointed, not really mad. The Ruby community emerged out of people annoyed with Java. I always felt what made Ruby developers unique was the willingness to try out different techniques to determine what was best for them. Ruby developers are also node developers and often times Scala , clojure, and Elixir developers. The way I feel about this shop is the way I feel about Java shops back in the day not willing to embrace new technologies.
Like @OvermindDL1 said, you dodged a bullet. Don’t get stuck on jobs with backwards people.
As I mentioned – I can see part of their reasoning but it doesn’t work for me (and for you).
Well, I haven’t turned down by a ruby shop because of elixir, but the fact that I am very polyglottic makes it hard to find a job. At least in this area.
An HR guy I was interviewed by told me during this interview, that it looks like I wasn’t able to focus or finish anything. And in the CV I only even mentioned languages needed for the job and that ones we had in university so far.
I heard from co-students about similar problems or comments in interviews.
I wonder if the same happened when people mentioned interest in Node a few years back …
It might be more of a biz thing, it costs money to hire and onboard a developer there is also a risk that a developer might leave during some important client project, so if they felt you are more interested in Elixir than Ruby it might be they felt that the risk of you leaving for an Elixir job would be high.
I could see it. The best developers are always learning but you learn what you are interested in. If they have a ruby shop with ruby clients and ruby projects and a ruby future they are probably looking for somebody who’s excited about ruby things, rather than somebody who’s going to keep wishing they were using Elixir instead.
I feel the pain, believe me. Sometimes they just have to make a business decision. You can’t dictate people’s interests though.
Not that I’m disagreeing with you - but isn’t that the attitude that keeps Java being used for greenfield projects - even when there is something more appropriate around? This type of tunnel vision can lead to a kind of “boiling frog syndrome” that allows the inertia of legacy code and technical debt to continually grow which makes it increasingly difficult for the organization to adapt to business changes.
Developers need to be able to maintain legacy technology because it typically can continue to provide business value without being rewritten in the latest and greatest technology. But developers also need to be aware of current industry developments in order to keep improving practices in those legacy environments and to be informed enough to indicate to the business that a legacy system is costing more than it is worth.
- Developers who can effectively apply contemporary ideas in legacy systems are valuable.
- Developers who can only apply contemporary ideas with contemporary technologies (because it is easier/more convenient to do so) are less valuable.
- Developers with a narrow skill set that matches the organization’s current technological portfolio are typically interchangeable/replaceable but populating your teams with individuals of similar, narrow skill sets compromises the business’s ability to change when necessary.
Being tech people we like to think that tech is very important in reality it rarely is. When there is a need and available resources they will be able to hire the expertise they need.
I also think a lot of this is fear amongst the technical decision makers at some companies. I’ve been in those positions and, depending on what was going on my life at that time, would have made the same call. I’m not defending it by any means because I completely feel that Elixir has made me a much better Ruby dev - but I get it.
I didn’t mean it like that, just that for that particular business it could seem like a socially distracting fit to hire somebody who is passionate about doing something other than what their business does. I don’t know their business, but they do so I could see why they could justify making the decision even if I don’t agree with it.
I am familiar with the argument.
- How are they going to recognize that it is time to change when they only have awareness of local technologies? I guess good consultants can help - but many of them have the interest of their own organization at heart. So by the time it is obvious that change is needed it may already be too late and/or expensive.
- Where do these resources come from when “the business” (or any other “business”) can’t be bothered to foster them? Apparently “the actual business” is so simple that it takes no time to bring new hires up to speed.
I get the whole understanding vs. condoning issue. But it also sheds some light on how the company views developers. Apparently developers don’t solve general technical problems that the organization faces day to day but simply wield some IT skill set that matches up with some current perceived need to a varying degree.
The key thing is technology rarely matters.
It’s a very rare thing outside of very specific sectors. Not hiring specific people does not mean they are not aware of some tech.
Simplest thing is consulting shops. If you all of a sudden decide you need top Elixir expertise you will contract Platformatec.
A good developer should know that “technology rarely matters”. Its general solution approaches and strategies that matter - and knowing what technologies enable them and which ones resist them. Good developers also know to drop the hammer and pick up a wrench when they are surrounded by bolts.
It highly depends on the context. In reality say for a major portion of software market (by $) the only thing that really matters is a strong sales team.
I’ve argued this so many times and sometimes I even managed to convince non-technical people.
The real problem is outlined in a “Matrix: Reloaded” quote: “That’s how it is with people – they don’t care how it works, as long as it works”. Business people tend to be under the impression that if there are no fires and people aren’t running around screaming, then everything is fine and doesn’t need to be touched.
This kind of poor management skills leads to disasters down the line, always. By the time the need to move on is recognized, it’s already too late to do so painlessly or with reasonable expenses.
It seems business people aren’t willing to learn from each other. For a dev like me, this mistake is so blatantly obvious. It sometimes angers me how the busy life of a business person leads to narrow mind and tunnel vision. I guess it’s human nature.
I think that’s the crux here - that they felt you were more interested in (/enthusiastic about) another language. However I would guess that that wasn’t the only reason and maybe there were other (perhaps micro) reasons as well? Maybe your experience was in a different field or the tools you used weren’t quite the same. Sometimes, it’s not about the work experience at all - it’s about the rapport you build in the interview itself.
That’s ok though because it works both ways… and just means that it wasn’t the right job for you and that that job, is still out there
The end comes, and then drums, drums in the deep. I wonder what that means [..] Doom, doom came the drum-beat and the walls shook. [..] There was a rush of hoarse laughter, like the fall of sliding stones into a pit; amid the clamour a deep voice was raised in command. Doom, boom, doom went the drums in the deep.