u/Key-Session1020

For anyone in IB, ER, S&T, corporate banking, or capital markets — what’s something you learned only after starting the job?

Could be about recruiting, interviews, hours, comp, picking a firm, exits, or just how the job actually works compared to what you expected.

I’m especially interested in things that aren’t really talked about during recruiting.

For example, was there a skill you wish you had worked on earlier? Or something you spent way too much time preparing for that ended up barely mattering?

And for people a few years into their careers, is there anything you would have done differently?

Curious to hear the honest answers, especially from people who have been on both sides of recruiting.

Ma business a clean nde ndi awo umakhala kusaka ma potential customers. Dzuwa kutuluka mpaka kulowa, but za illegal nde fast cash, zimangovuta kuti uzigona ndi diso limozi losegula but atleast the bills get paid.

Komaso mwina vuto ndi loti I am a good guy and anandilera bho

I've been building a visual R pipeline builder (drag nodes on a canvas → compiles to a real .R script → runs it → reads the JSON back). 52 node types now. Early on, adding a node meant Claude touching five files: the param form, the validator, the schema propagation, the codegen, the UI palette. It'd nail four and quietly forget the fifth, and I'd find out at runtime.

Fix was boring: collapse all five into one typed definition per node.

const groupBy: NodeDefinition = {

type: "group_by",

inputs: [{ name: "in", type: "dataframe" }],

outputs: [{ name: "out", type: "dataframe" }],

paramsSchema: z.object({ columns: z.array(z.string()).min(1) }),

paramsUI: [{ name: "columns", ui: { kind: "columns", fromPort: "in" } }],

validate(ctx) { /* warn on columns not in upstream schema */ },

inferSchema(ctx) { /* what flows downstream */ },

generate(ctx) { /* the R this emits */ },

};

One object drives Zod validation, the form UI, the column dropdowns, schema propagation through the DAG, and code generation. "Add a node" went from a 5-file diff to a 1-file diff. Claude stopped getting it wrong, because there was no longer a fifth place to forget.

Why I think this is an MCP lesson, not a React one:

A badly-shaped MCP server is the same failure. If your tool schema says one thing, your handler validates another, and your description implies a third, the model will confidently produce input that passes your schema and still means nothing. It isn't hallucinating — it's reading three sources of truth and picking one.

The pattern that fixes both:

- One definition, many consumers. Schema, validation, docs, and execution derived from the same object — never hand-maintained in parallel.

- Parse, then use. My codegen reads zodSchema.parse(params).data, never the raw input, so defaults are applied exactly once, in one place. Same rule for a tool handler.

- The model never invents names. In my compiler, node code reads ctx.inputs / ctx.outputs — it never constructs an R variable name. The compiler owns all naming. That single rule is what makes branching and multi-input graphs collision-free. The MCP equivalent: hand back IDs/handles, don't ask the model to build paths or keys.

- Feed the schema back. Column dropdowns are populated from the actual CSV headers read at run time, so suggestions can't drift from reality. Tool results should do the same — return the shape, not just the value.

Where I'm taking it: wrapping the registry as an MCP server. Since every node already carries its own Zod schema and description, list_nodes / add_node / run_pipeline are near-mechanical to generate from REGISTRY — the tool definitions fall out of the same object. That's the actual payoff of the refactor: the MCP layer costs almost nothing because the contract already exists.

Curious whether others have gone the codegen route — generating MCP tool schemas from an existing typed registry vs. hand-writing them. The hand-written ones I've seen drift within a couple of weeks.