I have managed to get 15/15 without =any= prior knowledge of use of python (treated it like Java in terms of local variables). Actually I don't know if the Python has integer types. Hardest question regular expression one (mostly because regular expressions are the type of write-only code to me)
that being said. Some remarks about questions:
1st fails for all NaN/empty. Returning negative infinity is hardly a good choice for an array full of NaN.
2nd I didn't like this one: "children" comes from nowhere. There is no 'definition' of order, so 'first' is quite confusing, perhaps 'any' suits better.
5th I'd have expected white spaces in the toString rendering of the array (checked via inspect element). Had to make some assumptions.
7th since only variables i1 and i2 are defined and 3rd/4th answers make no sense as loop predicates, the entire merge function body is rather pointless.
8th About the correct answer:: One problem with ASCII is that it only support English characters (and a few other European languages). The characters are Latin and even Ural based languages like Estonian/Finnish/Hungarian use the same base for alphabet. "Unicode is like ASCII, but larger.", I'd never consider them a"like", for instance converting hexdecimal numbers to their asciis code is 5byte assembly for 8086. Also ascii is sort of a code page while unicode tries to combine all code pages together.
10th But because they share memory with other threads in the same process, threads must synchronize access to shared data to maintain data integrity. "Synchronize access" implies certain data model/locking paradigm. It's possible to have entirely lock free/copy-on-write multithreaded code that will exhibit no need for explicit synchronization. Alternatively some code could still be correct with benign data races (but that usually comes close to poking the dragons)
11th best practice is generally to use prepared statements, which lets the database itself protect against SQL injections. The statement is not necessarily true, the prepared statement could be just standard execution with parameters being escaped by the database driver (client), technically still performing the escaping part.
12th Side channel, timing attack is correct but virtually impossible to observe due to the very short nature of hashes and the fact they are all in the L1 by the time the check is performed -- even SHA512 is just one cache line, processing the comparing function yields 10ns or so time difference. The real concern is "the user_submitted_hash" -- users should not be submitting hashes directly as that precludes salting and invalidates use of any =slow= hashing function as the attacker just submits more hashes. IMO a bad question.
14th One advantage of DFS, however, is that it uses much less memory. BFS must store a queue of nodes to visit, and this queue can grow to (order) the size of the entire graph. The statement is not universality true and the worst case scenario is the same, a good answer https://cs.stackexchange.com/a/299. More importantly DFS can be executed in parallel.
I started reading the green part after first few answers, hopefully the remarks are useful (and not snark).
that being said. Some remarks about questions:
1st fails for all NaN/empty. Returning negative infinity is hardly a good choice for an array full of NaN.
2nd I didn't like this one: "children" comes from nowhere. There is no 'definition' of order, so 'first' is quite confusing, perhaps 'any' suits better.
5th I'd have expected white spaces in the toString rendering of the array (checked via inspect element). Had to make some assumptions.
7th since only variables i1 and i2 are defined and 3rd/4th answers make no sense as loop predicates, the entire merge function body is rather pointless.
8th About the correct answer:: One problem with ASCII is that it only support English characters (and a few other European languages). The characters are Latin and even Ural based languages like Estonian/Finnish/Hungarian use the same base for alphabet. "Unicode is like ASCII, but larger.", I'd never consider them a"like", for instance converting hexdecimal numbers to their asciis code is 5byte assembly for 8086. Also ascii is sort of a code page while unicode tries to combine all code pages together.
10th But because they share memory with other threads in the same process, threads must synchronize access to shared data to maintain data integrity. "Synchronize access" implies certain data model/locking paradigm. It's possible to have entirely lock free/copy-on-write multithreaded code that will exhibit no need for explicit synchronization. Alternatively some code could still be correct with benign data races (but that usually comes close to poking the dragons)
11th best practice is generally to use prepared statements, which lets the database itself protect against SQL injections. The statement is not necessarily true, the prepared statement could be just standard execution with parameters being escaped by the database driver (client), technically still performing the escaping part.
12th Side channel, timing attack is correct but virtually impossible to observe due to the very short nature of hashes and the fact they are all in the L1 by the time the check is performed -- even SHA512 is just one cache line, processing the comparing function yields 10ns or so time difference. The real concern is "the user_submitted_hash" -- users should not be submitting hashes directly as that precludes salting and invalidates use of any =slow= hashing function as the attacker just submits more hashes. IMO a bad question.
14th One advantage of DFS, however, is that it uses much less memory. BFS must store a queue of nodes to visit, and this queue can grow to (order) the size of the entire graph. The statement is not universality true and the worst case scenario is the same, a good answer https://cs.stackexchange.com/a/299. More importantly DFS can be executed in parallel.
I started reading the green part after first few answers, hopefully the remarks are useful (and not snark).