If you're looking for a backend role, we're also hiring in New York Times Data Engineering--application engineers, data engineers, and database reliability engineers:
I'm an engineer on our CMS team and as Albert mentioned we're currently seeking both back-end and front-end team members. We're not opposed to hiring skilled developers that don't have deep experience the specific language or frameworks we use. There's also always the option of joining the back-end and transitioning over time to a more front-end role. If you're interested, I'm happy to answer any questions or connect you to the hiring manager.
We do have news employees in bureaus around the world but I'm not sure what the the exact policy is for tech employees. I'll see if I can find someone with the answer for you
As someone who has worked on the integration of off the shelf CMS and as well as built in house ones, I question this statement.
There’s a lot of value in building tools that fit the domain and workflow perfectly well. It’s expensive in the short term but in the long term saves a lot of time and money.
It takes a 'team' to provide any sort of professional level of support for an organization of their size. If the one-person "CMS/tech wizard" decides to stop working, or die, or get sick, or take an extra 4 hours to be with their family, the entirety of the NYT operations should just say "oh well, we'll just wait around for a while until we find our next one person to be our tech saviour"?
A word of unsolicited advice: Someone who thinks "I am a Python developer" is generally less useful to a team than someone who thinks "I am a developer who is good at Python."
Not all languages are created equal. While yes a developer with years of experience in python may have lots of transferable skills to other languages, my team arent going to hire someone for a mid level/senior position without a good knowledge of c++
C++ is somewhat of an outlier due to the sheer size of the spec(and getting bigger all the time). Not everyone will use the same subset of features either, which complicates things.
That said, aren't you using C++ as a proxy for other needed skills though? Many Python programmers are not exposed to concepts like vtables, or they do not know how a linker works(or why it is even needed). Heck, many won't have done manual memory allocation or manipulated pointers.
Even though most people won’t use everything, all c++ programmers will need to understand RAII, manual memory management, lifetimes, effects of inheritance and some* undefined behaviour. We’d probably take people with C experience, and maybe Some D or Rust, but really for a mid level C++ job we wouldn’t accept much less than C.
Funny that you mention linkers, as they’re a bit of a minefield. Lots of the behaviour of linkers is platform (and implementation) dependent, I.e. are you building a shared library or an exe on windows or linux, and there are different gotchas for all of them. We wouldn’t expect people to know al of those things, but it definitely helps when it comes up, and you don’t have the same problem (ODR violations come to mibd) in many other languages...
I like your way of putting it, but I think those concepts (RAII etc) are fairly easily learned by a competent developer in any language. Most languages have analogous concepts if you use them long enough.
A shop that says it requires years of experience in a particular language is probably making their own hiring situation more difficult than they need to.
C++ for example is definitely a sharp language that takes some time to adjust to, and experience in C will help.
However: I think any competent programmer with a few years of experience would be able to gain basic proficiency in a month or two and probably daily-level-mastery in 6-12 months.
I say this as someone who had 10+ years in Java and only passive experience in C. I've managed to become mostly proficient in C++14 in about a month of full-time learning. After 10+ years of programming, I can pretty quickly adapt to the C++ way of thinking about things. I don't think I'm alone in this style of learning a language, and many hiring teams seem to agree.
No language is inherently "better" than another. They are each useful for specific cases, and understanding more languages means understanding their contextual strengths and weaknesses.
In most hiring settings this isn't true though. Language-specific skills actually do matter, for all but entry-level positions at massive tech companies. It's not like my 3 years of experience in Ruby is immediately translatable to Java/Python/whatever. Could I get up to speed in those languages in due time? Sure. But if you were on a hiring committee, hiring for a team that works mostly with Java (or whatever) would you rather hire me or the version of me that's had the same amount of experience but with Java?
> It's not like my 3 years of experience in Ruby is immediately translatable to Java/Python/whatever.
It should be.
Picking up language X is very easy for most values of X (more esoteric ones excluded). After you know a few (and the more diverse the set, the less new concepts you'll see), picking up a new one is quick. If it is something like Go, it's a weekend's worth.
Using the language in idiomatic ways and knowing the most useful libraries and frameworks does take more significant ramp-up time. If you are a solo developer, or if the entire team is ramping up at the same time, then it is bad.
But a new, experienced team member, with zero knowledge in the most used language in the team? Sure, why not? They may even bring new skills to an otherwise homogeneous group.
I always let the interviewee pick the language during my interviews. Usually it is something like Javascript or Python. Sometimes it is Bash. I keep waiting for the day someone will offer to do it in Scheme, Haskell, Elixir, Prolog, D, Rust, even Ada. Pseudocode is actually fine too, unless I have a reason to think the individual lacks programming experience.
Whatever you do, DO NOT brand yourself as a X developer, if X is a programming language. I can understand specializations like machine learning. But languages? It's a mere tool, and you need more than one in your toolbox.
> But a new, experienced team member, with zero knowledge in the most used language in the team? Sure, why not?
It really depends on how much time you have to wait for a new hire to ramp up before they are useful. If you need immediate help, then hiring someone who doesn't even have experience with your programming language is a complete non-starter. If, on the other hand, you are hiring for the long term and can afford to pay a ~3-month tax for a good engineer for (hopefully) several years, then you are correct and the ramp-up cost becomes pretty insignificant. But don't make the mistake of thinking that this is an exception to the rule—what languages you know absolutely does matter to any company needing to get work done now.
> Picking up language X is very easy for most values of X
I disagree. If you know Y and you're learning X, it depends much more on the value of Y. If Y is Lisp you will be quite successful at learning any X. If Y is something like C or assembly language, then you will not (it's always easy to spot the C guy who just started using Python etc.)
In my experience it is like learning a spoken language. If you know a language in the same family then learning the new language is relatively easier (e.g, Java -> Scala, Lisp -> F#). I also think the ease of learning a language is proportional to the ratio of expressiveness of the language you are coming from to the expressiveness of the language you are going to (e.g., Lisp to F# might have a much easier time than F# to Lisp).
>Using the language in idiomatic ways and knowing the most useful libraries and frameworks does take more significant ramp-up time.
Yeah. As in years. This stuff also changes all the time so requires perpetual learning.
>But languages? It's a mere tool, and you need more than one in your toolbox.
It's not a mere tool and languages are more than just trivially learned syntax. They are the umbrella under which a panoply of tools, approaches, ideas, priorities and culture aggregate.
Sure, you specialization isn't necessarily always the optimal approach and sure there are benefits to the cross fertilization of ideas across community lines. However, being a jack of all programming languages, master of none probably means you'll suck more than a specialist at a lot of stuff.
Moreover, some ecosystems plain suck and avoidance is the sign of a good programmer. Statistically, you're probably a worse programmer if you've used a lot of PHP and better if you've learned rust/F#.
Language-specific skills actually do matter, for all but entry-level positions at massive tech companies.
Absolutely, which is why I didn't stop at "I am a developer". That "who is good at Python" bit is definitely important.
However, seeing yourself as a "Python developer" rather than "a developer who is good at Python" makes it look like you see every problem as something you'll solve using Python. That's bad. That will put a lot of companies off hiring you (companies that believe in a 'best tool for the job' approach anyway, and those are the ones you probably want to work for).
>However, seeing yourself as a "Python developer" rather than "a developer who is good at Python" makes it look like you see every problem as something you'll solve using Python. That's bad.
If a company didn't hire me because they idiotically interpreted "I am a python developer" to mean "I would try to build a rendering engine in python" then I'd say that's probably a bullet dodged.
I'd interpret it as "I don't build rendering engines but I build other stuff for which python is a good fit", but maybe that's just me being weird.
The trope about great programmers being people who reverse binary trees in their sleep and being able to swap ecosystems at the drop of a hat needs to die. Great programmers specialise.
Being able to interpret around your words does not make your words inherently better.
You aren't honestly trying to sift out clueless prospective employers out by their ability to parse a title, are you?
The advice here is to put focus on ability to write software, and experience using python as a tool to do so, rather than implying that your ability is limited to python.
What parent was trying to explain is that an individual is not defined by a specific subset of his/her experience.
Just as fluency in Spanish does not make me Hispanic, experience in python does not make me a "python developer". That title puts focus in the wrong place.
It depends on whether you're taking the perspective "if someone offered me this job, would I take it?" or "if I applied to this job, would they hire me?".
