In most of the cases, the required year of experience is required to measure the exposure of someone into different phases/ scopes of the job, not only the amount of time spend doing the same thing.

For example, a software / IT professional with 5-8 years of experience will have exposure to / knowledge of a complete development lifecycle, the product architecture and integration points for the product. On the other hand, someone working in the same program, for a year or less, might have the technical knowledge of the module they're working on, but will lack the overall visibility (or vision) for that product. Over time, someone is not only expected to gain the technical knowledge, but also acquire the domain / business knowledge associated with the product / platform.

In other words, it's not only about how you write code, it's actually more about why you write code.

Echoing what Adriano mentioned in the comment: experience is not just about the QUANTITY but the different scenarios and different moments of software life cycle you encounter over a sufficient amount of time. It's about the problems you face and the long term impact of your decisions.

Thereby, do not try to use the time as your only achievement, rather try to showcase your knowledge and expertise, that will be giving you positive edge. Best of luck.

Does doing double job counts as double experience?

TL;DR - No.

To elaborate, in most of the cases, the required year of experience is required to measure the exposure of someone into different phases  / scopes / activities / responsibilities of the job, not only the amount of time spend doing the same thing.

For example, a software / IT professional with 5-8 years of experience will have exposure to / knowledge of a complete development life-cycle, the product architecture and integration points for the product. On the other hand, someone working in the same program, for a year or less, might have the technical knowledge of the module they're working on, but will lack the overall visibility (or vision) for that product. Over time, someone is not only expected to gain the technical knowledge, but also acquire the domain / business knowledge associated with the product / platform.

In other words, it's not only about how you write code, it's actually more about why you write code.

Echoing what Adriano mentioned in the comment: experience is not just about the QUANTITY but the different scenarios and different moments of software life cycle you encounter over a sufficient amount of time. It's about the problems you face and the long term impact of your decisions.

Thereby, do not try to use the time as your only achievement, rather try to showcase your knowledge and expertise, that will be giving you positive edge. Best of luck.