Casual mendan preparation: questions, a self-introduction, and the apply decision

A casual mendan is commonly used before a formal application so the company and candidate can exchange information. It is not safe to assume that every company runs it the same way. The person you meet, whether a resume is needed, and whether notes are shared with a hiring team can differ.

Read the invitation and ask the coordinator if anything is unclear: who will attend, how long the meeting is, whether there is a specific opening, and what materials are expected. Treat the conversation as exploratory, while keeping the basic professionalism you would use in any work meeting.

You need enough context to ask useful questions, not a full interview dossier. Write one sentence each for the product and customer, why the company contacted you or why you accepted, what the possible role appears to own, and what you still cannot learn from public information.

Then separate facts from guesses. If the job page says "platform modernization," that is a fact. Your guess about a cloud migration is not. Turn the guess into a question instead of speaking as if the company has already confirmed it.

A practical introduction has four parts: your current role, the work you mainly own, one result or area of depth, and what you hope to understand in this conversation. It gives the other person enough material to choose a useful direction.

Template: "I currently work as [role], mainly responsible for [scope]. Recently I [project or result], where I focused on [your contribution]. I am exploring [direction], and today I would like to understand [role or team question]." Stop there and let the conversation respond.

Start with questions that a job description rarely answers. Ask why the role is open, what work would occupy the first three months, which problem is urgent, and how the person you are meeting works with the role. These answers tell you whether the company has a concrete need and whether the meeting matches your interests.

Choose questions tied to your own decision criteria. For an engineer, that may mean ownership, code review, releases, technical debt, on-call, or how product and engineering resolve priorities. Ask for a recent example when a broad answer sounds too tidy.

Even an exploratory conversation needs enough context to stay useful. Be ready to explain your current work, why you accepted the meeting, what direction you are considering, when you might move, and any non-negotiable location or language constraints. Keep these answers factual and brief.

You do not need a finished application motivation. A natural answer is: "I am not deciding on an application yet. I was interested in [specific product, problem, or role point], and I want to understand [open question] before deciding." That is honest and still shows preparation.

Follow the invitation when it specifies clothing or materials. If it does not, clean business-casual clothing and a short career summary are usually low-risk choices, but company norms vary. For an online meeting, test the link, audio, camera, screen name, and time zone before the call.

Compensation and work conditions are valid questions. Avoid spending the whole conversation on them when the person cannot give an accurate answer. Ask whether a range or policy is available, then confirm details with recruiting later. If a condition determines whether you would ever apply, it is better to clarify it early than to hide it.

Within ten minutes, record what you learned, what remains uncertain, one positive signal, one concern, and the next action. Choose apply, hold pending an answer, or skip. A pleasant conversation is not evidence that the role fits, and a reserved interviewer is not evidence that it does not.

InterviewTrail AI lets you keep the meeting at the casual-mendan stage, attach your questions and notes, and carry the useful context into later interviews if you apply. The point is to avoid reconstructing the conversation from memory when the company follows up weeks later.