Hi there!
Where do you prefer keeping your automated tests - same repository as application code or separate repository? Why?
In the past, I would usually keep API or UI tests separately from code, but it always meant devs having hard time maintaining or extending tests. In my new project I want to try different approach and include tests in same repository as application code. Please share your experiences 
I’ve done both. I like test code living in parallel with the application code. We already had this paradigm for unit and integration tests. Extending it to functional/end-to-end tests seems like a no-brainer in hindsight.
The biggest advantage here is that tests should align with the current code implementation. There’s no cross referencing between two repos to figure out what version of the tests need to be run against a particular version of the code. This in turn simplified our CI pipeline - only one repo to keep track of, check out, build, and run tests against.
Another benefit is that by pushing the code closer to code developers work with, it encourages them to take some ownership of the functional tests. We don’t gate on end-to-end tests since we’re not mature enough to have requirements/contracts specced out to the point where they can be updated at the same time as the features are built/updated/etc, but seeing the functional tests fail encourages folks to do that.
I agree with @ernie and for the reasons stated. Additionally, anyone would be able to run the suite of tests to get feedback on new and changed code. I think of it as running a regression very, very frequently.
Also, this works, as you may have experienced @vilkg, very well for API projects!
Joe