I think it is important to understand the reason behind questions. From your version of the question I think they wanted to see how you would approach a small problem and how would you think in process to fix it. Also possible to see how deep you would go for a simple-looking problem after they ask you additional questions, how familiar you are with Check Point products or your understanding of troubleshooting in general.
So, the initial information is not enough. But was it not possible to ask them questions to get this information? For example to ask if we have a network diagram for start.
As the first step you can just check in logs with given IPs. If all firewalls connected to the same management and log server, then you would see where traffic is blocked. This log entry will show you on which firewall traffic is blocked and which policy package it is using. If there are several firewalls on the path of this traffic, you would repeat it several times. That if we have logs for this traffic, of course. Here they could ask you something like "and what if we don't see logs for this traffic"?
Most probably you know source and destination IPs, so you can check behind which firewalls these networks are. You can check how traffic will be routed through firewalls - easier in CLI, but also possible through Dashboard with some assumptions. Here you could mention some commands that you would use to do a sort of reverse engineering for the network diagram. If you found required firewalls in CLI, then you can also quickly check from CLI which policy package is installed on the gateway.
They can tell you here something like "ok, you added rules, but traffic is still not reaching the destination server and not visible in logs". You would need to explain how you would troubleshoot it further using for example fw monitor and tcp dump, or mention "Log implied rules" setting.
Traceroute can be just blocked on firewalls (and it is by default), so you might not see anything in the output of the source host. You would see that traffic on the gateway of course, which returns you to firewall logs. The second possibility here is that you don't have access to the source host to traceroute, as it usually is in many companies - different teams are responsible for different systems.