What does a Human Factors job applicant bring to an interview and what happens in a typical HF interview?

In addition to the host of normal job skills, when interviewing candidates for a human factors position, I attempt to understand: What basic human factors skills has the candidate demonstrated? Does the candidate understand personas, use cases, event flow diagrams, sequencing diagrams, requirements generation, experiment design, ethical approval processes for experiments, statistics, survey design, basic standards documents in their fields, and a variety of standard metrics used to measure humans. What areas of domain knowledge does the person have? All human factors work is rooted in a particular application. It could be medical, manned aerospace, autonomy, construction, factories, etc. While any competent human factors engineer will pick up background knowledge in any domain they are assigned, it's best if you can hire someone who already knows the landscape. This is a test of implicit knowledge about a field. It's not required for entry and mid-level positions, it's just a bonus when it's there. How does the person handle large intractable problems? Human factors engineers are frequently caught at the intersection of project managers who want success, engineers who have built technical systems that assume humans are inerrant, and users who are driven by practicality not by what designers want or pretend. Breaking apart a system into components and figuring out how they interact is a mandatory skill for a human factors engineer. Often I'll ask a question like "The city of Boston wants you to design their new ticketing and card swipe system. You can ask any questions you want. Here's a whiteboard marker. Go." Can the person manage a team of artists and formulate software requirements so that work can be delegated? Human factors engineers are ideally suited to manage teams because a little bit of human factors criticism generates a lot of work for implementers. Can the person prototype effectively? While most people prefer specific prototyping tools for interaction, the best tools are paper, powerpoint, and a whiteboard. If the candidate cannot use these, and use them on the spot, it will be an uphill battle to get them to engage others. Pragmatically, the following things are also very likely happening: Since many companies lack sufficient software engineering capabilities, interviewers are attempting to figure out if you can actually make the things you talk about. No one likes a "designer" (in any capacity) who cannot implement or understand the difficulties that designs pose to implementers. Computer-related fields are plagued by the problem of people who claim to be one thing while lacking the ability to actually do the job. One terrifying phenomenon is the number of applicants for jobs involving coding that cannot answer the classic fizz-buzz interview question. One question that is probably in people's minds is whether or not you have a track record of actually doing things, of if you just talk about them in a way that makes it sound like you are competent. It's likely that everyone is thinking about how they can use your skills if they decide to declare your human factors job description a failed experiment and tell you to do something else. Many company cultures are skeptical of "this whole user experience thing" or blatantly think it's an excuse to sit around and tell people what to do. As a safety measure, putting some evidence forward you are an accomplished software engineer, controls engineer, graphic designer, manager, or anything else, can make skeptical people a lot more comfortable hiring you because they can imagine a backup plan.

A portfolio of deliverables would be one thing possibly. Some examples might be: Session guide Findings report (with video of study) Recommendations presentation (with ideated solutions) User survey/interview questions Personas Customer journey maps (maybe an edge case deliverable) Photos and/or videos of sessions conducted Outside of that, yes, case studies would be good and augmented by the deliverables above where possible.

Many projects have security or commercial confidentiality considerations, so collating work products into a portfolio can be tricky. Where the actual work cannot be included for such reasons, some 2 page maximum  summaries of each project and your role within them would be a good idea.