A few months ago I interviewed with Major CDN Company for a front-end dev position. They sent me a take-home React/NextJS project stub with dependencies and such already defined, and instructions to finish building out the full app. "Perfect!", I thought. No stage pressure, plenty of opportunities for going an extra mile. They encouraged me to get creative and I did; it met all the requirements and then some. I proudly submitted it.
A few days later I got an email saying, "Sorry, we're going to pass. The feedback from the person who reviewed it said that, 'It crashed with res.flat() is not defined when we tried to run it'".
"That's weird", I thought. I assumed they were running it in a different browser that lacked Array.flat(). Annoying, but maybe browser compatibility was part of the test (it hadn't been stated as such). So I did some digging just to be sure; I asked what version of NodeJS they were using. Version 10. Turns out that version of Node is somewhat old and doesn't have flat(). Huh. Dug some more.
.flat() wasn't even called in my code.
The stack trace went down into NextJS itself. They had given me a project with a particular dependency declared and then run it in an environment which was incompatible with that dependency, and then immediately punted it without any further debugging. I tried to engage my contact via email, presenting the proof that it wasn't my fault. I got an icy "Thanks for your feedback, we'll forward it to our hiring team", followed by silence.
My (somewhat charitable) interpretation was that either:
- The position had already been filled and they didn't want to bother fully informing me
- Both my contact and the person who "reviewed" my submission just really didn't care at all about the process and/or felt their time was better spent writing code than doing hiring (both people were technical)
For what it's worth, this was actually the second time I'd interviewed at this company, and the first time - while I didn't get the job - I went all the way through to the final interview and everyone I met was perfectly reasonable and nice.
Just reinforces the point from the article: an enormous factor in these processes is what kind of person you happen to be randomly assigned to on the other side. So don't take the results too seriously.
You need to be considered for sainthood, with how charitable you’re being here. It’s also possible for interviewers to just be wrong and incapable of seeing it, like the one who misjudged the runtime of code that I wrote and didn’t even have the toolbox to resolve such a disagreement.
Well, they might have claimed that but based on your account I'm having my doubts.
On a more serious note, I do find the attitude towards hiring in many companies perverse. I realise it can be time-consuming, frustrating, and draining, but at the same time it's hugely important.
Of all my responsibilities, Literally the most important is building a strong team: hiring is a critical component of that. We're always looking for ways to improve the experience for candidates, and I'm still involved in interviewing fairly regularly. I feel like it's important for me to set that example.
As with many things, if you're hiring and want to enjoy the results of making great hires, you have to learn to love the process somewhat.
To be honest I never understood this logic. Clearly a firm's skill at interviewing might diverge from their ability to mentor, innovate, have a great engineering culture and so on? Sure - perhaps it's slightly less likely, but it's not at all obvious that interviewing skill and company excellence are 100% convergent.
Well, from this example, management side was unwilling to even invest time in exploring or acknowledging the idea that they might be wrong. I don't know about you but I don't want to work with people who you can't have a reasonable conversation with to get to the bottom of a problem and figure out the issues together. Everyone makes mistakes, sorting them out together and achieving mutual goals is what makes this sort of work bearable.
If management doesn't understand collaborative working environments, humility, and basic problem solving, I don't (and will not) work with them.
If you have ever been in a situation where things were done to a standard of excellence, this type of excuse is simply unacceptable. People who have first-hand experience with environments that pursue excellence in earnest have little patience for such nonsense.
Kind of like the movie line "Failure is not an option." The line involves a bit of creative license, but was based on the movie people interviewing someone from NASA.
Sounds like poor internal communication structure to me then.
If the recruiter is from a third party it's a bit more forgivable (though I have gripes about this approach in general). I'd contact the company directly if I was working through a third party that stonewalled me. It's usually pretty easy to find recruiters public facing profiles to figure out how closely (if at all) they're connected to a given business.
This was definitely true at a past job which happened to be a fantastic place to work. The HR recruiting team was well-liked by the executives and run by a founding member of the company (so had a lot of power and autonomy). But they absolutely tormented us with things like not telling us a candidate had canceled until right before the scheduled time (we could find their emails in the recruiting software from hours or days earlier), scheduling individuals for multiple interviews simultaneously because they didn't care about our time so put it on us to find someone else to help, and occasionally forgetting to book a conference room forcing us to scramble and generally look bad.
The only satisfaction we got from the whole situation was reading the furious reviews the candidates would write on glassdoor.
I once worked at a company where hr would go for months saying there are zero candidates for x position. I finally escalated and got access to the database and there were loads of candidates. The issue was they were purposefully holding my req because they were sorting out a budget issue in another department. Even after that got resolved I literally had to go into the database, read them all, and then say this person, that person, etc..completely useless.
No, but their skill at being inconsiderate assholes almost certainly transcends the interview process as well as their engineering process. It likely permeates their whole organization. That's what I think the interviewee is looking at in this case and that's what was found. Unfortunately, fixing inconsiderate asshole syndrome is close to impossible. I wouldn't want to work at a place filled with them as described by this interviewee's experience above.
My opinion is based more on the final sentence than on the borked exercise.
Everyone makes mistakes. Character is revealed in how one handles it when the mistake is pointed out in good faith by a party who has a perfectly legitimate reason to do so.
If someone giving you an interview problem isn’t mortified that the entire premise of their result is invalid because they didn’t even bother testing the code, I would not want to work with them.
Yes, its a blessing in disguise to fail the interview at such a company, but it is kafqaesque, infuriating and leaves a bad taste. But I agree that’s the best way to think about it.
I remember once interviewing for a startup my friend was working at because I wanted to work with said friend. It was mainly a PHP/Laravel job, but I didn't care. I had a high opinion of said friend and stacks are just tools to me -- you can do good work in just about anything.
Go in for the in-person interview which goes extremely well, but talking to their two most senior engineers it seemed like they had just recently learned what OOP is and "drunk the Kool Aid". I found this extremely odd given that this was well into the 2010s already.
They gave me a take-home exercise which was basically to implement some feature with Laravel using established best practices. I turn in something that's clean, documented, with tests, using the documented best practices (like literally from the Laravel docs), and extremely performant (would scale to a high volume of requests). Functional style though, broken out into 1-3 line functions that only do one thing -- similar to what you'd expect from a Rubyist.
Rejected and they told my friend that I don't know how to code. My friend knew better and got a new job himself a month later and I went on to much better things.
" Functional style though, broken out into 1-3 line functions that only do one thing -- similar to what you'd expect from a Rubyist."
I'm pretty laid back generally and I'm willing to overlook many things, but I think this is one of those where I'd vote against hiring, since I'd never want to maintain such code.
Following the logic of algorithms would be for instance really hard because of having to jump around all the time.
That's not how that works out in practice though. When each function does one thing, the cognitive load is low and you name things appropriately that make understanding each function on its own easy. You can scan an area of code quickly and find problems without having to build the whole house again in your brain.
It's much clearer when you hit some unintended edge case then having to maintain a mental model of a huge function doing a lot of things.
If your way of grading someone's code is to make sure you can build the whole house in your head, rather than have an exhaustive set of test cases to validate your specification and a simple "each function is appropriately named and does exactly what's intended in the correct manner", then the grading method is the problem, not the code.
You're talking about something different now though: initially you were mentioning functions that are 1-3 lines in size, but now you're describing functions which do one thing, without talking about the size at all. I was very specifically criticizing tiny functions. There are two big issues with such functions:
* the overhead in LoC of declaring and defining the function is between 30-100% of the function body!
* like I previously said following even simple logic becomes an exercise in jumping around the code. Never mind the whole house, even a simple loop barely fits into a 1-3 lines function.
I had literally said "that do only one thing" in the section that you'd quoted.
I've always been talking about that.
LoC aren't a metric. We're not getting paid per line and we're not playing code golf either. It works, it passes tests and most importantly, it's easy to change.
As for the comment about loops, both the languages I mentioned have powerful map functions. The goal of keeping the functions small is to avoid nesting loops and heavy amounts of indentation.
You said you broke your code in functions of 1-3 lines, I offered an explanation why that may have not been well received in your interview. I understand that you don't agree with that and that's fine with me.
That's what names are for. I prefer to find _afterLeft_ spread all over the place rather than `x2<=x1` even if it actually increases code size by 50%. I can validate it only once, and if I stumble upon _aboveBottom_ I don't even need to validate it to infer what it means (left as an exercise for the reader).
This spaghetti line: `x2<=x1&&x1+w1<=x2+w2&&y2<=y1&&y1+h1<=y2+h2`, in my opinion, is much harder than `inside`.
x2 <= x1 is actually a one liner which could arguably be transformed into a one line function. OP was talking about splitting an entire program into 1-3 line functions, or at least that's how their sentence reads to me.
Haha, this mirrors my experience - once I was asked to write some embedded hardware driver, which required to run it under the RTOS in emulator, which they failed to run. They failed to run a simple qemu! I even provided them a shellscript to copy and run the required stuff. Surprisingly, I was hired nevertheless, because code "made sense", but still. I can imagine it's ubiquitous nowadays. Too many incompetent people decide on how to choose among competent people.
My company does a takehome project, but are completely understanding if dependencies don't work on different systems.
Basically, if the code looks right and you can show it working on your system, we're pretty understanding. The goal of a takehome isn't perfection - it's to demonstrate underlying abilities.
I failed a hiring code assignment because I didn’t provide a unit test. They didn’t ask for unit tests. I did provide various data samples to provide various end-to-end tests with documentation.
Now I abandon any interview that requires a code assignment. I have better things to do than mind reading or dicking around with subjective code style nonsense. If they are taking this seriously they will provide their grading criteria along with the assignment text.
You have demonstrated solid debugging skills and stated your case. That's usually harder to find than someone who can churn out code based on simple and well-defined specs. Because that's the easy part.
They probably assumed someone else did the debugging. People assume the worst in these situations because they haven’t bothered to learn about the person.
Good grief man... I’m saying they assumed the candidate phoned a friend for the answer and then fed it back as his own to save his application. I honestly have no idea what happened, no one does... but generally there are no do overs and that kind of sucks given he figured out why they weren’t able to run his code.
I think the situation was unwinnable. You've exposed their incompetence. Rightly or wrongly, most people can't stand being criticized. If there's a solution to that one it's a diplomatic one, not a technical one.
Be similarly wary to point out bugs in code reviewer's code. Unless you have a healthy professional atmosphere and multiple reviewers, your best course is to manipulate the reviewer into "coming up" with the idea for the bugfix from your ticket.
Life is not superhero movie and you have to deal with assholes on a daily basis. You can get away with what you're proposing if you already have an escape plan (another workplace). If they're your coworkers, following your first gut instict is bad.
A few days later I got an email saying, "Sorry, we're going to pass. The feedback from the person who reviewed it said that, 'It crashed with res.flat() is not defined when we tried to run it'".
"That's weird", I thought. I assumed they were running it in a different browser that lacked Array.flat(). Annoying, but maybe browser compatibility was part of the test (it hadn't been stated as such). So I did some digging just to be sure; I asked what version of NodeJS they were using. Version 10. Turns out that version of Node is somewhat old and doesn't have flat(). Huh. Dug some more.
.flat() wasn't even called in my code.
The stack trace went down into NextJS itself. They had given me a project with a particular dependency declared and then run it in an environment which was incompatible with that dependency, and then immediately punted it without any further debugging. I tried to engage my contact via email, presenting the proof that it wasn't my fault. I got an icy "Thanks for your feedback, we'll forward it to our hiring team", followed by silence.