I agree -- these types of questions need to stop. I get it; they are easy to ask and are supposed to be setting up a level playing field for interview candidates as everyone is knowledgeable about lights (or whatever physical object they ask about) to some level. This helps the interviewer compare answers to other candidates. It also helps the interviewer by not giving away any company secrets about their own products.
Generally, the interviewer is wanting you to ask questions to gain clarity instead of jumping straight into an answer. Interviewing is a skill like any other, so the more you can practice interviewing, the better you'll do.
With the information you provided, what can you ask to gain clarity?
- Are there any requirements for this project?
- What is the purpose of the lights?
- Why is having the lights setup in a triangle important? Is this a requirement? Can they be setup differently? Are the lightbulbs triangular or are they setup in a triangular shape? What happens if you setup/move the lights?
- How do I turn on/turn off the lights? Are there multiple ways to turn on/off the lights? If so, what are those ways?
- What should occur when I turn on the lights?
- What should occur when I turn the lights off?
- What color is the light supposed to be?
- Do the lights have a timer?
- Where are the lights mounted? Where should they be mounted?
- What types of lights are being used?
- What shape are the lights?
- What should happen if you add or remove a light?
- Are they smart lights that can be controlled via an app?
- Are the lights an accessory to a larger item (think camera, tv, projector, car head/tail lights, etc)? How do they interact with those accessories?
- etc, etc. There are too many questions to ask! (QA can mean Question Anything)
Some of these questions you might think, "I already know the answer." Don't go there. Don't assume you know the answer. QA can mean "Quit Assuming." In my experience, bugs occur when people on the team make assumptions about the requirements or functionality. Ultimately, get in the habit of asking questions to learn, to seek clarity, to seek knowledge!
With you asking those questions, you want to pay attention to the interviewer's answers as they can lead you to the right test cases to implement. Bring paper with you to write down their answers.
How do you answer and create test cases now?
You want to be holistic. The answers you gave really concentrate on functionality. I like what Kate said in her answer about fitness for use. What does that look like? Your answers should touch on:
- Performance of the lights. Turn the lights on/off repeatedly for x,y,z number of days. Bonus points if you say, I'll build a robot to do this as you're thinking of how to automate the test.
- Security of the lights. If they are smart lights, ensure proper access control to the lights. If not smart lights, you can ensure proper access control to the room they are setup in.
- Usability: are the lights easy or hard to use? Can everyone use them: different ages, people with disabilities (this is your accessibility testing), people that speak different languages (localization and internationalization testing)?
- Observability: Are the color, tone, temperature of the lights correct and match the requirements?
- Scope: If the lights are an accessory, test for integrations into the product. What are things that can go right/wrong once it's integrated?
- Edge cases: you damage the lightbulb; you cause an electrical short; you cause a flicker; does it still work? There are tons of ways to cause failure. How do the lights (or really, the application) recover from failure?
Bonus points if you can also add in what you'd do if you found a bug; who would you reach out to for answers to your questions? Yes, you mention collaborating with the client, but unless you are doing consulting work, or work at an agency, the client is the business you work at. So, mention how you'd collaborate with the developers, the Project/Product Manager, DevOps, etc.
The answer they are looking for, the terms they are wanting to here used are: Performance, security, usability and user experience, observability, accessibility, localization, internationalization, etc. So the more you can do this, know terminology, how to use terminology, and create a strategy, the better you'll do in the interview!
Side note: I'd say, lights is a weird one. A cup, a mug, a pen are very common.
Also, since this was for an intern position, you may not know the techniques or terminology. I'd encourage you to seek out that knowledge.