Explain Dart positional vs named parameters and write one signature

WHAT THIS TESTS: This question checks whether you understand Dart's three parameter flavors and can express them in a single valid signature. Senior interviewers care less about memorized syntax and more about whether you know how calling conventions affect API design, readability, and backward compatibility. Knowing when to use positional versus named parameters signals that you have written real Dart code beyond tutorial examples.

A GOOD ANSWER COVERS: First, a concise distinction between positional and named parameters. Positional parameters are matched by order in the argument list, while named parameters are matched by identifier and are wrapped in curly braces in the function signature. Second, the answer should present one function signature that contains all three requested pieces in the correct order: a required positional parameter, an optional positional parameter inside square brackets, and a named parameter with a default value inside curly braces. Third, a strong candidate notes that named parameters can be marked required with the required keyword since null safety, so they are not inherently optional. Fourth, the answer should mention that optional positional parameters use square brackets and can have defaults, while named parameters use curly braces and can also have defaults.

COMMON WRONG ANSWERS: A frequent red flag is claiming that named parameters are always optional or that optional positional parameters use curly braces. Another mistake is writing the optional positional parameter after the named block, which is invalid because Dart requires positional parameters to appear before named ones. Some candidates also forget that a default value for a named parameter is written with a colon and value inside the curly braces, or they omit the type annotations entirely. Confusing the call site syntax, such as passing a named argument without its label, also signals weak familiarity.

LIKELY FOLLOW-UPS: The interviewer may ask when you would choose named over positional parameters in a public API. They might also ask how required named parameters changed with Dart null safety, or how to handle a function that has many optional parameters without creating a messy signature. Another follow-up is asking about the difference between positional optional with defaults and named optional with defaults in terms of readability and maintainability.

ONE CONCRETE EXAMPLE: A solid signature looks like this: void describePet(String name, [int age = 0], {String breed = 'unknown'}). Here name is a required positional parameter that must be supplied in order. Age is an optional positional parameter inside square brackets with a default of zero. Breed is a named parameter inside curly braces with a default value of unknown. At the call site you could write describePet('Milo', breed: 'Golden Retriever') and omit the age argument entirely because it is optional.