I couldn’t agree more. As a strategy consultant I do have to face new clients on a regular basis. Sometimes the industry / topic overlaps with the previous engagement - often not.

1.) Really, really, really ask those dumb questions in the first week. Everyone will tolerate it and even expect it

2.) Learn the basics of your new domain / industry top-down asap. Meaning: understand for what your company gets paid for, understand the basic process how it gets delivered, understand the strengths / weaknesses of your company. Know who the key customers are and what they really want. It’s often the new guys who are empowered to challenge those high-level topics while everyone else takes it for granted (and often have the wrong idea in mind)

3.) Always ask a question / say something during the first five minutes of a meeting. It just gets harder and harder afterwards. But as soon as you asked you’re in the game

4.) Bring in experience from the past but try to take the extra mile of translating it as much as possible to the new situation (“at my last gig we did... I understand that here we have... however I see further potential in...)

Two to add:

5.) Ask a colleague to give you a dedicated intro session. Not just a random “I show you some stuff on my PC” but a real one. Typically a nice way for the colleague to reflect on their learning as well and/or prepare a public talk :-)

6.) Be aware that almost no one really knows. They are all bluffing, they are all biased. There are exceptions but they are super rare. Even someone 2-4 years in a specific job will get his stuff done but still struggle with some concepts. On Management Level it gets worse as those guys tend to not have the time to digg into it

Can't stress (6) enough. Most people do stuff because that's what they heard first or it's a solution they found for a problem that existed years ago. Having a new perspective and questioning existing norms is healthy. You can add value there more than most of the existing "tribe".

When you do 5.) show them appreciation - buy them a nice meal as they explain things to you - it's a nice thing to do, a small price to pay, assuming it's appropriate

At our company when I was on boarded we had a process called boot camps. Which was basically a week set aside with meetings for each respective team/department to get a high level over view of what they do and how they fit together with the company as a whole. This gave me some good insight on how I fit in as well as open up new dumb questions to follow up with.

Definitely 5 - not only do you learn a lot, but you also learn about different people's learning/teaching styles too. You also pick up on the political landscape, as well as priorities.

Had the best intro in my previous job where the first 2 weeks were dedicated to learning and meeting people. Overwhelming, but good chance to really crack on with it.

These are great! An important caveat for 5) is to make sure you have done the ground work before asking! There is nothing worse than spending valuable 1-1 time with somebody who hasn't even done the React tutorial yet ...

1. Intelligent people ask questions. There is no reason to stop after the first week. Connect the dots in the open and people will understand that you're intelligent. "Why do you <technical detail> here?". "Because of X". "Ah, so it's basically the same as using <technical detail Y>." Just show that you are able to take in the new information.

4) Is excellent; so much of your first few weeks are about perception. You want to be curious, engaged and trying hard AND you want to show it.

May I ask ...

- Were there any times you got a job in a new domain without any experiences (e.g. didn't worked on as a hobby project, didn't do extensive learning the new domain by yourself)?

- Any ideas why those employers chose you for the job? (e.g. purely because of your past experience from the old domain? Any specific qualities they saw in you?)

- How much effort (time?) you would normally spend to learn a new domain before applying for a job? Or if time is difficult, what criteria you use to determine that "Yeah, I'm ready to find a job in this domain"?

I got a job once as a producer for a video game publisher and had pretty much no experience. That first couple of months was basically an intense crash course on video editing (Adobe Premiere and After Effects, had never used them before), localization, qa outsourcing, certification, working with external dev teams, figuring out how dev kit machines worked, evaluating pitches and game demos to see if we should pursue publishing them, etc.

Before that I hadn't done much more than develop and self-publish several Flash games, sometimes collaborating with an artist.

They chose me probably because they were tiny, could tell I was passionate about games, and they expected I would do more game design than I ended up doing (my title was Lead Game Designer... I did some of that, but I was mostly a producer).

And since I thought it was mainly a design role, I didn't hardly anything to prepare. Once I got there, it was like someone volunteered me for the Ice Bucket challenge and didn't tell me before dumping the water on me. Had a lot of fun, though.

Only reason why I'm not doing it now was because I felt like my coding skills were atrophying the whole time I worked there and that thought made me feel pretty uncomfortable. I'd probably be more successful now though if I stuck with it, though.

I have a bit of an unfair advantage in that when people look at my resume now they have no problem believing me when I say I'll ramp up in the new domain. I've professionally used C++, C, C#, Fortran, Java, Javascript, Python, Tcl and multiple stacks so it's not too hard to ramp up on a new technology stack.

I normally ramp up on the company and space for at least 6-8 hours before the interviews start. I take the approach of a customer and try to figure out whether I would buy their product or not. I tend to ask questions about competitive threats and possible pivots that show you grok the market. Sometimes I discover competitors they have never heard of, this sometimes kills the job :-P

If you have the technical chops, you need to show you'll use them productively as soon as you hit the ground.

I'm also both a manager and a developer and can easily plug into multiple roles. I'm happy to roll up my sleeves and program while building the team.

I would also like to know more about getting in. I'm confident I could get up and running in a matter of a few weeks working fulltime on almost anything. I just have a difficult time getting in.

Right now I'd like to go from embedded to data science, machine learning. I think I have some useful skills. But I obviously can't show much in terms of SQL knowledge. I've used python pandas for a few internal tools. I have a solid background in statistics from uni, but I feel like after some years in industry, people don't care about your uni background anymore.

If you work in embedded, start to shift your focus into IoT. Internet-connected systems are the ones producing and storing the data necessary for data science/ML to happen. Experience with the data ingestion layer IoT cloud platforms (AWS IoT, GE Predix, Azure IoT Hub) could help you transition to higher level data analysis roles, especially if you can demonstrate your domain expertise with embedded systems. If you are working with Matlab along w/ Simulink, you should check out ThingSpeak: https://www.mathworks.com/products/thingspeak.html

If you are working deep embedded/legacy products or purely on the hardware side, you may need to grab an ML course/certificate to signal your interest, or just network really hard. Having embedded engineering skills can't hurt though.

Everyone wants to do machine learning; you need to fight for it to get there.

why do u want to leave embedded?

At least in my industry all the application layer gets done in Simulink. I prefer working with code. I find working with Simulink frustrating, you can't diff properly, simple things are hidden in hard to find configurations. It just doesn't work well with how I like to work.

Three other option is going back to firmware, which I did in my previous job, but I don't want to write more firmware drivers. It's just not exciting.

Additionally I'd also like to do more creative work, I find data science sounds very exciting and I could probably bring a lot of software skills to the team

But convincing the industry to go another path is probably harder than switching fields.

Please don't fall for the "sexiest job of the 21st century" adline.The wife works as a sw dev on a speech rec team(one of the popular ones) and she works with P.hD "Data Scientists" which are looking at getting in to dev. If you apply the pareto rule, "Data science" is 80% Cleaning and 20% ML. Hardcore ML research is totally different which requires atleast a MS with ML focus and pedigree plays a huge part. Here is a thought. Why don't you try rewriting stuff you did with Simulink in Python. My man, Downey got you covered https://github.com/AllenDowney/ModSimPy. I would recommend that you start with Think Python before tackling this book.

I went from Astrophysics > Computer Security > Genomics > Alzheimer's research > AI > Medical imaging

The secret? Stop worrying about not being an expert in the area. Be friendly with coworkers and immerse yourself in the new field. You will pick it up, even if the verbage doesn't make sense at first.

While doing this, exercise regularly, since this promotes neural plasticity, which is needed to learn new things.

> I went from Astrophysics > Computer Security > Genomics > Alzheimer's research > AI > Medical imaging

With half of these jumps I'd be worried about Impostor syndrome.

With all of these? About Dunning-Krueger.

I don't believe there is such a thing as a dumb question. If you don't understand something, have the confidence to ask - at any point, not just week 1. That way, you will learn. And more importantly, people, especially those who know you just started in a new domain, will see that you are developing yourself. Who cares, if you upset some delicate flowers that don't like getting asked questions they think are below them.

Thanks for sharing, this is really cool. Can you please share with us what did you have to learn in order to get into Fintech? If you were to assemble a short bullet point list of essential topics to study for the job, how would such list look like?