It will not work with the data like this

a1: ["olp" "love" "string" "love"]
a2: ["ulove" "alove" "holp" "sholp","vfmstring"]
r: ["love" "olp" "string"]

Because dedupe - "Returns a lazy sequence removing consecutive duplicates in coll."

Do you mean that I should put the "doseq" in the "deftest"?

There should be more than 1 test. deftest creates a top level definition.

There are randomized tests that are pregenerated, as described in the comment:
; these are were generated offline as random string creation is very time consuming in clojure
; they are based on C++'s algorithm as follows:
; first and last cells are always clear, maze size between 4 and 11 (not including line breaks), 1 out of 3 chance for a wall

I've added the code I'm using for maze creation to the tests also.
(defn random-maze-builder
[size]
(let [maze-size (+ size (* size size))
break-idx (+ size 1)]
(str
(reduce
(fn [maze idx]
(let [next (cond
(= idx 1) "."
(= (mod idx break-idx) 0) "\n"
(= idx (- maze-size 1)) "."
:else (if (= 0 (rand-int 3))
"W"
"."))]
(.append maze next)))
(StringBuilder. maze-size)
(range 1 maze-size)))))

random string creation is very time consuming in clojure

If anything is very time consuming, it probably means it's done in the wrong way.
Anyway, there should be some kind of random tests, maybe slightly randomized pre-generated strings or something else dynamically random.

Wow I wasn't aware it would be twice as fast with mapv!
Thanks, this is a tip to remember.

Too close to the maximum execution time. This solution randomly times out sometimes. Maybe change map to mapv in the tests? It makes a noticeable difference in performance.

Fixed the comparator, unless I'm missing something additional (in case I'd appriciate you'd point out)

Print the result of sorting a random sequence to see, for example [[-410 211] [197 266] [195 400] [449 476] [491 496] [100 142] [213 379] [282 380] [12 302] [-296 172] [-7 149] [-23 120] [370 376] [-373 -339] [-302 -264] [226 289] [499 500] [-180 -130] [490 498] [234 424]].

Could you please elaborate? When I tested it, it worked fine

Your comparator doesn't implement java.util.Comparator correctly, so the random tests expect incorrect results.

Having the frequencies call within the every makes it an O(n^2), so it's probably better to calculate them ahead of time

Saying what's the issue with this solution would be much more helpful than just saying "is terrible"

Original signature is "std::string DNAStrand(const std::string& dna)" in which you can't change dna because of the "const"

You should probably "dedupe" only after the sort, as there is no promise array1 is sorted