Cover the essentials: "Every string gets __() or _e() with the text domain. I generate POT files with wp i18n make-pot, and use wp_set_script_translations for any translatable JavaScript strings."
Wrap all user-facing strings in translation functions: __() for returning translated strings, _e() for echoing them, esc_html__() and esc_attr__() for escaped translated strings, _n() for singular/plural, and _x() for context-dependent translations. Each plugin/theme declares a text domain matching its slug. Translation files (.po for source, .mo for compiled) go in the languages directory. Modern workflow: use wp i18n make-pot to extract strings, translate with Poedit or GlotPress, and ship .mo files. Strong candidates mention: the difference between load_plugin_textdomain() and load_theme_textdomain(), JSON translation files for JavaScript (wp_set_script_translations), and that WordPress.org handles translations via GlotPress for plugins in the directory.
Baseline internationalisation skill. Candidates who hardcode English strings throughout will produce themes and plugins that cannot be translated. Those who know the full workflow including JavaScript translations demonstrate thoroughness.