It was a very easy proof of concept. Back then they used XSLT to convert clients’ homepages to an intermediary HTML-dialect that would then be rendered out to mobile phones and other devices according to their capabilities. That was before everyone had a smartphone just around the time the first iPhone was released.
The test was to write an XSLT that would convert one very simple HTML file into their dialect. They knew that almost no candidate would have ever touched XSLT before that. So they needed people who could learn quickly. My own entry was plenty suboptimal but at least it achieved the task. That was about two hours of work.
Pseudocode/general thought process walkthrough should be the only thing imo. Oh no, the interviewee forgot a semicolon, so he is trash at coding and is a no-fit is complete bullshit.
I thought my entrance test was far too easy, I only had to create a blog in my web framework and show doing the basics like validations, secure parameters, etc.
I learned later on that most couldn’t pass because they came from other languages and thought they could get by without knowing anything.
Although, now that I’m an interviewer, I kind of despise FizzBuzz, because nobody thinks clearly during a high pressure interview.
Whenever possible, I love to talk with a candidate about some concrete past source code they claim to have written. I’ve better luck putting the candidate at ease and then talking through their contributions to the code.
Of course, when I get enough candidates who shared source code, I don’t even invite the ones who didn’t share source code for an interview.
My boss once asked me whether their entrance test was too hard after several candidates sent him something that wouldn’t even run.
That’s an instant ego boost
Should working code even be part of an interview? Seems like a situation rife with abuse.
Need free contractors? Just put your code issues up as a 4hr take home interview test.
Just like leetcode - where you’re helping train the AI that will replace you while not getting a job.
It was a very easy proof of concept. Back then they used XSLT to convert clients’ homepages to an intermediary HTML-dialect that would then be rendered out to mobile phones and other devices according to their capabilities. That was before everyone had a smartphone just around the time the first iPhone was released.
The test was to write an XSLT that would convert one very simple HTML file into their dialect. They knew that almost no candidate would have ever touched XSLT before that. So they needed people who could learn quickly. My own entry was plenty suboptimal but at least it achieved the task. That was about two hours of work.
Pseudocode/general thought process walkthrough should be the only thing imo. Oh no, the interviewee forgot a semicolon, so he is trash at coding and is a no-fit is complete bullshit.
how the applicant thinks breaks down problems and handles how to answer them matters more than if the code is actually functional on the spot
I thought my entrance test was far too easy, I only had to create a blog in my web framework and show doing the basics like validations, secure parameters, etc.
I learned later on that most couldn’t pass because they came from other languages and thought they could get by without knowing anything.
Good old fizzbuzz. https://blog.codinghorror.com/why-cant-programmers-program/
Classic write-up!
Although, now that I’m an interviewer, I kind of despise FizzBuzz, because nobody thinks clearly during a high pressure interview.
Whenever possible, I love to talk with a candidate about some concrete past source code they claim to have written. I’ve better luck putting the candidate at ease and then talking through their contributions to the code.
Of course, when I get enough candidates who shared source code, I don’t even invite the ones who didn’t share source code for an interview.
One guy completed it, so it was just perfect