The difference between a developer who is using test automation, vs a automated test developer is philosophical and academical, but in reality they have nearly-identical set of skills (and difference in other skills will be bigger than this difference).
If you are hiring a developer who cannot test, it is not a real developer and obvious no-hire.
If you hiring manual tester, no development skills are required.
So I assume assume hiring for a position with substantial responsibility for automated testing.
Now you are presumably comparing a developer who already knows (or willing to learn) your test automation technology, vs automated tester. Some people call them "software developer in test", which tells you all you need to know. They are developers, but instead of your core system, they are developing tests for that core system.
If you will be interviewing 1000 people to hire 200, it might be not a total waste to ask your question. But because you are hiring just one person, you just list core and nice-to-have competencies, and then hire best overall candidate.
And quality of the candidate is more complicated than just being a developer (and if developer cannot do unit tests for own code, it's a no-hire) or a tester (manual? test automation is just development using different libraries). For that single hire, you need to account for
- other skills (communication, sys admin, personality fit, etc),
- level of those skills, and level of domain knowledge (previous experience with similar systems)
- transferable skills from previous projects
- previous experience (and/or lack of it) with dozen of tools you use,
- estimated time to get up-to-speed with missing skills and expense to get them (and do you have time to wait)
- "vibe" from the candidate and candidate's willingness to gain those missing skills (it is difference between learning during work hours if I have to, vs learning in my free time because I am so eager to learn the technology)
People are not cogs, especially for small group, where you are flying very low, contribution of every member is obvious, there is no place to hide, and bad hire can make or break the project. You need to evaluate individuals, and chances you will have two candidates with exact same level of all other skills (and so difference mentioned in original question will be the decisive difference) is zero.
Your best bet would be a former manual tester, who already knows your core system, and is eager to learn programming and upgrade skills to test automation. Or a former core developer, who for whatever personal reason is interested to learn your test automation technology (vs being forced to learn it).
Edit, Feb 2019:
Also, testing on unit level is best done by the developer who is changing related code. a (failing) test should be written for each reported bug (to make sure it is correctly detected), then bug should be fixed (so unit test will pass). It would be a waste of time to someone else (tester) learn relevant code deep enough to write unit tests (core developer already knows everything relevant to write that unit test).