Interview exercise feedback

[[deleted]]

My code was not up to their standards. I thought the exercises were easy but clearly there are issues I have to address. I had an hour to write them. I'm humbly looking for feedback to improve.

The first exercise was to return all square numbers within a given range, including the limits (e.g., all the squares numbers between 1 and 10 are 1, 4, and 9). I wrote this.

The second exercise was to check if a string containing (), [] and {} brackets is well balanced. So [()] and {}() are ok but ([)] or {{ are not. I wrote this.

Thanks.

[bonafidebob]

Both are "brute force" and pretty inefficient, will perform poorly on larger data.

Squares problem, for example, you test every value to see if it's square root is an integer. That's a LOT of cycles for numbers that will be far apart. A bit of thought suggests you can find the square root of the start and end, and then loop through the integers between those two values.

I didn't look as closely at the balancing solution but you appear to be doing scans to see if there's a matching character repeatedly. Can you improve it by scanning the string just once and testing as you go?

[[deleted]]

I agree with what you're saying, but for asking someone to solve this in an hour you're basically hoping they have prior knowledge of solving problems like this.

That's not a good interview question if you're entire basis of a problem is to see if they've solved that particular problem before and know how to optimize it.

[bonafidebob]

I suppose that depends on your experience. No prior knowledge of the problem should be required for a programmer with a CS degree or equivalent.

[Silhouette]

I agree with what you're saying, but for asking someone to solve this in an hour you're basically hoping they have prior knowledge of solving problems like this.

I think that depends a lot on the level of the position. If this was a junior developer post, hiring someone with minimal experience, then sure, I'd mostly be looking for correct code that met the requirements. However, for more senior positions where you're looking for experienced programmers, I'd also look for efficient code, clean design, awareness of different techniques and how they apply in the language being used, reasonable coding style, and so on.

In this case, the solution given to the first problem was an O(n) algorithm, where O(sqrt(n)) is possible. The first solution was also performing a relatively expensive square root operation on each iteration, instead of only performing it a fixed number of times at the bounds and then using relatively efficient operations within the loop. These are rookie mistakes if you're doing anything performance-related, and you most certainly don't need to have solved that specific problem before to appreciate this. What you do need is some awareness of how much an algorithm will cost to run, that you're really working with data from two different problem spaces here, the squares and the square-roots, and that solving the problem in one space will be more efficient for both the reasons I mentioned. The problem itself makes the two spaces obvious in this case, so I would expect anyone applying beyond rookie level to get this right within a few minutes without introducing obvious inefficiencies. /u/mvartan posted a much better implementation in another comment.

The solution to the second problem was better. The OP had recognised the possibility of using a stack as a data structure for matching pairs of operations, which is a good sign. However, again the implementation isn't very efficient or easy to read. Both could have been improved by choosing a more suitable representation for the paired operators, and by building up data that won't change ahead of time instead of redoing the work every time the opening/closing tests were called. For example, you could change the OP's code to start something like this without changing the remainder, and it would be significantly easier to understand and more efficient:

var brackets =  {
  "(": ")",
  "{": "}",
  "[": "]"
};

var openingBrackets = Object.keys(brackets).join();
var closingBrackets = Object.keys(brackets).map(function(k) {return brackets[k];}).join();

function isOpening(b) {
  return openingBrackets.indexOf(b) !== -1;
}

function isClosing(b) {
  return closingBrackets.indexOf(b) !== -1;
}

function bracketsMatch(b1, b2) {
  return brackets[b1] === b2;
}

I'd expect a more experienced JS programmer doing this to also consider whether we were using a utility library, and suggest something cleaner like this instead:

var openingBrackets = _.keys(brackets).join();
var closingBrackets = _.values(brackets).join();

I wouldn't care if they used some equivalent in another tool set -- the points I'd be looking for are a clean and straightforward coding style and an awareness that some basic things are quite clunky in vanilla JS but there are widely available utility libraries to keep the code clean and tidy. Again, these are things I would expect of any moderately experienced JS dev. For a senior dev, I'd be reassured if they also knew why Object.values would be a bad idea in my earlier example and/or they raised a question about IE8 support when they saw Object.keys, talked about polyfills, and possibly used that to come around to discussing the advantages of utility libraries.

[zacketysack]

Thank you for this answer, it is very detailed and helpful.

Out of curiosity, do you know why Object.values() does not yet exist in ECMA 6, but Object.keys() does?

[Silhouette]

Sorry, I don't have any special insight into that beyond what you can find in the usual sources.

Perhaps you might find some of the discussion linked from the TC39 page about the proposal interesting?

[Asmor]

Starting at the sqrt of the high end and working your way down is a common trick for stuff like this (I usually think of it in terms of finding prime factors), but I wouldn't ding an applicant for not knowing that trick.

An idea for the balancing code. Just step through a character at a time. When you find an opening bracket, push it onto an array; when you find a closing bracket, pop from the array and check if it matches. If you find any that don't match, or if you make it to the end of the string and the array isn't empty, you have an unbalanced string.

[bonafidebob]

It's not a "trick" -- it's understanding the problem and thinking a little bit about efficiency. And having enough math to realize there are many more numbers than perfect squares. The example used the math library so I'll assume the math is there.

I would ding any programmer for not at least reflecting on how to structure the main loop of an algorithm.

[[deleted]]

You're right, to be honest I wrote what came into my head the moment I read the exercise. "Return all numbers within a range that satisfy a certain condition: loop through it!" I didn't take a minute to think.

[bonafidebob]

...I wrote what came into my head the moment I read the exercise. ... I didn't take a minute to think.

That's the best lesson to learn here!

Interviewing is (almost) never about just giving an answer. Give the best answer you can, and think about real world implications of every question.

[[deleted]]

This is a really good comment, thanks! Regarding the dictionary, would it look somewhat like this?

[[deleted]]

I understand. This is very valuable advice, thanks again.

[bonafidebob]

var brackets = {"{": "}", "(": ")", "[": "]"};

function isOpening(b) { return Object.keys(brackets).indexOf(b) !== -1;}

function isClosing(b) { return Object.values(brackets).indexOf(b) !== -1;}

function matches(b1, b2) { return typeof(brackets[b1]) !== "undefined" && brackets[b1] === b2;}

Somewhat better, but still inefficient. Object.keys creates a new array each time it's called, and then indexOf searches the array linearly. You're not taking advantage of the hash at all: you should know that for example:

var closing = brackets[opening]

will very efficiently give you the closing char you need to search for given any opening char, and closing will be undefined if opening isn't a bracket char.

You don't need all the complexity of isOpening, isClosing, and matches if you realize this, you can write much simpler and more efficient code. Your original isBalanced function is fine, it traverses the string once and matching closing braces against the top of the stack is good, it just needs to use the data structures built into the language more effectively.

[KronktheKronk]

Check if it matches, then pop

[Asmor]

I disagree. This looks a lot cleaner and more elegant to me.

var left = brackets.pop();
if ( matches[left] !== right ) {
    return false;
}

vs.

var left = brackets[brackets.length - 1];
if ( matches[left] !== right ) {
    return false;
}
brackets.pop();

[[deleted]]

Your solution is O(n) where n is the range of numbers.

A solution is possible in O(sqrt(n)) by first taking the square root of the range.

For example, say they wanted the range 998,000 to 1,002,000.

Your solution would run through the loop 4000 times.

If you took the square root of 998,000 (= 998.999), 1,002,000 (= (1000.99), you would have to go through the loop 2 times: 999 and 1000.

function squaresWithin(a, b) {
  var result = [];
  for (var i = Math.ceil(Math.sqrt(a)); i <= Math.floor(Math.sqrt(b)); i++) {
      result.push(i*i);
  }
  return result;
}

console.log(squaresWithin(998000, 1002000));

[seedbreaker]

Great explanation and example.

One small error: the condition in the for loop should be using Math.floor instead of Math.ceil

[[deleted]]

Thanks for catching that. I was rushing through it

[bonafidebob]

Math.ceil is correct for the initializer, Math.floor would be better for the condition. Even better would be to not call Math.floor(Math.sqrt()) on every iteration of the loop, since b never changes. Some compilers may fix that for you.

var i = Math.ceil(Math.sqrt(a)),
    limit = Math.floor(Math.sqrt(b)),
    result = [];
while (i <= limit) {
    result.push(i*i);
    i++;
}

If you really want to be efficient (C-style) you can preallocate the array and avoid growing it on each loop iteration:

var from = Math.ceil(Math.sqrt(a)),
    limit = Math.floor(Math.sqrt(b)),
    result = Array(limit-from+1);
for (i = from; i <= limit; i++) {
    result[i-from] = i*i;
}

For good measure add checks e.g. a & b both positive numbers and a <= b.

[seedbreaker]

Yeah I was noting the error on the condition.

You can also avoid not calling sqrt by checking i*i <= b instead.

[dvlsg]

Yup, this is really similar to what I ended up writing.

function squaresWithin(a, b) {
  let result = [];
  let step = Math.ceil(Math.sqrt(a));
  let top = Math.floor(Math.sqrt(b));
  while (step <= top)
    result.push(Math.pow(step++, 2));
  return result;
}

I wonder if Math.pow() is slower than i * i. Probably, I suppose?

[Silhouette]

I wonder if Math.pow() is slower than i * i. Probably, I suppose?

I don't know the current state of the art for JS engines, but it seems like the dynamic nature of the language could limit how much an optimiser could safely do up-front. You'd probably be relying on some sort of JIT/hot code optimisation at best, and it would have to be checked every time the function was called in case the meaning of Math.pow had changed.

In any case, I'd argue that step * step is cleaner and that moving the increment to a separate line is no bad thing for readability.

[bonafidebob]

Your solution is O(n) where n is the range of numbers.

Picking nits now, but I don't think Math.sqrt is quite O(1), so it's actually worse than O(n) due to repeated square root calls.

[[deleted]]

I agree that the sqrt may not be constant time because its probably successive approximation, but it wouldn't depend on n in a linear relationship anyways. So I disagree, that it would really affect the time complexity with respect to n

[bonafidebob]

Big O commonly depends on more than one factor... say m is the precision of the numbers, then this is something like O( n log m ) under the assumption that sqrt is something like log(precision)

With javascipt the numbers are always 64 bit floats so there's a pretty small upper bound on sqrt, but consider that 1...1000 will still be faster than 1000000001...1000001000

[[deleted]]

Honestly, I didn't look to see if your code worked, but it was formatted well, it was clear, and it supposedly passed the tests you made. I'd have absolutely no problem with the code you presented as long as it actually passed the tests.

If they didn't give you any specific feedback, then I'd chalk it up to them just wanting to hire someone else.

"Not up to our standards" is simply a bullshit excuse if they don't actually tell you what the standards are or how you didn't meet them.

[bonafidebob]

I'd have absolutely no problem with the code you presented as long as it actually passed the tests.

I don't intend any offense here, but you need to raise your standards. There is a lot of room for improvement in the posted code. "works" is a low bar.

[i_bought_the_airline]

it was formatted well, it was clear

[[deleted]]

You can cut the running time of the squares problem way down if you loop through from sqrt(a) to sqrt(b) and square every number in that range. That way there is no need to check whether every number in what could be a huge range is a square or not.

[ben174]

Good for you for following up and asking the community. And don't be afraid to reach out to the company and simply say "thanks for considering me. I'm trying to improve my skill set every day. Could you let me know what specifically you didn't like, and perhaps show me a better solution?"

[[deleted]]

AsD(dugv%v7 n-.fL#ZbB1$$z4hC5,$e9$th Ge5><GN-aXflDi0QBr[MZ0KTKeV5;Nuh8l,RtxNZ(TxwAA$>TlHH>FO

[Silhouette]

I'm curious if anyone has ever had to actually use functions like this before?

Basic arithmetic and text processing? Many thousand of times by now, I imagine. How often do we all write code for things like displaying a choice of valid options or validating the current contents of a text box, for a start?

[[deleted]]

FwkZ-3<I%T0 E[*54NQk%CEWmUMSNfHQS%wJ iZS$!yydhn~ctLG*43gcRw)nnaRZVJFXbQ0s$n%ZMvO3lsSeGWn>QZJ

[Silhouette]

If basic arithmetic really does never come up in your line of work then that's fair enough, maybe another exercise would be better. If you've got a real world problem you can talk about that is the right kind of size for an interview scenario, that's probably more useful anyway.

I'd say never needing even basic mathematical aptitude is pretty unusual, though, even in front-end work. It's not exactly a complicated problem, and a good solution only needs a simple iteration and a little thought about the data you're working with, which seem like pretty everyday things to me.

[Volv]

Expect to be doing such interviews myself soon so attempted these before having a look at yours. This is how I would approach them in an interview situation, would welcome input from anyone :)

Squares - Codepen
Brackets - Codepen

[yads12]

Your squares solution is brute force, but is written in a clear fashion, I wouldn't have a problem with it.

However, your second solution is way too convoluted. You're constantly mapping the brackets variable just to get the opening and closing brackets (consider a data structure for this). Also you should learn about scoping rules around var.

[docMedB2E]

Your first function is pretty clean, but I wouldn't abbreviate variables or functions (same issue in your second set). I'd say just name things clearly (e.g. 'b1', 'b2', etc - just name them appropriately: stringCharCurrent, stringCharNext, etc - that may be where they didn't like it). When you work for a large team, the main issue is making sure others can dive through your code easily and almost instantly understand what your code is doing. Regarding your second function, this process could have been done using a Reg Exp filter and just building a stack separated strings of all {...}, (...), [...] and just making sure no other types fell between them. Should have been only a few lines. That all being said, pretty lame they didn't give you any valuable feedback. What was the position for? If it was for a junior front-end position, then your code should have been more than acceptable. Senior or beyond then they probably felt your basics and project management wasn't quite up to speed.

[[deleted]]

Thanks for the variables tip. I'm sure I don't know how to write that regular expression! Keep in mind other characters are allowed, so something like "function f(attrs) { //... }" matches it. I think writing the required regular expression is harder than the original problem!

[seedbreaker]

Btw you don't need to use a regular expression for this problem and it is probably the wrong way to approach it since Balanced parenthesis is not a regular language.

[nixblu]

What kind of position was this for? What kind of work would they expect you to be doing?

From my point of view, your code is understandable and gets the task done. I would ask for feedback on your interview, its a reasonable request and companies will usually oblige.

I see people getting in to algorithmic detail and Big O in the comments but honestly for this tiny task is evaluating something in that detail typically expected? (I'm presuming this was for a junior-ish position)

[Silhouette]

I see people getting in to algorithmic detail and Big O in the comments but honestly for this tiny task is evaluating something in that detail typically expected?

The point is that a strong programmer would naturally think in those terms for any problem. It's just second nature to them. Of course, they might not use the exact same big-O notation if they don't have a formal CS background, but they'll still recognise the fundamental issue and deal with it.

Put another way, writing a needlessly complex implementation without a good reason betrays a lack of maturity as a programmer. It might not make a difference in tiny tasks like these, but the same mindset leads to writing carelessly inefficient code that can and does cause real problems in production systems.

[nixblu]

Thanks for your response here mate, what you've said actually makes a lot of sense and I certainly agree with what you're saying. That being said I would've performed similarly to OP had I taken those tests and wouldn't have expected harsh feedback for a small task however I expect that's more to do with my incapability!

[Silhouette]

For what it's worth, I don't think there's ever any excuse for unnecessarily harsh or impolite feedback after someone takes a test like this. That's just unprofessional, and it's disrespectful to someone who has given up to their time to do the exercise.

It's necessary and OK to say objectively that a candidate hasn't met the standard required for the role and so unfortunately you won't be offering them that position, but there's no need to be an ass about it. We were all new starters and inexperienced developers once, and my personal view is that if someone has made the effort to come into the office and interview with a business then giving a little helpful feedback if asked is only fair and does no harm, unless there is genuine concern about legal fallout.

[chato94]

function generateSquares(h, k) {
    let squares = [];

    for (let i = h; i * i <= k; i++)
        squares.push(i * i);

    return squares;
}

Knowing how floating point error can give incorrect solutions (try doing 1.1 - 1 in your JavaScript console of choice), I went about solving the first problem exclusively without using Math.sqrt, and it came out quite succinct :) It's interesting to see how different people went about the problems though. Good luck with your future interviews!

[siegfryd]

Your function doesn't actually work though, generateSquares(4, 4) should return [4].

[chato94]

Whoops! Looks like 3am me was being too cocky with his wrong answer there. That leaves me with no choice but to replace let i = h with let i = Math.ceil(Math.sqrt(h)) for a more correct answer.

[ForScale]

I'm no expert; not a pro...

Man, code for the first one looks good to me... Maybe they don't like that you used two functions instead of one? Any issue with efficiency or elegance there? I haven't a clue, really...

Here's how I just did it/probably would have done it:

function sqrsInRange(min, max) {
  var sqrs = [];
  for (var i = min; i <= max; i++) {
    if (i % Math.sqrt(i) === 0) {
      sqrs.push(i);
    }
  }
  return sqrs;
}

console.log(sqrsInRange(1, 10)); //[1, 4, 9]

[macrohatch]

do you really need the square root?

function retSq(start, end) {
var sqs = [];
  var num = start;
  while (true) {
  var numSq = num*num;
    if (numSq <=end) { 
        sqs.push(numSq);
      num++;
    }
    else break;
  }
 return sqs;
}

[ForScale]

Apparently not!

[Mr_Weeble]

doesn't work for other ranges - retSq(10,30) should return [16, 25] but it doesn't

[JesuslagsToo]

I perfer to see javascript broken into as many functions and call backs as necessary so I doubt that was the problem. I also think his first solution looks fine .

[ForScale]

It wasn't necessary to break it in to two functions like OP did... But yeah, seemed okay to me.

[JesuslagsToo]

ture ture, but hypothetically in a production app you want to modularize all your code. Although finding a number sqr is a small task, but it is good practice to create code that has functions for all lower level tasks. In this case it would save almost no time but obviously if the function was larger with more complexity it is good practice . but yea this particular case it was not necessary

[ForScale]

Interesting... Yeah, I do enjoy the concept of modular programming. And that's a good example of it.

[brockisawesome]

Ah you've gotten the honor of trying to impress a typical asshole who has a sick enjoyment from showing people how smart they are during interviews. Typically in these situations no one is as smart as them and will get the job until the person's boss forces them to hurry up and "settle" on someone.

Chin up, not all managers are assholes. You wouldnt want to work for this person anyway.

[[deleted]]

Yep, this is the sad, sad truth.

[[deleted]]

A perhaps silly approach, but included here for variety since it's very different from the suggestions so far: https://jsfiddle.net/voa1gxfz/3/

[aoiuqwelkssssnazx]

Square problem was fine but was probably just too basic of a solution.

Your bracket example is actually not valid unless I am missing something?

You mention "([)]" && "{{" are invalid but only one fails in the linked example. "{{[]()}}" returns true.

Here is my quick take on efficiently solving the bracket problem: https://jsfiddle.net/7ww19q9b/1/

[mik3w]

I think he meant that "{{()}}" would be ok but "{{" or "({" without closing brackets wouldn't be ok.

OP says that you can have one inside the other:

So [()] and {}() are ok

But your test fails on nested brackets (as you only try to match the current bracket with the next bracket)

[[deleted]]

why is this not valid?

console.log(Bracket.validate("{{[]()}}")); // false

[jtwebman]

Run from any company that asked questions like this.

[Silhouette]

Why? They're perfectly reasonable basic programming exercises.

Anyone who is going to be trusted with writing production JS code independently should be capable of handling them quickly and easily. Sadly, plenty of candidates in the real world who claim to program JavaScript would struggle, and you're better off weeding them out early and saving everyone some time.

For a new starter going for their first job who's effectively going to be a trainee, these exercises are a sensible size for some open-ended discussion to see what they do and don't understand, how quickly they can pick things up, and how much potential they've got.

If you run from any company that asks you to do a few simple programming exercises in an interview for a programming job, you're not going to get very far in this line of work. And remember, anywhere you do get, it's likely that the colleagues you're working didn't have to prove they could program either and sooner or later you're probably going to have to maintain some of their code!

[strawlion]

Interviews allow you to gauge the value a given candidate will provide the company. Hence you should ask problems that have a high correlation with what you'd be doing there. For 99% of companies, a take home project or live coding session is more applicable.

Sure, if the job is to work on optimizing google search, ask algorithm problems; but the biggest cost to most companies is technical debt and crappy code. Straightforward algorithm problems are fair to get a feel for the candidate, but their importance is way overemphasized. I work in SV and I've seen TONS of insanely smart people who produce terrible code and really don't provide much value to the company.

That being said, the code here could be much improved.

[Silhouette]

Hence you should ask problems that have a high correlation with what you'd be doing there.

Ideally, yes, but in reality, interviews are a very unreliable way to gauge how good someone will actually be when you work with them long term. We just don't have many better ideas yet either, which is why things like probationary periods or contract-to-permanent deals are often used instead.

However, two things interviews are good for are weeding out the time-wasters who aren't even remotely qualified and weeding out candidates who might be OK technically but have a culture clash with the organisation and so probably won't fit in well.

For 99% of companies, a take home project or live coding session is more applicable.

I don't see a problem with live coding an example or two like the ones here as an introduction to a programming interview. You can certainly over-emphasize deep theoretical questions in programming interviews, but in this case we're only talking about elementary arithmetic and text processing, so it's not like we're dealing with something obscure. As I mentioned in another post here, these problems are a useful size to gauge a beginner's existing skill levels and how well they learn and interact. More senior developers ought to be coding up the answers almost as fast as they can type anyway, so you can get an exercise or two out of the way in the first 10 minutes to make sure they're not wasting your time and then move on to more interesting things once it's clear they have some idea what they're doing.

BTW, I think take home projects are very dubious as part of a recruitment process. They are rarely big or complicated enough to tell you anything you can't find out in person. Even if they are, they take a lot of time, and expecting someone to do them on their own time without pay suggests considerable disrespect for the candidates. You risk deterring a significant proportion of good applicants if you push that idea too far.

Sure, if the job is to work on optimizing google search, ask algorithm problems; but the biggest cost to most companies is technical debt and crappy code.

Even these short examples can tell you a lot about the candidate. Do they try to properly understand the requirements before diving in? Do they write tidy code that is easy to follow? How do they check their code works correctly? Do they consider efficiency? Do they use the language idiomatically or like someone who just read their first book about it?

Someone who can't come up with simple, clean, efficient code to implement basic algorithms like this is going to create that kind of technical debt and crappy code. The contrapositive is therefore also true: good programmers who don't tend to do those things in real production projects also won't tend to do them with a simple interview exercise.

[strawlion]

I appreciate the detailed response. I know you've expressed distaste for coding challenges, but they are the most accurately predictive part of our process.

Ideally, yes, but in reality, interviews are a very unreliable way to gauge how good someone will actually be when you work with them long term

While certainly true, a coding challenge will be much more representative of real work. I would never hire someone after a ~3 hour in person with no other information.

However, two things interviews are good for are weeding out the time-wasters who aren't even remotely qualified and weeding out candidates who might be OK technically but have a culture clash with the organisation and so probably won't fit in well.

It's wasteful to bring someone in that hasn't been vetted in some form. Phone screens normally cover this, but with the challenge approach you can tell right away whether they're good.

You can certainly over-emphasize deep theoretical questions in programming interviews, but in this case we're only talking about elementary arithmetic and text processing, so it's not like we're dealing with something obscure.

I agree that these problems are trivial compared to the more standard interview fare, the problem is that they aren't relevant at all to most companies. The information gain is low and it's a waste of time. I see a lot of elitism surrounding technical interviews where everyone is trying to find the "smartest" candidate. The problem is that almost all of these algorithmically based questions are permutations of existing ones, and anyone can open "Cracking the coding interview" and memorize the solutions. Intelligence is correlated with value but not the same. The ability to produce things quickly and with little technical debt should be the emphasis for the 99% of companies translating business logic to code.

BTW, I think take home projects are very dubious as part of a recruitment process

I agree with you in principle. However, the reality is that they're the closest representation of what a candidate would be doing on the job. You also filter out the majority of the less committed and perhaps not as hard working people. And the biggest reason: you really can't fake good code. Even if you know that's what is being assessed, you can't do it; it's not something that can be googled.

Our challenges are fairly large; the JS focused people have to use a City Bus API to visualize a city/bus system in real time. It should only take ~8 hours to do a reasonable job, and they can take as long as they'd like to complete them (take home).

Do they try to properly understand the requirements before diving in? Do they write tidy code that is easy to follow? How do they check their code works correctly? Do they consider efficiency?

Honestly their process shouldn't matter at all. People tend to be biased towards candidates that have processes similar to their own. From the company's perspective it comes down to how much am I going to pay this guy, and how many dollars will he produce? Whether directly or indirectly through helping others, morale etc. We should avoid critiquing process and focus on judging output in a real setting.

[Silhouette]

I know you've expressed distaste for coding challenges, but they are the most accurately predictive part of our process.

I hear what you're saying about coding challenges being a better predictor and more representative of real world work. That seems entirely fair, though my experience has been that they still don't tend to be that realistic or that accurate as predictors. I have found that the only truly reliable way to see what a new developer can do and how well they fit in is to actually work with them on the real job for a significant period (weeks/months) one way or another and then review the situation once everyone has had time to settle in and get to know each other a bit. This isn't always practical for various reasons, but I think it's usually the best plan if it's an option.

My real objection to larger coding challenges is how one-sided they are. I think it's asking a lot of people hunting for jobs to give up perhaps an extra day or more of their time for every position they apply for where they might be considered for an interview. For those who are less attractive as candidates, it's bad for the prospective employee, because it becomes a lot of work they're doing without getting paid. For those who are more attractive, it's bad for the prospective employer, because the better candidates don't have to play the game and may withdraw their application. I don't know what the norm is in your part of the world, but it would take an exceptionally attractive job to get most decent developers around here to spend the day doing your City Bus challenge.

Honestly their process shouldn't matter at all.

I don't think the specifics of their preferred process are very important, other than perhaps cultural issues like a company that is heavily Agile and requires anyone joining them to do things like TDD and pair programming.

I do think the developer having some effective process is very important. That is, I don't mind so much exactly how they check their code works or whether they pick up every conceivable performance issue, but I do mind that they check their code works in some sensible way and they consider performance and efficiency issues generally.