I agree, and this is what we have been doing for a while at my current job (I went through the same process, so it's been done for at least 7 years).
The candidate would come to the office (when we were still doing in-person interviews) and meet a couple of the developers for a little bit of chatting. They would then be given a couple of printed pages of Java code with a few basic classes representing banking accounts with some typical methods for depositing, withdrawing, persisting to a database etc. (with all of the details stubbed out) - and they would be given these instructions:
Read the provided Java source code files and identify any problems that you can find.
The problems can include things such as actual bugs, design problems or code quality issues.
You do not need to search for syntax errors - the code does compile.
You have 15 minutes to find as many problems as you can.
The candidate would be left alone with the papers and a pen and would spend the next 15 minutes looking over the code by themselves.
The rest of the interview would then be spent discussing their findings. Most candidates would find the obvious problems in the logic, missing null-checks etc., while trickier things like synchronization issues were missed by quite a few. Even though we had a list of all the bugs/issues that had been put into the code, the important part wasn't for a candidate to check off as many of these as possible - the important part was the discussion about the issues that followed.
After the candidate had told us what they found, we would start hinting about the remaining issues and eventually tell about all of them. How quickly someone would pick up on an issue when it was pointed out told us quite a lot. It was a way to get a feel for how the candidate thought and reasoned about code, without the pressure of them having to actually write code with someone looking over the shoulder.
As others have commented there are lots of costs and logistical complications involved in a traditional photo shoot.
You need to have all the garments of the outfit, the model, the photographer and all support staff in the same place at the same time.
Replacing this with all digital models and clothes would be a big cost reduction.
However, it is still relatively hard to render photo-realistic faces and there's still a long way until all clothes are available as 3D models with realistic simulation of fabrics etc.
But there are already solutions being used today that achieve some of the benefits without using completely generated content.
Looklet[1] provides a system where each garment is shot individually on a mannequin. This is done by a couple of operators in a custom studio, typically placed in a warehouse or similar where samples are received.
The images are then combined with other garment images and previously shot images of models to produce photo-realistic catalog images without the need for a traditional photo shoot.
The web page has sample images and a list of retailers using this technology.
Take a look at e.g. Saks Off 5th's[2] catalog and see if you can spot the images that have been produced in this way.
The candidate would come to the office (when we were still doing in-person interviews) and meet a couple of the developers for a little bit of chatting. They would then be given a couple of printed pages of Java code with a few basic classes representing banking accounts with some typical methods for depositing, withdrawing, persisting to a database etc. (with all of the details stubbed out) - and they would be given these instructions:
The candidate would be left alone with the papers and a pen and would spend the next 15 minutes looking over the code by themselves.
The rest of the interview would then be spent discussing their findings. Most candidates would find the obvious problems in the logic, missing null-checks etc., while trickier things like synchronization issues were missed by quite a few. Even though we had a list of all the bugs/issues that had been put into the code, the important part wasn't for a candidate to check off as many of these as possible - the important part was the discussion about the issues that followed.
After the candidate had told us what they found, we would start hinting about the remaining issues and eventually tell about all of them. How quickly someone would pick up on an issue when it was pointed out told us quite a lot. It was a way to get a feel for how the candidate thought and reasoned about code, without the pressure of them having to actually write code with someone looking over the shoulder.