Ask HN: How to onboard yourself to a new product/industry in a new job?

* Putting in time to learn the product as a user of it before trying to develop for it is time well spent. In my experience it makes it easier to read the code afterwards

* When a codebase is old and you're reading a file where 10 to 20 developers have done a pass of bugfixes on it, it may not immediately be obvious what everything does and why some checks are being done. Going through the history and checking earlier versions of the file sometimes helps me getting the basics of it down

First, meet 1 on 1 with every member of your immediate team. This of course serves as a "get to know you" meet, but your real goal is to get them to explain their work to you. Have them go into as much detail as time allows on whatever they're currently working on. Ask followup questions that start with "why" on everything. Have them show you their part(s) of the product, have them share as many docs as they're willing to (for you to read async later), etc.

Put aside whatever ego you may have, and just get into a beginner's/learning mindset. Ask all the stupid questions.

Then, at the end, ask them who else they're working with from other teams. Put those names on a list, and rinse and repeat with them. This way you'll start local to your role and work your way outward in the company. Eventually you'll find people that are doing nothing particularly relevant to you and you can decide to stop.

If it's a larger company, this is also where you establish your understanding of the org chart and who does what in it, and also makes you known to a ton of folks who may want or need to work with you in the future - which is invaluable in and of itself.

Ive done these rounds at every job and 2 times I left that job immediately after the interviews.

I've approached it by reading and thinking about the company's relationship to it's stakeholders. Understanding and writing mini-essays on the current customers and their pain points, the main competitors and their products, the history of the industry/segment and more.

Information sources include YouTube, podcasts, press releases, news articles from niche sites, research paper summaries and various websites.

Networking of course plays a role, where I've sought out friendly people a few years ahead of me when it comes to industry knowledge. Mostly through existing contacts I'd do this again if I needed to, and would make sure to leverage each new contact to introduce me to further relevant people.

I've asked ChatGPT specifically to detail out how a MBB-consultant would approach the knowledge acquisition challenge, as they are adept at quickly navigating and learning a new field in a short amount of time. This has helped somewhat and suggested I'd sit down a perform a few different types of analyses.

As for rote learning, I've bought into the Anki flashcard system where i study acronyms, enemy materiel NATO designations, specifications and more.

To wrap up, I've studied finance myself and I have a strong feeling that there's a low correlation between financial-academic success and proficiency in marketing in the industry... Best of luck!

Here are my tips:

1. Schedule time to ask questions. Domain experts' time is valuable, and you don't want to be interrupting their other work, so if you can build up a list of questions and schedule a 30 minute period to ask all your questions, that uses their time more effectively, and also gives them the opportunity to take the time to answer the questions you didn't ask. (OP doesn't appear to be a freelancer, but for any freelancers reading this, I don't bill for this time, which helps clients to feel they're getting something worthwhile from it).

2. Ignore "rank". The people on the bottom of the totem pole are often the people who know the most about the domain because they are actually working waist-deep in the domain. There have been cases where I have used my seniority to escalate problems or promote ideas from, say, an intern or junior, that were likely more valuable than the development work I was getting paid for. When you do this, be sure to give credit where it's due--people remember that sort of thing.

3. There comes a point somewhere in the 3-6 month mark at a job, where I start getting a lot of anxiety because I feel like I should understand the domain better than I do. This has never, in my experience, been anyone else's expectation. It's just impostor syndrome.

Much of it will be foreign. Over time, more and more will make sense. It will begin to gel.

Take notes on words and phrases that are unclear. Google them. See who you can ask about help (see the 1:1s strategy).

Repetition is important in learning. Everyone learns differently. I like multi-modal reinforcement. Listen in groups, QA in 1:1s, read books, search Google, try by doing. It all somehow comes together and all of a sudden you're riding the bike without paying attention to your feet and hands.

There are probably old time finance people running the company ir advising it. Find out what they did back in the day and look at things from that point of view.

Anytime I got stuck on a problem for more than a few hours, I asked the greybeard for a quick chat. He was pretty always willing to hear me out, let me break down my understanding, then rebuild all my faulty assumptions. His time was relatively cheap but his knowledge base relatively valuable, so with him I did deep dives.

The smart hacker guy I watched from a distance. Any time I saw him merge some ludicrous Rube Goldberg type commit I’d send him a quick DM, knowing his time was precious. I’d fire off a few quick questions and try to glean as much insight into his critical work before he scurried off to the next apparently invaluable task.

I think approaching the problem this way, leveraging the “implicit theories” embedded in the teammates heads, is the surest and most efficient way to ramp up, besides the obvious advice like RTFM and gloss over the relevant textbooks. Always remember to make yourself useful first. No accomplished engineer will ever turn down a well intentioned and friendly favor! “Team work makes the dream work,” as they say.

Good luck!

Get a ChatGPT4 subscription and ask away. It may hallucinate, but it lets you ask questions and immediately clarify points you don't understand. When you get the basic understanding, check it against a more reputable source (e.g. Investopedia?)

Here's an example question (which I obviously made up):

"Hi! I'm about to get a job in finance but I feel that I don't fully understand some of the important concepts, such as compound interest. Can you explain compound interest to me?"

To speed it up, write an interview script with a set of questions. Use an LLM to make the questions non-leading if you want, but point is to show colleagues who have customer contact your script. If you manage to do the interviews, record them, transcribe them and share them around. You are now a customer advocate who knows the customer's needs and wants.

Don't wait with doing this only after you've met the team, start immediately. Let this be your driving force to meet colleagues. It's useful, offer to share the results, or ask for question ideas to whoever wants to listen to you.

You now have laid the groundwork for your success. Now you can focus on the organisation, the team, the mission, the proposition, etc. Everyone you now meet, talk about how customers want to do A or B but can't, or about their challenges. People will appreciate your insight and you're off to a great start!

Showing an interest is important, learning the lingo is important but it will be a learning curve and it’s important not to expect too much from yourself too soon.

whenever you see a term or concept you don’t understand, WRITE it down. The brain-body connection works well for your memory.

I’m gonna get flak for this, but going out drinking and to the smoking area will give you an inside track to how the company operates.

I used to work in tech at an investment bank. When I first joined I was all starry eyed and eager to learn about the business, even to the point of trying to get a CFA (which some of my colleagues apparently had done).

Fast forward many years, I came to the conclusion that the limited time I had was best spent becoming a better technologist/engineer instead of a halfassed banker/trader/investment professional. Of course it’s still useful to know the basics of the industry and anything specific to your role, but beyond that the returns diminish sharply.

FWIW most of my engineer colleagues that spent all that grueling time and effort to get a CFA no longer work in the finance industry, so it’s arguably all down the toilet unless they ever go back. AFAIK none of them want to

1. No-one’s going to go out of their way to guide you. Esp at smaller companies, the fact that you’ve been hired means you’re joining a time-poor company, and there likely won’t be a formal onboarding process. So...you’ve got to onboard yourself.

2. Adopt a mindset of personal responsibility. This isn’t going to be a passive process, but an active one.

3. Don't meet everyone for the sake of it. The goal isn't to set-up endless meetings and become a burden. Limit yourself to a few, and make the most out of them. Make your ask clear when you ask someone for their time — e.g. 'I'd like context on X and what's been done so far'

4. Get some small wins on the scoreboard. Although your priority is to learn the key skills of the job, you also want to make a great impression during your first 60 days by showing you’ve made an impact. To do that, identify some smaller projects you can knock out to get a few small wins under your belt.

5. Be ‘seen’. Make your presence known. And communicate upwards so people know you’re busy. How? Tell your manager, “Can I send you a list of 5 things I think I need to hit the ground running? I’ll then set up a 1-1 and we could go through that.”

the full essay's here [2] (and plug: the newsletter I write is called Coached. If occasional career strategy is your thing, feel free to check it out)

[1] https://coached.com

[2] https://careersupplement.beehiiv.com/p/cs233-onboarding-hard...

1. find a good text book in the field as narrowly construed as possible, and just browse the table of contents.

This will give you a quick map of the field, and a place to put all the info you gain.

2. Read the management discussion in the 10k of a public version of the company you work at and 2 leading customers, and the transcript from the earnings call.

Fastest way to get up to date on challenges.

I think all the other comments saying "read a lot" and "talk to everyone" are correct first steps, but for me, consuming information has diminishing returns after a short while. After you've reached a point where your brain feels like it's exploding, you should switch your focus to outputting information.

If you're a "write things down" person, then write a synthesized document explaining everything you've learned, and then ask a few trusted coworkers to tear it apart.

If you're a "talk out loud" person, schedule time with coworkers to have a "teachback session" where you give a presentation about everything you've learned. Again, ask them to tear it apart.

It's crucial to build trust with a few coworkers who are willing to critique your output. Get them to rip everything you've created to shreds. Whenever you write or say something that's even slightly off compared to how someone in the industry would say it, make sure you learn about that, and learn how someone in the industry would say it.

This focus on getting the language right - especially the colloquial language of how people actually describe things day-to-day - is important for every role, but I assume it's especially important in marketing, where you need to be able to use the precise language that your customers use.

tl;dr: Read/talk to people at first, but switch to writing/presenting ASAP. Solicit and internalize as much critical feedback as you possibly can.

If you're not, you won't.

Nothing else to it.

1. Immersion. I learn more German in Germany when I visit for a week than I do in months of study. Why? Because I can see it all context. I can guess what a Hauptbahnhof is context, and other words. You start to see the patterns. Work is much the same. Get in there and learn! There is a reason why the first thing every software developer should do is fix a pretty easy bug. It gets them to do so many essential things they will need to do day to day as part of their job.

2. There are no dumb questions. "What is Alpha?" "What are the Greeks?" etc. All VERY valid questions. If in Star Trek parlance if someone says to "Tech, tech the tech." ask some questions. :) (Tech was used by the writers as a stand in to allow them to write the script without looking everything up.)

3. You have time. Nobody expects you to know anything. Ramp up for an industry to basic levels is usually about 6 months.

4. Suffer. Try to learn the concepts. This won't always work, but it'll teach you tons of extra concepts you will need later. Time spent learning is rarely totally wasted. It just may be the knowledge you need to cross a gap later. Also it makes it obvious to the people around you, you are trying, thus you are more likely to get help.

5. Don't be afraid to be stupid. When I used to work with TLAs a wise boss once told me if he didn't know what some word/acronym meant. He'd just ask.

It was amazing how many times nobody in the room could expand it. Despite us all working with it ;)

I've picked up this habit from him. It hasn't hurt me... But it can be a great way to rattle people.

What were some of the reading material and books? What area of fintech?

I went the other way, from finance into non-finance. And from bigco to smallco. It took a solid 6-12 months to start feeling competent. It was worth it. I now have a lot more breadth on the business side, and technical depth from having to read code to learn a bunch of new stacks and end to end integration flows. At the smallco there wasn't much for docs to read, and the ones they had were out of date.

I haven't gone too far out of the way to learn aspects of finance other than through exposure and osmosis. As long as there's someone on the team that really understands it on a deep level, you don't have to be that person to be effective, at least on the frontend (which has been my focus for this client, although I am doing a bit more backend now).

Hasn't stopped me from implementing complicated features as requested and discussed, just asking questions for what's expected, what the data should look like when it's done correctly, etc, but now I do understand it a lot better and I can mostly follow along during deep discussions (some of it still goes over my head though).

That being said, you can pick up books on finance to help you understand things better. For me, I discovered recently (stumbled upon it at a used bookstore, actually), that I should probably pick up textbooks on Quantitative Investment Analysis and Portfolio Management in order to understand those deeper discussions better, but the focus of your startup might be different.