I don't care about your code challenge
blog.mattbasta.com
blog.mattbasta.com
Here's the gist of how it went down:
1) first part was the "personality" interview. Two "HR" people blew smoke up my ass for about 30 minutes about how awesome my site and my work was, then asked me to do a "code challenge". I agreed - I mean, how bad could it be?
2) The code challenge. I was given a PSD with a straight forward design. Asked to code it, make sure it worked in legacy browsers, publish on a server and show them the code on GitHub
3) Passed and then was asked to come back and explain some of my coding decisions. I was told this was more for show and I was already in effect hired, I just had to pass this last hurdle. It turned out to be a very confrontational, inquisition type of an interview. Not at all the type of laid back code review I'm used it.
I got pretty frustrated by the two "Senior" devs who seemed to take great pride in tearing my code and my decisions apart. After my first heated exchange with one of the devs, I actually asked them how many of the sites listed in the gallery on their site they actually tested and validated the code on. They said "All of them, why do you ask?" I told them I actually ran all of their sites through the W3C validation site and none of them passed. Every single one had over 60 errors on it. I basically said, "If standards are so important to you, then why are you holding people who don't even work for your company to a higher standard than those who actually do?"
There was a long silence and then I finally spoke up and said, "Clearly, this company has its priorities in the wrong order. Thank you for time, but I'm not interested." and got up and walked out.
I got several worried calls from the company recruiter, but by then I was so pissed at how much of my time they had wasted, and vowed never to do something like it again.
Two possibilities:
a) You got a glimpse of how your life on the job would look like.
b) Just like qualified specialists can be terrible interviewees, they can be terrible interviewers. They just screwed up.
Well, you want to hire people who are better than you, not worse than you. Hiring bar at a good company should go up, not down, as it grows.
The problem was - A man has to get a fox, a chicken, and a sack of corn across a river. He has a rowboat, and it can only carry him and one other thing. If the fox and the chicken are left together, the fox will eat the chicken. If the chicken and the corn is left together, the chicken will eat the corn. Write a program that will help the man make the correct decision and explain the operational complexity.
I was given an hour to come up with a solution. I worked on it about half-an-hour coming up with the algorithm. And then for some reason my brain keyed in on the "write a program" part of the question. So I wrote the following in C++ (from memory so may not be exact) -
int main(int argc, char** argv) {
std::cout
<< "Man takes chicken, leaves fox and corn, and returns" << std::endl
<< "Man takes fox, leaves corn, and returns with chicken" << std::endl
<< "Man leaves chicken and takes corn, leaves corn with fox, and returns" << std::endl
<< "Man takes chicken back across" << std::endl;
return 0;
}
Must have been an OK answer because I got flown up and ended up working for them for 4 years (before a series of bad jobs that have finally lead back to something good).
Sure, if you ask no follow-up questions after the challenge is completed. However, with a few well-placed questions about the implementation and some inspection of the code, it'll be quite clear whether you're talking to the author or not.
We once gave a (non-web-dev) programming "challenge" (I thought it was a joke/insult given the candidate's claimed experience) to a senior dev candidate. Mind you, this was on-site. I even tested it by putting our newly hired grad to the test and he aced it within 20 minutes. We gave the candidate an hour to complete it (and added a 30 minute extension when he was struggling).
The challenge involved developing something against an SDK (interacting with a camera) and we gave him internet access and the SDK examples to work off of. In the end, he produced something not quite what we were asking, but he was sure to claim it as his work. Although it wasn't ideal, I was prepared to say that he "passed" the assignment, because he was close and I was sympathetic to factors of stress and nervousness.
As he was toured around the facility, I inspected the code and saw that he was completely passing off one of the SDK examples as his own work (diffs showed only two variable names had been changed). The reason his code didn't quite do what we wanted, is that he wasn't even able to tweak the SDK example to do what we asked. He was a complete fraud and never mind technical ability, we couldn't have dishonesty like that on the team.
Before that interview I thought those kind of challenges were a joke, but after this I saw their value. Of course, their value depends highly on how their are implemented and targeted, but dismiss their usefulness at your own peril.
These are all relevant details, because except for the most trivial of SDKs and their appropriate domains, a thoughtful, skilled developer might spend an entire hour simply reading through the SDK and/or its documentation to get a handle on its capabilities.
So I don't get that your story is an anecdote in support of the potential usefulness of code challenges. Instead, what I gather from your story is that your company prefers candidates who practice cowboy, shoot-from-the-hip programming instead of thoughtfully approaching a new, unfamiliar SDK and pondering how it might be used to solve problems related to the domain it was built for, then applying this thoughtful process to provide a solution to a problem. In fact, if I'm given a non-trivial SDK and told "write a program that does X using this SDK; you have one hour", my response might be something very similar to the above, directed at the person giving the "assignment" out, followed by a polite but firm indication that the company doesn't meet my requirements.
I wanted to avoid writing a novel, so I left out some of those details you're interested in. Trust me, when this "test" was first suggested, I was wary of it myself and did everything in my power to make it very achievable. That's why I considered it a joke, it was not nearly difficult enough to assess the level of seniority this candidate was claiming. This was someone with 10+ years of development experience, in the same field, experience with the language and environment we used. On paper and even on the phone, he made himself sound like the perfect candidate. In fact, before the on-site interview, I thought he had it in the bag and was excited to get some help on the team.
The SDKs in question were for a camera (to get images from the camera) and OpenCV, which is well known in imaging circles. The test was to receive a video stream from the camera (there was an example showing how to do this and I made it clear I didn't mind if he made that example his starting point) and to subtract consecutive images to create an image representing the "difference" between the two images. Not a meaningful result and one could barely call it image processing, but it would show us the candidates abilities to interact with multiple well-documented SDKs to accomplish a very simple task. If someone who claims to have years of experience with image processing can't accomplish subtracting two consecutive images and drawing the result to the screen, given all the tools to do this, there's a big problem.
Our new grad was mostly a tester and an occasional developer. He had less than a year of experience. He completed in 20 minutes without supervision.
>Instead, what I gather from your story is that your company prefers candidates who practice cowboy, shoot-from-the-hip programming instead of thoughtfully approaching a new, unfamiliar SDK and pondering how it might be used to solve problems related to the domain it was built for, then applying this thoughtful process to provide a solution to a problem. In fact, if I'm given a non-trivial SDK and told "write a program that does X using this SDK; you have one hour", my response might be something very similar to the above, directed at the person giving the "assignment" out, followed by a polite but firm indication that the company doesn't meet my requirements.
While I am fully aware that there are severe limitations to the usefulness of a test like this, in this situation, it saved us from a terrible hire (this test wasn't the only indication that he wasn't who he claimed to be).
In all honesty, you sound like a fairly thorny/difficult person to work with and in your hypothetical scenario where the test caused you spurn the position, it would have inadvertently done its job.
What are people worried about? I have to say I can't help but assume the worst. Because what have they been doing for their career as a professional programmer, if when asked to actually write a program, they can't actually do it? Even with an example right in front of them?
Don't forget that in this particular example we have a supposed senior programmer! Somebody applying for this sort of job should, I feel, be able to actually program. Even if they've never seen the library before. In fact good candidates should be barely fazed by an unknown language! What is the "senior" bit for, if not this? At the very least, perhaps the candidate could admit that they seem to have found themselves interviewing for the wrong sort of role, and one that makes better use of their other skills would be more suitable? That might be a better tactic than storming off in a huff.
But I've never stormed out of an interview in a huff - so what do I know.
Put another way: it's just as unreasonable for a company to expect a developer's skills to be measured by contrived tests or to demand they spend any unpaid time at all doing "work" (e.g. projects), as it is for a candidate to expect a company to effectively kiss his butt and lay out red carpet just because he decided to apply.
This functionality is pretty simple, but it still took many hours to code. My feeling was that they thought it would perhaps take an hour to do. It was fun and interesting to do, but it took much longer than I thought. I think the companies giving the challenges should have their own engineers do the task, so they get a good handle on how much they are asking from the applicant. And of course it also depends on if it is a buyer's or seller's market (jobwise that is, not in terms of my "trading" system). If there is a lot of competition for developers, maybe they should give too big projects.
a) If you are trying to hire 5 engineers, say, you need to talk to ~25 candidates at least. It's a competitive market. b) If you aim to talk to 25 candidates in a short period of time, you need to have SOME standard way to evaluate candidates if you don't want to just throw darts on the board. Being sloppy with process is bad for companies and the engineers and a waste of everyone's time. c) In order to create a standard process, you have a very limited # of options to work from. I've seen comments like "do a co-working day to get a real sense" or "do a contract and see them work with you daily" positioned as realistic options. They are not. If an engineer has an existing full-time job they don't have the time to do co-working days or contracts. d) The other options are 1) whiteboard interviews 2) coding challenges 3) some combination thereof. e) Lots of candidates hate whiteboard interviews. Lots of candidates hate coding challenges too. Neither is a perfect system but it's better than doing nothing or asking for co-working time. f) We use coding challenges at the top end but we time-box it to 3 hours. If someone asked us to pay for the time, we would happily do so. g) Our coding challenges have 3 different problems so candidates can pick whichever aligns best to skills. One problem is JavaScript-heavy and 2 others are Ruby/Rails-heavy. h) Several engineers on the team solved the coding challenges on a timed basis before we put them out to candidates. Doing otherwise would be stupid/unfair. i) In the few cases where we've been able to do 1-2 co-working days, we have offered to pay for the candidate's time. Not full freight consulting dollars but something that indicates our seriousness. j) In this case, the OP got caught by a dumb coding challenge to build a full website. But the headline paints with a broad brush because coding challenges by themselves are not evil. They are a tool that can be used well or poorly. That's all.
1. You're dead wrong if you think employers are always getting more out of the employee. It's a mutually beneficial relationship and a free, highly competitive market in SF. If poorly treated, candidates bail and current team members do too.
2. We aren't talking about profits at all. This confuses and conflates eventual profits with employee salaries.
3. Nothing that I said indicates that we treat them like they came out of school. If you have a better alternative, I am all ears.
4. We don't want to do it quickly and cheaply. We want to do it as best as possible under our constraints. We're a small startup.
Good luck to you as well and thanks for flipping the bird. So mature!
I wasn't trying to get you to work with me but thanks anyways!
Standard processes are important, but they need to respect everyone's time.
I agree that companies have to be respectful of candidates' time. People do talk to their friends before they engage with companies or accept offers and word can get around fast if companies mistreat candidates (as it should).
"I'm not equipped to do your challenge" - really?
"Engineers aren't different" - again, really?
Rhetorical question: you don't want the job, do you?
I am not sure if the issue is with the hiring process, or with the candidates' ego here. Candidates. Plural. As the article's author doesn't seem to be the only one.
Apparently there is a lot of people that believe they are rockstars and they don't need the job, the job needs them. Challenges like this help to figure out non technical skills as well, like: how committed a candidate is; how much he wants that job.
I'd rather hire a junior that is committed than a senior that is not.
Your boss may like you, but your company couldn't care less if you were hit by a bus tomorrow. Sure, you'd get a mention and a small office party with stale cookies and cheap pizza, but you'd be forgotten within the year.
Personally, I've asked potential hires for work product demonstrations. However, two crucial differences: 1) I paid them for their time, and 2) the task was on a real part of our infrastructure, the code they produced eventually being used in production. Everyone was happy with this situation.
I think the long and short of it is that being committed to a job has nothing to do with whether you'll tolerate a code challenge. Being "committed enough" to finishing a task to unlock the gate to actually speaking with a company's engineering team is completely orthogonal to how much you care about what you're paid to do when you have a job.
Here's a novel idea: both the candidate and the job need each other. If the job didn't need a candidate, then why are you looking to hire someone new?
Humility goes both ways. So does the arrogance. You reap what you sow.
I'd rather hire a junior that is committed than a senior that is not.
As long as you're prepared to deal with the difference between the output of a junior and the output of a senior, then you're okay. Word of advice, though: you'd best hold on to your own seniors.
We're sorry, but what you produced is not good enough. We're not going to tell you what you missed.
At least technology tells you what you missed. If you have a standard, have it documented so that I'm not firing a bullet into the dark. Chances are I'm just as good as you; but you won't know because I haven't seen your coding style. You're on my project, you code like me. I'm on yours, you better believe I'll code like you.
And then there is the times they like to dismiss you for it but have some other reason and use it as a cover. So you worry about your code not being perfect and you develop a ritual to validate yourself before it goes through a compiler. Yep, I write my code three(avg) times now. 10 lines, over and over until it's a effing poem. It's called ocd.
Coding challenges, pfft, worthless. There is only one company that I did a coding challenge for in the past year and it's because they were really awesome people. - I'm here to make a product and work with a team. I'm not here to explain shit to you just so you can tell me to look up the documentation. If I take the time to explain my code to you, you better well explain why you think something is better rather then telling me to google it.
fufff, I needed that.
This is most interviews in general, and I hate that. When interviewing candidates I try to give actionable feedback to each of them, regardless of whether it results in whiny emails back (and it often does). There was only one case in recent memory where I couldn't because he'd gotten literally nothing right while bragging about how fun it was to write thousand-line functions. Eek.
The type of coding challenge a company asks (interview questions also) can be one of the most important data points to use to judge a company's culture...
(a) Short - 45 minutes to an hour
(b) Only as complex as necessary (for the front end we provide and end-point serving JSON, for example, so they don't have to worry about that)
(c) Real problems we've run into, distilled down into a form appropriate for an interview
(d) Made up of problems that we were having candidates do on the whiteboard before we developed the at-home test, meaning they're not super complex
I think that at-home coding is the perfect second step to an interview (after a phone screen). It's more realistic than whiteboard coding. You have the internet at your fingertips. You don't have the pressure of an interviewer sitting there. You have syntax checking. From my side, I don't have to waste 30 - 60 minutes on a bad candidate. And, assuming the code is good, reviewing it provides an awesome first hour of an in person interview. And the problems I give you to take home would have been given to you in person anyway, so you're not spending any more time than you would have if you'd just come in for an interview.
The issue here is that the tests he's being given are bad examples of a take home test, not that take home tests are bad ipso facto.
Our front-end test is a bit longer than the back-end test with a tradeoff of a shorter in person interview, but the front-end test shouldn't take more than 90 minutes.
One of our problems is a small matching algorithm. Another is a thread safety problem. The front-end test consists of pulling JSON data from a server, formatting it, and posting a single action back to the server. It sounds like we're in a minority though. Reading these other posts it seems like a lot of the tests are very onerous (build a small trading system? that is a ton of work).
Have you gotten feedback on the questions? It's easy to say that it's a valid question, but when you're close to the problem, it's easy to make a mistake since you might encounter a specific sort of problem that others might not be nearly as familiar with.
The difference to me I think is that yours are very specific, and "build a small trading system" can be very general. If it's timeboxed, there might be only so much that you can do--i.e. you might not be expected to complete the task. You want to test someone's knowledge, without being too 'in depth'. A candidate that can solve a problem on his own in 30 minutes isn't necessarily better than a candidate who can solve the problem in 10 minutes with the assistance of Google.
0.02
Nevertheless you should never agree to complete a full production project without being paid.
I built it. It worked. Then they said my application was not aesthetic enough and said thank you for your time.
The whole thing seemed backwards...
In my opinion (as someone who has been going through the process for a few years now throughout undergrad with internships and now looking for a full time job at the end of my masters), very few companies do the "coding" problem right.
I don't want to work for you if you ask me to write a nested for loop and regurgitate the overhead involved in searching a b-tree. I also don't want to work for you if you ask me to build a application with no pre-defined criteria.
In my opinion...the best coding question you can ask me is fizzbuzz types of questions or pseudo-code for something complex (to see if the candidate can think through the steps of solving the complex problem without having to waste the time solving it).
So far not a single company has done the below.
If I were a front end developer, I would much prefer to be asked to write a quick, tailored to fit within the time allotment (e.g. one hour) web site rather than answering obscure coding puzzles that probably have little relevance with what I'll actually be doing at the company.
As the interviewer, I would phrase it as: "Build as much as you can in one hour, with the following functionalities in order of decreased priorities: login, cart, etc...".
Then I would judge you on how much of it you built, how solid each of the features are, etc. In my book, you can choose to go broad (build a lot of features, albeit superficially) or broad (only a few features, but well designed, tested, clean code).
How can you be so sure? Were you there? You're essentially calling the author a liar without even pretending to have access to more data than that author. Thats just rude.
If you know something that the rest of us don't that would lead you to make such a forceful assertion, please share.
I'm sad to say that this is untrue, and that in writing this article I have not exaggerated the requirements in the least. I'm not going to name the company, but the requirements of the challenge indicate that it should be something you would be comfortable putting in production.
The "challenge" is a repo on the company's github. I'm sure you could probably easily find it with a bit of sleuthing.
I have had companies ask for an idea or some sort of feature to develop for the company and refused because it was essentially a "do some work for us and we might hire you" deal.
My opinion is that companies that think unpaid "code challenges" are a good idea don't respect my time enough as an individual to be worth it to work for. It's a signal that they're either going to have an awful work/life balance or that they are filled with unjustifiably arrogant "rockstars" in a caustic environment of petty elitism (or both). The latter signal applies especially if the company's product is some web "application" for the young-20-something set.
However, the coding challenges I've done for applications have always been in the vein of "solve this interesting puzzle and show us how you did it", not "do some boring day-to-day work, but do it for free".
With the exception of my current employer, who asked me to make a small static site with some JS oddities (about 6 hours total), they've all been fairly simple challenges just to get a grip on my thinking process, not really have me do the routine stuff.
Another small fraction of the comments are: I don't care if you can't do X despite being good or won't do Y because it's a big hassle - the bug is a feature and it filters out people who are not into our instasnapsocialmobileresponsiveapp. Get real guys, no one's that into you, some people are just desperate. Pretending that you're some prestigious company where everyone wants to work doesn't make it so - you have to earn it and if you get there, you won't have to pretend because you'd get so many resumes that you'll be forced come up with a quick way to be selective.
The secret to hiring is just like what pg said about the secret to VC investing - get better at distinguishing good programmers from bad ones so that you don't need to waste so much of everyone's time to make a decision. Being indecisive, after being clearly presented with enough information is a sign of incompetence.
Since then, publishing code samples became the normal thing to do, so we simply require code samples instead, and give out the coding task only when they have nothing at all to share with us.
If you're in the job market, publishing some sample code, even if it's just a throwaway toy instead of, say, a full blown OSS project, can be a great tool for people to evaluate you as a candidate.
What I do have is years of experience building mission critical applications that move millions of dollars per day in transactions, and I have a solid track record of being easy to work with. I am good at what I do and I work hard to be an asset to any company that employs me, and I work hard to be enjoyable to work with.
If you can't be good enough to figure that out from a conversation and looking at my track record, why would I work for you?
BTW, I haven't had to look for a job in over 13 years - although I've worked for several companies during that time.
I agree that companies are excluding people such as yourself with these coding challenges. That's their right, just as it is your right to not apply to any companies that require such challenges.
If someone is finding good candidates with a coding challenge, that's great. If someone is finding good jobs while avoiding coding challenges, that's great too.
I will say that there's some nuance implied in your comment that simply isn't present in any of the github/coding challenge blog posts that have popped up on HN over the last few days.
Whether a coding challenge is appropriate doesn't just depend on the company or the candidate--it also depends on the position! It's far easier to test junior/mid level skills than senior skills in a 1-2 hour task. Geez, some of the skills you mention above would be hard to test in a 1-2 day task.
When you are looking for esoteric, softer, or more senior skills (requirements gathering, or architecture), you need other ways of evaluating candidates beyond a code challenge. Things like what you suggest: conversations, references, etc. Of course, there are some "senior" folks out there who aren't great coders even though they talk a good game, and if coding is what the position requires, a code challenge is fine.
I work with several people who have over a decade of experience with "mission critical" applications and do not have the commensurate skills.
> If you can't be good enough to figure that out from a conversation and looking at my track record, why would I work for you?
Just because you can get something done, that doesn't mean you did it by writing well-thought-out, sanely structured, maintainable, readable, useful code. I mean, you probably aren't bad if you're bragging about yourself like this, but who really knows until the code is visible?
The language and environment we work in isn't known for high-quality coders. Quite the opposite. Filtering out the wheat from the chaff is basically a requirement, even for the people that seem good after a phone screen and an in-person interview.
At no point did I claim to 'just get things done'. YOU said that. What I wrote was that I have years of experience building mission critical applications (which, of course, I would not claim if I could not prove).
It's not hard to prove or disprove if someone knows what they are talking about. I view 'coding challenges' as a sign that the company is not confident in their ability to assess people. It's a red flag to me. It's an amateur move. It tells me a LOT about the company from the inside, and it's not good.
'Coding challenges' are for companies who don't understand the skill set they are hiring for. I've hired plenty of devs over the years as well - we've had some bad ass programmers who worked for us, and I never needed a coding challenge to figure out who to hire.
For me, personally, this would be the better choice to judge my skills - and probably would lead to better chances for me to get the job. I suck at these braindead trick questions that are considered 'clever'. I'm not comfortable around a whiteboard only, being grilled by one or more other people while thinking.
I'm not slow, not really anyway. But I'm faster and better the more I know about the stuff at hand. I'll be good on the job, I'll suck solving math puzzles that some guy just read about in a book that ranks high on Amazon's list of code puzzle collections..
So - I'm glad that there's both. The author obviously would've preferred to show his skills live, in a discussion. This guy here would be happy to hand you a (small, mind you - I agree with the time-sink argument) finished project and discuss _that_ afterwards.
That's not to say don't make sure people are smart. And the idea of proving coding skills is good too. But the manner has to be consistent with respecting the time and skills of an expert.
I had someone offer me a paid test. I refused because I am too busy.
By requiring coding tests, employers and managers may be accidentally selecting only desperate candidates.
I consider 4 hours to be a max. 45 minutes is a bit short IMHO and does not allow for including unit tests. Also, I believe that a good challenge should ask for a complete set of unit tests as well.
But a full working MVP is way overboard and is too complex for the hirer to make meaningful decisions based on the outcome.
Any challenge should be followed up by an interview in which questions focus on the solution as developed by the candidate. The why of choices and the intent are important factors, probably more important than the actual code.
Write a program to fetch some data from S3 using these credentials we made you, perform some analysis on them (algorithm question, generally with recursion) and then display the final output. And write a test for it.
We provide a stubbed-out Rails project on Github so they don't have to know all the details about S3.
With this we test three things:
1) Can they quickly find missing info on Google/Stack Overflow (S3 stubs)
2) Can they handle recursion? (Algorithm question)
3) Can they write a test?
Then we go over their submission on Skype. It's worked pretty well for us.
1. Company A sends me an exercise with slapped together and near nonsensical instructions, no browser compatibility requirements, and a link to a data API that doesn't resolve. Keep in mind this is an established company offering big bucks. After getting them to send me a link to a working API, submit perfectly functioning implementation with squeaky-clean code (~2 hour exercise). Receive absolutely no fucking feedback whatsoever - I only know that I was explicitly rejected because the 3rd party recruiter eventually told me. Still would love to know what they took issue with (maybe they were offended when I asked for clarification on their washy challenge?).
2. Company B sends me a ~5 hour Ruby coding exercise for a JavaScript position.
In both cases, a complete lack of respect for my time has been demonstrated. How naive of me to think that the quality of companies out here would be better. I'm thinking of calling quits on getting a new and exciting job out here already. Don't get me started with the other pieces of interview "process" of encountered. Yeesh.
However, I've had two coding challenges which I did not like. In the first was just too time consuming (more than 3 hours) and I stopped working on it because I felt it was taking too much time, and the second was on-site without an internet connection where when I drew a blank on using setInterval, and couldn't remember document.getElementsByClass (I was trying getElementByClass) I was unable to look-up the answer, which basically meant I had to sit there wracking my brain trying to remember and completely failed a test which would have been a walk in the park otherwise.
At the same time, the two companies that I've chosen to work for have not asked for coding challenges. My current employer did look at my GitHub profile, I don't think my previous employer did.
I think that supplying sample code should be enough for most employers, hopefully there is a way to confirm the applicant wrote the code they are taking credit for (I've had somebody claim to build one of my sites before, so it's happened. I got a bunch of e-mails by people asking me for a reference).
Another good way for businesses to decide on a coding question (if they decide to do one at all) is to take questions from larger successful technology businesses. I had one company ask me to complete one of the questions from Spotify https://www.spotify.com/au/jobs/, it didn't take very long at all (may 40 minutes) and if it is good enough for Spotify, it is probably good enough for your company.
I recently completed a code challenge, and I was told by the recruiter that there were "problems with it," but he didn't get into any specifics because he was just passing on the message, and no one else has called either. I look at it as a dodged bullet, since it's a sign that they don't respect my time. I expect that had I gotten the job, they wouldn't have respected my free time or created a good work/life balance. Regardless, it has left a bad taste in my mouth. After I've spent about 12 hours of my free time (in addition to my 40 hr/week job), the least they could do is give me 15 minutes of their time to call or write out some comments about it.
If we were to take a moment to think about the purpose of interviews at a high level:
Initial Interviews (Phone/HR/etc)
- Determine mutual interest - Estimate likelihood of match - Check for red flags
Follow-up Interviews (With team/Code Challenges/etc)
- Confirm initial impressions - Evaluate finer points of fit (skills, etc) - Determine final interest
Each of the interview goals above apply to both the interviewer and interviewee. Failures happen when either side tries to monkey with this formula too much.
If your job is to write code and be an engineer, it's not outlandish to think that you'll be asked to write code as part of your evaluation for a new position. It's also not too much to expect that as an interviewee, you should be properly sold on the job by the interviewer before being asked to invest time to prove your skills. (Both sides should estimate high likelihood of match before confirming impressions)
If the company's preference is to hire full-stack engineers into front-end jobs, fine — more power to them. But those expectations should be included way up front in the process, so candidates like OP can mark a "red flag" and opt out of additional interviews.
TL;DR: Properly setting expectations in the interview process is ultra-important, but rarely practiced.
Note: I'm the founder of Mighty Spring (https://www.mightyspring.com), an anonymous, passive job discovery site. Part of our service is to help our clients (companies) hire more efficiently by coaching them up on interview process improvements like this. We're in private beta now, but send out new candidate invites regularly.
There is a serious point: companies often aren't forthcoming about day-to-day working conditions. But the response you get to your puzzle solving activities can be telling.
if you look great on paper (e.g. have some nice name brands on your resume, are a minor celebrity in some relevant community, or come in through a strong internal referral), there's no need for stuff like this.
however, if you don't fall into one of these categories, until there's a reliable way to tell if you're good from your resume, having an OPTIONAL coding challenge is a great way to get your foot in the door.
coding challenges shouldn't be about making people jump through arbitrary procedural hoops. they should be about making the (very broken) eng hiring process more meritocratic for people who'd never get their foot in the door otherwise.
I don't think there is anything wrong with the headline font. I'm not too fond of the link highlighting used on the front page, but it's fine. Really. And you can be a "front end person" and have very, very little to do with design these days. Entire webapps are made on the front-end.
As for the content:
I've dealt with numerous developers who only want to do one thing, only backend, only front-end, only design. I've constantly run into shenanigans when working with such people in a fast paced dynamic environment. "I can't work on the frontend till the backend api is finished", "I can't work on the backend till the frontend data requirements are defined", "I can't work on the frontend till the UI/UX are defined". It's a never ending requirements dependency argument.
More capable full stack people are able to mock or fake the bits that are as of yet undefined allowing them to continue working on their core piece while gaining a better understand of the system as a whole. This allows them to contribute to the product definition at all levels instead of just living in their own little piece of it, waiting for definition from outside.
> I have to
That's not true. You don't have to reply. No one is requiring you do that. You've already started off by lying. This means anything else you might want to contribute is awful and worthless.
> say
You didn't. You typed it out. I'm pretty sure you didn't "say" anything. And now you are trying to be confusing. That's just awful.
> , that headline font is awful
Well, that's your opinion. Your opinion is worthless because you haven't validated your credentials.
> and the link highlighting on the blog's front page is worse.
So, not the page we were directed to. Did you happen to check out his Facebook page, too? Did you decide to comment on his awful dinner choice last night?
> There is a bit of oddness
This whole sentence is odd. In fact, that sentence is far worse than anything the OP did. You would say it's awful. In this case, you'd be right, because it's a shit sentence.
> in declaring yourself a front-end person by talking about not needing to be tested as a back-end person
That's not what he's doing. He's saying he's a front-end person, and was tested for back-end work. He's not saying he's a front-end person by talking about not needing to be tested as a back-end person.
Those are two completely different things. If you don't immediately understand why, I apologize, but you wrote the awful and confusing sentence.
> when you're applying for a front-end job yet having a blog with a such a jarring front-end.
What's jarring about it? Surely you aren't speaking of the design. That would be a designer, not a front-end person. And we've established he's not apply for a designer's position.
Unless you are suggesting all designers should be expert programmers? Because that's the only way what you said remotely makes any sense.
Awful, just awful.