Learning new Tools for Interviews?

My current instinct is to learn via failure. That is, I have almost all of the above tools on my resume. If someone asks me about them and I'm not able to give a good answer, I will learn that part about the tool so if I'm in the same situation I can answer properly.

I love how creative this is, but I feel like it won't go well 😂

The thing is that interaction where you don't have the right answer is like what, 2 minutes? Patching together 2 minute awkward failures in interviews won't actually teach you the stack. You're probably better off just Googling for something like "Top 10 Spark Interview Questions", going through the first 5 articles, memorizing all the Q&A across those, and stitching together that raw memorization as your "learning".

I think the better approach is to figure out the power law and understand which of those technologies you mentioned is most sought-after. I really doubt they all have equal weight. You can do this by:

1. Going through DE job postings and vetting requirements - Let's say that 90%+ of high-quality DE job postings require Spark, far more than any other technology you're missing. From there, you know you should prioritize seriously learning Spark.
2. Learning from immediate rejections - For opportunities where your resume goes straight into the "No" pile, try to get signal on what you were missing. I have had many recruiters tell me "We can't consider you because you're missing X technology". Figure out what "X" appears the most.

Now let's talk about actually learning the technology. You can try some collection of these things:

1. Integrate It Into Your Current Job - This is by far the highest-quality thing you can do as it's actual production experience. My recommendation here is to try doing it with a new module rather than a migration (it's super hard to get buy-in for migrations). For example, as Meta was transitioning from Java -> Kotlin, the first thing we prioritized was making sure that all new modules were written in Kotlin and after people got comfortable writing new stuff in Kotlin, they went back to old modules and rewrote them. This is much safer as refactoring old code is really dangerous, especially at Big Tech where everything is interconnected. New modules are more isolated, so you can use it as a playground to try out new tech. If you can't come up with a new feature module, maybe you can do it via an internal tool or something? It's all about finding safe playgrounds.
2. Udemy Courses - I think traditional learning like courses and books are great in the early stages of learning a new stack. It's probably enough to get you passing some interviews, especially if they're for junior-level roles or early mid-level.
3. Do Side Projects - If you have the time for a Udemy course or Udacity nanodegree, I feel like you probably have the time to spin up a legit side project. My concern is that I don't know how side project "friendly" data engineer stuff is - I imagine it's way, way lower than front-end stuff like Android.

If you can do #1, you probably don't have to do #2 or #3. Here's some related resources to help with #1:

• "Transition to Program Manager vs. Software Engineer from non developer background"
• "How do I transition from QA into SWE?"

Thanks Alex!

For "Learning from immediate rejections", do you have any specific recommendations for trying to get a signal on what I'm missing from my resume? Companies don't tell you why they're not interviewing you.