> You have ‘4–6 hours’ to design a slick product, with a memorable brand and cohesive working method. No one acknowledges the fact that in reality, you’re about to dedicate up to 5 working days on this task, with the potential for them to ghost you straight afterwards.
To make this more fair, why not let the designer work at the company's office, so the interviewer can actually see how much time it took, and the interviewee doesn't waste more time than necessary?
That's what's I thought too. At one of the companies I interviewed at, we had a programming task that could take max 4 hours. The interview was at the company itself.
Less convenient for people who have a different job at the same time though.
I won't spend half a day in your building without being paid. At home, I can split the task. Beside, 4 hours task is a bad joke. I interview at a lot of different companies. I have no time for this.
My policy, before finding a place I like and plan to stick around at, is no programming tasks. There's plenty of companies desperate to hire than you can be picky if you know your stuff. I also will walk out if they start up with those 'clever' programming questions that have nothing to do with the job.
You took out the time to go to some office. You just spent an hour talking about your hobbies and attitudes and the company's working culture etc. Then, a programmer asks you to balance a red/black tree. You do.. what? You angrily throw the marker on the ground, cry insult, and run out the building? No, right? So then what?
I see this repeated a lot on HN and I'm not sure I'd have the guts to walk out of an interview. To be honest, I doubt many people do.
In the current market there’s abundance of junior or mid-level developers from body shops applying to senior level positions. If you cannot stand from this crowd and shine by balancing the tree right, why someone would care hiring you? I can tell you plenty of stories about people who had impressive background and great soft skills, but in the end barely can do their job.
On a first date you don't do boring everyday stuff becouse you don't want to spend time on that.
My experience is that hireing descicion is so noisy that there are no reason to invest too much since the rate of sucess is barely increased anyway.
The more picky the employer seems the less reason to apply. It might be a internal candidate allready chosen or they are just hoarding resumés to keep recruiters occipied.
The decision is allready made from the from the first minutes ... but you can ruin it of course.
> If you cannot stand from this crowd and shine by balancing the tree right
I don't think memorization of an algorithm is what should make a senior level candidate stand out. Senior people need to be able to lead, mentor, self manage (this is a huge one IMO), and understand the bigger picture. "How do we avoid having to balance this tree at all?"
The role of the senior Engineer isn't to tell you how to balance the tree. You, or anyone you instruct to, can simply ask google that or use a library.
Their role is to ask why we need to balance the tree. You very definitely can't ask google that, and that's why you need to hire a senior Engineer.
It’s one of the ways, for sure. But it is really interesting to me how a person without deep knowledge of fundamentals can lead or mentor anyone while being on a non-management position? They are supposed to gain authority from their professionalism, but without theoretical knowledge they won’t be able to justify their decisions, and then what? What exactly they can teach anyone?
As a senior/lead developer with years of broad experience you don't need to remember details of every algorithm in existence. But you should keep information scrap in your head to guide you or your apprentice to relevant source of information.
"Hi <dev name>! I think we may need to optimize memory consumption of this distinct element counting code a bit; I remember there is some HyperLogLog algorithm which should help here... let's check how it goes... (reading Wikipedia page)[0]"
The last time I applied to a company, I ask them all of this. Something in those lines "Hello, I use your product FooBarTools everyday and it help me a lot. I really like it. It is nice piece of software. bla bla bla. I see that you have some opening positions in your careers page. bla bla bla. I would love to be a part of the improvement of FooBarTools. bla bla. What is your hiring process? What do you expect a senior/midlevel/junior should be able to do? bla bla. Thank you for your time. Have a nice day."
> I don't think I'd have the guts to walk out of an interview either, especially for a job I applied to first.
Have you no common courtesy? I terminate the process as soon as I find out I'm not a good fit for the company or vice versa, no matter who initiated first. Continuing with an interview when I'm sure I'm going to decline is just wasting everybody's time.
Not really in this case. If you go to the job you like saying that the shitjob offered you 2x the salary... and they call your bluff? Now what? Take the shit job you are not going to take? For that you could have bluffed with an empty hand anyway.
I was condoning lying about offers or salaries on offer, just that having more offers signals a perspective employer that you're a desirable candidate.
I've heard of companies asking for proof of other offers so saying so and so offered me 2x is a very risky play if untrue.
I just use recruiters to do all the leg work and tell them my requirements. Always had made sure to still bring it up during the phone screening. Only once had they brought me in and started with the quiz nonsense.
I have walked out of interviews as well. Sometimes the interviewer and I discover together that the recruiter we worked with didn't know their job, at all!
More often, though, it sort of was clear from the start of the interview that the company would not be a good fit for me. I would tell them so, and my reasons why I thought so, and leave after thanking them for their time.
If they ask me to do some simple programming task, I ask them if they have looked at my Github repository and what they think they will learn during the simple task they could not from my repository. If they do would have a good answer for that, for example they want to get to know my thought processes while coding, I am happy to oblige. But if they clearly have not looked at my Github repositories, nor have any inclination to customize the interview process, I tell that I do not believe in the validity of the process.
I have also walked away twice during the one-month trial period. Once the company was unable to find a project for me, even though they kept on promising there would be one for me soon. The other time I discovered I was unable to combine working full-time with finishing writing my PhD thesis.
Anyway, I also found that in half of the cases I walked out,
the other party did understand and accepted why.
Of course, it is easy to walk away when you know you will find a job soon anyway and even if you would not you will get some support from the government anyway.
A cute thing to do whenever someone sandbags you with trivia is to suggest going over to the developer desks and asking everyone in turn if they know the answer. If you find someone that does, you answered the question. If you don't, then you suggest doing a web search, and you have also shamed your interviewer.
If they don't wave you off at the suggestion, you also get to meet everyone and see their work environment.
I did. I walked into the hiring manager's office and he barely looked up while asking me to decode the complex declaration on the white board that wrapped twice. My departing words were along the lines of: if you and your team write code like that, this is not a match. So I left.
I remember an interview at Coinbase I should have walked out of. The first question was "what is the angle between the hour and minute hands of an analog clock at 3:15?" It went downhill from there.
I think you're totally right to walk out on puzzle questions. But if you avoid companies that make sure you can program, aren't you worried about the skills of your colleagues?
There's other ways to evaluate if someone can program. A "4 hour" take home test for example isn't a good one as they could easily cheat or spend more time on it. In person tests are often setup to test your memorization which let's be real, how many of us don't google stuff on the daily?
What I feel is more important is a persons thought process on how they approach a problem and come to a solution.
I can offer different perspective here: what about a task which also has some value for you? I rarely give tasks to candidates and only in cases where otherwise good candidate is not familiar with our technology stack. The task in that case is to build a proof of concept on that stack and requires fast learning and general understanding of software architecture. I always give detailed feedback on completed solutions. Even if the candidate was not selected, they still can take something from it and won’t consider it wasted time.
I would never spend 4 hours on a task after hours for a company I'm interviewing for, that is my time and I value my work life balance. It is my humble opinion that a serious interview should take max 1 hour.
If you don’t see any value in learning and trying something new, I can understand it. At the same time there are plenty of people who see it differently and accept such challenge, willing to commit much more time to this kind of task. Maybe it’s not the kind of the job you would be interested in, but then why your opinion on it would matter?
One hour interview cannot be more than just screening, when split 50-50 to give candidates enough time to ask their questions. It leaves ridiculously small amount of time to the really interesting technical topics. And this discussion is important: CVs are not trustworthy, plenty of people lie or exaggerate the facts — only a live talk can verify the necessary knowledge, experience and skills. It may not be enough, true, but hiring someone after barely speaking to him is unnecessary risk. And hiring someone without necessary practical knowledge and without proving the ability to learn quickly is the same.
It's not a marriage, it's a job, and if you can't screen someone in a hour interview then you're doing it wrong. Have two rounds of interviews, whatever, if a company wants me to learn some skill they need then they can offer training as one of the benefits of the job.
Working for this Ivan guy it's entirely possible. Jokes aside though, I've worked for great companies and each had an hour interview and things were fine, people that didn't fit the culture just left and I can't imagine dedicating 4 hours to one interview because frankly speaking I have better things to do and a company that values a work life balance will respect that and keep their interviews short.
if you can't screen someone in a hour interview then you're doing it wrong
Are you sure you meant to say what you wrote? I'm not aware of any place that has figured out how to properly screen candidates in one hour. If you know how to do it, please share, it would help all of us.
They are not selecting for individuals with an ability to do the job, punch out at the right time, and then live their lives.
Corporations love obsessive-compulsive workers who feel thankful to have the job, are willing to sacrifice personal time towards their business goals and would never dream to unionize or otherwise engage in collective bargaining. They want solitary and competitive workaholics, that's the whole point of 'homeworks'.
A.k.a individuals who accept whatever deadline is imposed onto them and work round the clock to meet it instead of telling management they failed to properly assign time and resources to the project.
Seems like a really obnoxious way to communicate though. If they want somebody to do their best work and really do not care how much time it takes them to get there, they should just be upfront about it: "You have until next Monday, good luck".
If that makes them look like assholes, yeah, I can see why someone would feel that way but at least they are clear about their intentions and not insulting anyone's intelligence in the process.
Are they though? Playing Devil's Advocate, I have a pretty good idea of what I can do in 3-5 hours of solid work. If I was hiring for someone to replace me and asked the same question, I'm fairly sure I could tell whether it had been 3-5 hours or 3-5 days.
It'd be more useful to know they could execute roughly what I'd expect in 3-5 hours. As in they think quickly, come up with something, get the basics down and are ready to progress or not.
...Of course, if they're doing it at home they could spend 3-5 days on something I'd spend 3-5 hours on and I'd never know...
As a general rule when I'm given a programming task that takes 4 hours to do then - IF everything I will need for the task is already installed on my computer and all dependencies bugs and so forth have already been taken care of in these things - it will take 4 hours.
Maybe the same situation applies in Design somehow? I mean yeah it takes 4 hours to make the product if you happen to have all the graphical elements you will be using already downloaded and organized.
on edit: although I have noticed a disappointment in some places that I have not done a lot of time cleaning up the code after writing it and making everything beautiful and writing a good readme to tell them everything to do and so on and so forth and normally I don't do those things because I spent more than 4 hours because there was stuff that needed fixing and anyway if they wanted all that 4 hours would not be enough.
Coding is like math homework. When your doing the math homework you know when your done, it's very obvious and anyone can check your work and clearly see it's either right or wrong.
Design is like a book report for English class, it's bottomless and can always be improved given more time, albeit with diminishing returns. Design challenges are evil and bullshit, you can poor hundreds of hours into a design challenge and still iterate further.
well that is sort of the point of my example - I am done with my math homework if the math works = I am done with my programming assignment if the program does what was asked.
But people complain that I am not done with the programming assignment if I have not made it DRY enough, or put in tests, or done a readme outlining more advanced than run npm install then do npm run start.
Programming assignments may not be infinitely improvable but they can often be improved, I just don't consider it worth the effort to improve the work before submitting
Agreed, unless they want a good polished solutions, meaning it has been refactored, has decent comments, is well tested, etc.... then it becomes a lot like design where the sky is the limit.
My wife got her first job in the states because of a take home design challenge. Other companies were wary of her because of her foreign degree and no US experience, and she was able to show off in the design challenge they gave her (she spent more time than estimated, but not incredibly much more than that). In this case, it really worked out for her.
Right. Someone asked me to make a small Javascript backend API. I spent a day installing a dev environment on my personal machine since I haven't worked not-at-work since I last upgraded. I didn't mind doing it because it was interesting, but taking that time would be a dumb reason to no-hire me over someone else.
This was actually my thought. Looking at the mockups he submitted, it is clear that this was 30-40 hours of work minimum. And depending how fast/slow they worked it could be much more than that.
If I asked a candidate to spend 4 hours on something and they come back to me with 40 hours of work, it isn't what I asked for. Despite it being potentially amazing, that person ignored the task.
A 4-hour task would probably yield 1-3 mockups. Maybe a launch/splash page, the home leaderboard page, and then a page showing the details of a specific user.
Even these 3 pages would be pushing your 4 hour time limit, but that is really the most I would expect.
So if I was interviewing and comparing candidates and one candidate submits a 40-60 hour project while the other candidates submitted a 4 hour project. I can't really compare the two. I would probably throw out the guy that ignore what I asked them to do by spending 40-60 hours of work on something I only wanted 4 hours of work on.
> To make this more fair, why not let the designer work at the company's office, so the interviewer can actually see how much time it took, and the interviewee doesn't waste more time than necessary?
I had an interview once where we were on the phone, I got the task, and they told me they'd call me back 2 hours later.
My last company they flew me from another continent to do a 3-days assessment, I worked with the team on a legitimate feature(that would be trashed after as they couldn't use the code because I was unpaid). I liked it, I met the team, I interacted with them, I did the task and got a job offer in the end.
All engineers at the company highly valued the 3 days assessment because we got to select great people to work with, but we were getting too many candidates giving up or false negatives, they eventually cut it down to 1-day despite our protests.
I'm not sure what country you're from or what country you flew to for this ridiculous 'interview' process, but it's one of the many things I loathe about this field...right up there with "rock star" and "ninja" coder.
Honestly it's stuff like this, that has me contemplating giving up this career path because there's just no more room for people in their 50s with 25 years of experience in information technology, who aren't willing to sleep at the office, drink your "insert trendy microbrew here" on tap, and suffer through a ludicrous ask like "we want you to work for three days for absolutely nothing to see if you're a good fit".
Agreed! Who has the time to spend on a 5-day long interview?
If you are traveling internationally, then you have to add 1 day of travel on each side of your trip. Plus the 3-day "interview" or challenge or whatever. So that is 5 straight days of interviewing for a job. That is actually asinine.
If you have a current job (most software developers do, especially the good ones) then that is an entire work week that i have to request off at my current job to go to unpaid work with no guarantee of getting a job afterwards.
I can't believe someone has actually done this. It is crazy!
FTA: You have ‘4–6 hours’ to design a slick product, with a memorable brand and cohesive working method.
I don’t think Google necessarily requested a full end to end product. A nice logo/app icon for the “branding” portion and some UX concepts can definitely be fleshed out in a single work day, especially with zero tech/biz requirements IMO.
Maybe you’d need to take an extra day just to brainstorm first... but actually pushing pixels, if this designer compressed his output a bit, could have happened in 6 hours.
My employer has sometimes given out challenges that take a few hours. We just ask the candidate when they'd like to do the take-home and email it to them on that schedule. Then they have to submit their solution within the allotted time. It's a nice way to make sure the candidate knows it really only will take a couple hours, because neither side wants the candidate to spend 30 hours on a 3 hour take-home.
I don't doubt that it's quite stressful for some people. In general, I think any element of an interview process is going to be stressful for at least some people, just given the stakes involved. That said, at least this guarantees it's not stressful and a big time sink.
Also, I do think that some people are able to complete it in a third the time, but I think the more useful evidence is that many candidates complete it and do a perfectly good job, some even with a healthy chunk of time to spare. If it were a totally unrealistic time goal I'd expect we'd quickly notice when no one finished.
It's not supposed to be fair. Interview questions are designed to differentiate candidates as quickly and broadly as possible. This is one where the notional goal of completing the project is different than the true goal of seeing how the candidate performs when given an impossible scenario.
The author of this article fucked up when he tried to pass off 5 days of work as an example of what he could accomplish in 5 hours. I am glad he was able to find inspiration from it, but for the success of his startup I hope he also is able to understand other, better ways he could have approached the interview task.
What a great launch story! I don't mean to reduce your experience to a marketing gimmick but I know that you intentionally crafted the story to be impactful and to coincide with your launch. Most importantly, though, you pulled it off really well!
I can't help but admire the way this was done :) I hope my launch story is this good.
Great job. One should always do the best work possible. If this means someone else rejects your efforts, it'll still be a tangible satisfactory memory that, like this specific example, could turn into something more.
Awesome to read about you turning this into your own startup.
One thing I came to think about regarding the "4-5 hours" and throwing 5 working days on it, is that, maybe as an interviewer it is quite obvious that you put more than 4-5 hours into it and what they were "really" after were the trade-offs you would have made if you put 4-5 hours into it. Just a thought.
Not Google, but similar company and can confirm. If you spend 5x the amount of time we suggest, it’s obvious and the expectations scale a lot, lot higher than if you just spent 5 hours.
This makes no sense for "product design". Just thinking about it, looking at existing similar products, before you even grab your napkin, takes 4 hours.
Yeah, it may translate into, "well, if I work with this person, are they going to spend way too much on details that I don't need and burn themselves out just trying to please me?" Part of working is being able to be assertive and say "ok, for only 4-5 hours, here's what I was able to do for you, so now let's figure out next steps".
Yeah, I hate hiring people who are interested in what we are doing and are excited to work on it.
It's one thing to accept that some people are busy and shouldn't be punished, a bout
are we supposed to only hire people who have zero excitement for the industry and job?
That wasn't really my point. My point is that when you are working on a team, it's a collaborative experience and if your superior asks you to do a task a certain way, there may be a good reason why. The exercise here may have been to see what ideas you could generate about the user experience and less about aesthetic polish of a final product. I got the sense from the post that the author spent a lot of detail in making it look aesthetically pleasing, which is only one part of user experience design. A larger part of it is design something easy to use and understand.
Sure, feel free to spend extra time on the take-home assignment to signal to the potential employer you are passionate, but that's a different thing.
Are you sure you didn't sign any NDA, preventing you from working on ideas you might get during interview? Google used to have pretty water-tight policy on outflow of ideas (but inflow was encouraged) during interviews.
We make our candidates sign an NDA before an on-site interview, but do so because of the risk that they see/hear some of our internal information during the interview process not to entrap their ideas.
They have nothing of the sort, as of last year. The ask politely that you not share the specific design prompts or your solutions, so that future candidates can't copy you, but they're all over medium anyway. There are no legal teeth behind the request.
This applies to the design prompt specifically, which is an early-stage take-home thing. I don't recall whether google had an NDA for the onsite interview portion itself, but I think their badge signin thing might have one baked in, and other companies of equivalent size had paper NDAs as part of checkin. Presumably they only care about you stealing the cool stuff you hear about, and you wouldn't be in danger for running with their (intentionally generic) interview prompts on your own.
(Usual disclaimer: IANAL, just a person who's worked / consulted several places and signed several NDAs in his life.)
Here's the thing: the NDA you sign when you go onsite covers the company's intellectual property. It might cover the interview questions they ask you, but if they're not paying you for the work you do as part of a take-home interview question, and if you're doing it on your own hardware - it's not theirs, it's yours, and they have absolutely no say in what you do with that work afterwards.
Moreover: if you are subsequently hired by the company, they still don't own the work you did on your own time and hardware. (However: if you continue to work on it while employed by them, they might then own that follow-up work. Check your employment contract carefully, and if you're in a position to insist that employers do not own your off-hours work, insist away.)
Now, if you're currently at another company, and you complete the interview task on their hardware, and especially if you make the mistake of doing that work during company work hours...well, your current employer might then own your interview work. This is a matter usually covered by your employment contract (and another excellent reason to read those carefully).
An interesting aside is if the NDA is bidirectional? In most interviews, the candidate would discuss their past experiences and past projects, which could contain sensitive information via unintentional leaking. Perhaps even a side project that the candidate is working could be covered with NDA. Thoughts?
Meta: I assume you're doing a website update at the moment. I prefer the blue! Though I might still use a white version on the homepage to remove emphasis from the header. Also, on you signup page it would IMO look nicer if you pinned the page footer (eg https://matthewjamestaylor.com/bottom-footer).
Thanks for taking a look! I actually have always had a different style on the landing page from the rest of the app. One was designed to be eye catching and the other functional. The landing page is probably due for a fresh coat of paint, though. I'll give some thought to pinning the footer.
That's fine, and probably works, but the other pages look better finished and the menus jump around, etc., which gives a "in progress" feel to the site IMO.
When people are turning their interview questions into successful companies, maybe it is time to start asking some easier interview questions. This is a visceral demonstration of how absolutely ridiculous interviews have gotten.
I call them low self esteem corporations, the interview process requires you to constantly flatter them and tell them how much you'd like to work for them. I have too much respect for my own time, what's important is on my resume and the rest they can find out in a short interview, homework assignments and cover letters are plain silly.
The top 1%-2% who are willibg to actually complete the challenge. Probably not even then, as some of the top candidates who do complete the challenge may hold themselves to the explicit time limit.
Or increase the performance of Gmail (or Google Maps!!) back to what it was. Funny how the two apps ran perfectly smooth on devices 10 years ago, but they struggle with the horsepower on devices today.
I think that is crazy. You can turn laundry folding into a successful company. It's not that the interview question bar is high, it's that the "what can you make a company" bar is effectively on the floor. This is good.
Also, OP launched on product hunt today. Calling them a "successful company" is generous if not outright false, though I wish them every success.
Stated less dramatically, what happened here is "I turned my design interview prompt into a real piece of software". That doesn't imply that google's interview questions are too hard. A software company asking for a deliverable that approximates software is sane.
I think the time that google demands for their take-homes is a bit much (explicitly, this is 4-6 hours. in practice, it's 20 to 30 if you want to deliver at high caliber). But the questions/prompts themselves are intentionally quite boring, and exist to see how far you can take it.
I found them to be pretty good. These kinds of questions depend somewhat on chemistry between candidate and prompt, so they ask more than one of them, which is great. The takehome I picked was the only one of the 3 offered I could even pretend to care about. Of the two asked onsite, one I felt I delivered on at only the most basic level, and one I think I could have credibly patented / raised a series A for were it a thing I cared to spend 2 years on.
>explicitly, this is 4-6 hours. in practice, it's 20 to 30 if you want to deliver at high caliber
This is a problem with a lot of take home assignments of many types (not just programming). If someone has landed an interview at a company they really want to work for, it's almost not rational for them to just bang out something that's "good enough for government work" some evening rather than taking the time and care to really do it properly.
But this doesn't scale if they're interviewing at a number of companies and/or otherwise just don't have much free time.
Personally, I love interview questions with some real life practicality to it. Tell me a problem your company is facing now and I will be energized to give you a solution. Typical abstract questions like design a binary tree or solve an arbitrary puzzle don’t interest me.
And sometimes its easy to memorize such solutions. Translating a real life problem into a computer science one requires some skill.
I'm not a big fan of extended take home assignments but I can definitely see the logic of wanting to have some evidence that a candidate can do what the job requires.
I do a lot more writing than programming and, for someone for which that's one of their primary jobs, I would absolutely want to see writing samples--and, if they didn't have one they could share, they're going to need to write something custom.
I honestly don't get the max 1 hour interview process. You're probably not that special. I guess I did just have an interview over lunch once but I had known (and worked with in various capacities) the person making the hiring decision for years. Other than that, I've always had multiple interviews, if only so that multiple people could talk to me. As an interviewer, I really like having the perspective of multiple people precisely because it is a very imperfect process and people miss things.
I don't understand why interview tests are so prominent, why not just hire the person as a test for a bit and fire him if he's not up to par? Doesn't cost much and is a much better predictor of success in the company
It costs a lot to hire someone and onboard them. And, if you make a practice of firing people after 60 days because they aren't a good fit for whatever reason, you're probably going to find that you have a hard time hiring anyone.
As I said in another comment, (paid) interning and hiring someone as a contractor/consultant for a fixed period are great for situations where it works for everyone. But, if I'm looking for a new full-time position, I'm almost certainly going to pass on a position that doesn't carry with it the presumption of ongoing employment.
[ADDED: And, yes, some companies have an official probationary period but AFAIK that's mostly reserved for when a hire really isn't working out for some reason.]
This startup is the equivalent of a task management app. I guess you can call that a startup, and app to help you manager your exercises. There are only a 1,000 others out there.
A few things ... the word 'Crunchr' is real hard to make out when overlayed on the image of the person mid-pushup ... in that same-but-too-small font is your company name 'Tona' or 'Tonu'? ... the busy graphics on almost every screen looks great at first but would wear me out and get between me and my info, and looks too much like a cult-of-body-and-youth or like Men's Fitness, definitely not relatable ... the need to select a fancy background for every class listing would be tedious and would require extra info on whatever back end manages schedules, nobody will go through all that work and will be left with weird unrelated defaults ... that your original interview submission contains no rough work would make me worry you'd commit to a suboptimal path without opportunity to reset the course after a preliminary critique.
I don't like all aspects of its design but after getting through its initial quirks the Android Simple-Workout-Log app is dead simple and bare-bones and works quite well without the busy graphics.
I like the concept. I use Strava a lot for cycling, but it's not very good for non-cardio activities. Lots of people I follow also track their strength workouts on Strava, but I haven't done it myself as I find it hard to track progress when the system is not made for it.
Before I have used Fitocracy, I'd say this may be the biggest competitor to this, as it is (at least 5 years ago when I used it) more tailored for strength, where one can log specific exercises and track them over time.
I think it is a bigger issue of signaling. Just like going to Harvard or Stanford. Proving you are "good" enough to get a job at FAANG get you pay and RSU but then also sets you up for all future opportunities.
More money allows you to retire earlier (or have a big enough cushion to take time off as sabbatical or to start your own company or whatever), which is a huge benefit IMO.
I agree with you. I was immediately struck by the tone of the article that the author was "fortunate" enough to be interviewed by Google. Maybe it's because I've been working for nearly 20 years now and am becoming an "old man", but the feeling that Google is this promised land of opportunity rubs me the wrong way. Every company has pros and cons and I suppose Google may have a lot of pros (free food, good perks, and good pay) but at the end of the day, it's just a big company where you work on large projects and will likely have little say in the final product's look and feel.
Recently interviewed at Amazon and I got that vibe as well. Didn't really "sell" the job to me at all, just assumed I would automatically be in love with them. Obviously they're there to evaluate my skills, but in my opinion an interview should be something of a two-way street.
I thought for the past five years FAANG, maybe Netflix aside, was supposed to be passé. Unicorns like AirBnB or Stripe were supposed to be the killer workplaces to strive for. Though I suppose with the potential IPO busts this year (see Uber) the dream aspirant tech workplace might be changing, too.
This reminds me of a take home software engineering interview I was once given via email. Same deal, I was told about 5 hours. I’m an iOS developer, so I was expecting a pretty simple app.
I opened the PDF to find not one, but three separate tasks. Completion of all three was expected, with an estimate of about two hours each. One of the tasks was to replicate Apple’s ‘Reminders’ app in its entirety, backend sync functionality included. Another, a task requesting Visual Studio (iOS devs have no need for any experience with this).
I promptly replied declining to continue the interview process. If you’re ever in a similar situation, interviews can sometimes tell you more about the company than they can learn about you. Good chance I dodged a bullet, and could have been working for someone setting highly unrealistic client deadlines, with the expectation that I can build something in any technology proficiently.
I've found it incredibly glitchy. I have some reminders that somehow duplicate and show up multiple times (all at the same time), and others that will show up and instantly dismiss themselves. I can even be looking at my phone and see them pop up and instantly disappear.
For a long time I thought it was perhaps due to poor sync with the Mac, since sometimes I manage reminders from there, but the same thing happens with the wife's phone and she doesn't sync Reminders. She has a single daily reminder at 10pm. Sometimes it shows up 4 times. Sometimes 4 times and 1 disappears for a net of 3 reminders. Sometimes just 1 shows up. Sometimes none of them show up. It's bizarre.
Reminders sync when I create them and recurring reminders show up on every device, but I have to mark them complete on every single device. Sometimes they show up again right after being marked complete.
I've stopped thinking about it as "glitchy" and more "the new Apple way".
Interesting — does iCloud otherwise work normally? We've used it heavily for years and never seen anything like that. They used to have an option in the iCloud.com settings (under advanced) to reset the sync system which might be worth looking for — back in the day there used to be a utility to reset the Mac sync database which often fixed problems like this but I believe that was removed at some point.
I believe iCloud does otherwise work normally. Reminders is the only app I can think of (including all Apple and non-Apple apps) with any sort of obvious glitches, sync-related or otherwise. I'll give the reset a try--thanks!
Ridiculously glitchy for me too. No idea if it will remind me or not. No idea if clearing something will really clear it. Unusable really. I assumed it was piss poor exchange/activesync support but if it happens to others without any sort of syncing maybe there's something more to it.
Not Reminders, but Apple's calendar system torpedoed my Apple interview. Didn't properly account for the fact that my interviewer was in China and I wasn't. It got the time of day right, but he called me a day before my interview time while I was in class because it was tomorrow in China.
He let me reschedule for later that day but seemed hostile and grumpy throughout the whole thing. Didn't get the next round.
We've joked about giving potential hires a challenge to fix a problem we are currently experiencing, but we wouldn't really do it. That takes some balls to ask interviewees to write or fix production code.
Back in 2000, I had an in-person interview at a very small b2b website. They'd been using overseas contractors (zero local technical people) and the founder/interviewer barely knew a thing about computers. He didn't know how to run a technical interview, so he sat me down at a computer, logged in as root on prod (lol the only server), and pointed me at a couple of bugs. I knocked them out lickety-split and was hired on the spot. The world sure has changed
Every company I see "really would like" to fully automate their build/test/deploy pipeline, to actually have automated tests for most new features, infra as code is a work in progress, et c. Basically most of the Joel-test or modern HN-bubble best practices are still on the wishlist or on a perpetual "we're trying to make that happen" an awful lot of places.
And they are all, all, "fixing their Jira workflows". Constantly. What a time-sink of a tool, as commonly used. I'm convinced at this point they'd be better off letting their dev teams use whatever, and just have human-driven processes for collecting all the (mostly meaningless) metrics they always seem to need to report upward, rather than trying to make one tool do everything automatically. Pretty sure Jira and other heavy PM tools are typically the sort of software/process that Graeber calls out in Bullshit Jobs: adding a ton of work out of proportion with any real benefit, to make everything fit in a computer and on a spreadsheet, rather than reducing work.
I'm making it like that again. I'm back down with the blue collar proles in Mountain View, landscaping and moving and waiting tables and the like. That's how things work outside of speculation... employer has a business where they get paid, and they outsource their own functions. I'll never run an engineering org like Silicon Valley again, it's so broken in delivering results as a result of the speculative nature. I have a project website up serving two cities. We use Clojure and static generation, and operate and maintain IT like an old tractor. I train my replacements to keep myself available and customers getting a good price (minimum wage). It lets people start their career with hands-on work. It's in BigTech's interest to make us think tech is hard, but I'm using most of the same stuff as I did when I was 14 and self-taught 20 years ago, and it's gotten far far simpler and better.
I'm in high tech and dying. This is making me feel nostalgic and thinking... maybe taking 3 steps back would be 10 steps forward in terms of my mental health.
What's the copyright situation in America anyway? I can't see company lawyers over here be comfortable with using code written outside formal employment.
Code is copy-written by default. So unless the company has you specifically license the code in a way they can use, there's defiantly some room to go after them.
A game studio I worked at had a blanket policy of destroying all fan fiction. And story plots we were sent just because someone had previously sued for stealing their idea.
Means a lot of letters from kids get read only by the secretary till the identify it and destroyed.
It's great if you do it as long as you pay for it. I was doing a 1 week payed interview at Coinbase. I was not hired, but my memories of the interview process are great.
This sort of thing mostly works fine for students and similar. (And internships are often great for everyone concerned.) But this doesn't really work for someone who already is working full-time. Some pay is fine but there's no way I'm taking a week of vacation to interview with you.
I understand it, I wasn't a student, but I didn't have a job at that point (I quit 2 years before to travel the world and had some contracting jobs).
The good part is that it was the last step, and 50% of the people from the last step were given an offer, so it wasn't that bad (though I'm afraid that the offer itself was maybe too low compared to my previous works).
Also keep in mind that many tech companies have anti-moonlighting clauses or otherwise forbid side projects. You’re losing current employees from these companies from the interview funnel.
I'm sure a lot of folks take the attitude that it only matters if you get caught. However, unless perhaps I already had one foot out the door, I'd be very hesitant to flagrantly violate an employment agreement forbidding such things to accept a relatively modest payment for some outside work.
At our place we reserve coding tests for applicants on the more junior end of the spectrum. I've always found conversational interviews sufficient for vetting mid to senior level developers.
We do pay a good rate for the time we instruct people to spend on the coding test. We value our people and prefer starting the relationship generously and in good faith.
I've just completed an interview process (waiting for the decision) that was explicitly "this is a real problem we have", but also stating that I'll be paid for 8 hours work. I have no problem with that. It took about that long as well.
So I suppose if you're honest about it, and you give a fair estimate of the time required, then what's the problem?
I still disagree with that. are you being paid 8 hours at a pro-rated salaried rate? Well you're going to have to report that as income and take a 30% haircut off it. There's a reason contractors get 30% or more above the hourly-equivalent of a salaried employee.
Our interviews have consisted of something similar, but never in a way that produces actual usable work. We've had candidates "add features" to code, except the code in question was in a language they don't know. So they didn't write anything. We have them tackle past PRs for bugs that have already been fixed. And we've had them do design work for systems/processes we've already built.
We're not evaluating them on whether they got the same answer as us. We care about hearing aloud their thought processes.
This happened to me too. A company reached out to me on Angel with their coding "challenge" - create a facebook timeline clone with an API, enzyme + selenium tests, documentation, and deploy everything to AWS. fortunately i have enough experience to say no to this kind of thing, but I do feel that some more junior folks are being exploited into thinking this sort of project is normal for an interview
>Once one agent learns how to become more competitive by sacrificing a common value, all its competitors must also sacrifice that value or be outcompeted and replaced by the less scrupulous. Therefore, the system is likely to end up with everyone once again equally competitive, but the sacrificed value is gone forever. From a god’s-eye-view, the competitors know they will all be worse off if they defect, but from within the system, given insufficient coordination it’s impossible to avoid.[0]
I once received one of these tasks, described as requiring four hours. I had a look around the web, found the source of the exercise, complete with an expected time to complete of four hours, and the guy had completed all of two classes before abandoning it.
I had a similar experience once but a little more extreme. On a take home interview test they were asking to build a full backend analytics setup plus a data viz UI. I called the recruiter back and told them an estimate to a problem like this was well beyond the ~4 hours they originally told me. Their response was to say "they were looking for people who would find a way to get it done no matter what". I immediately stopped the interview process without looking back.
> you’re about to dedicate up to 5 working days on this task, with the potential for them to ghost you straight afterwards
I often give companies a list of open current open source tasks I'm working on. Pick one and I'll complete it for your interview. Every singe company turned me down, except one, who just accepted one of the tools I had on Github and examined that.
One of the biggest challenges I have as an interviewer is setting up a framework that allows me to compare candidates fairly. Most candidates don't have a list of open source tasks they're working on. If I have three candidates who completed my standard interview code sample and your open source pull request, it's much easier to spot the differences in the other three candidates.
This is a very good idea! I could even imagine something like this could be a socially acceptable way to test candidates, with thw benefit of helping open source
I recently Skype interviewed for a local startup run by a former Googler. He was very proud how much the interview process was based on Google's, with multiple stages to ensure they get the highest quality developers.
The startup sounded interesting, and I might have been prepared to spend the recommended 5 hours on the code test, had I had a chance to actually go into the office and meet the team...!
At least at the end of a Google interview you get to work for Google.
To be fair, even though the hourly expectations are often unrealistic, I much prefer a coding challenge (as a former hackathon goer, I likes me a challenge) over a sweaty nervous “whiteboard session” where they nerd grill you on some irrelevant algorithm questions. Unfortunately, most companies do both.
Recreate Reminders? Wow. That app has an entire team of engineers to build that. It isn’t trivial, despite being “simple.” And to do it in two hours? That’s just insulting.
A while back I made a career change and I was looking to break into the land of programming, where there are a lot of bootcamp noobs like me trying to do the same.
I did an interview and one guy just didn't want to be doing interviews it seemed. Later when I was asking questions it became clear that he was a "senior dev" who just didn't want to talk / work with anyone he deemed less knowledgeable or just not capable or something. I also find out he's the lead for the spot they're hiring... bad feelings started for me.
Later I got some positive feedback that the take home assignment I completed was one of the only fully completed and "thoughtfully done" assignments they received (one of the only times I received useful feedback during a recruiting experience).
Bad vibes aside, I was a noob and beggars can't be choosers so I was surprised when they asked for a second interview and felt I had to go to the interview (need a job!). Second interview and it was the same thing, and when I asked questions he didn't even answer them really / his random technical statements seemed like sort of ultra truisms / not related to the actual problem we were working. It also seemed this dude's team kinda worked on their own island (kinda appealing) and he was the guy running the island evaluating people (very much not appealing). More bad vibes....
It was a big corporate place (good pay, benefits I had heard) so that meant, MORE interviews if we were going to move forward..
But by that time I had a good interview at a small place (less benefits, probabbly less pay, fewer people to learn from / with, long commute, but it seemed friendlier and the lay of the land was way more clear)... I decided that I just had too bad a vibe from the guy who would be my boss so I declined the interview.
I was pretty honest with the HR person that just from the interview this guy really seemed like he didn't want to hire me / didn't really want to work with anyone like me and if they were going to hire someone they might want to work on that. The HR person said "yeah we know".
I still wonder what that job would have been like, would have been really nice to work at that place...but that guy... you just get that sense in an interview sometimes.
In a data science interview at a respected company I received a take-home with the framing “A Product Manager wants a dashboard with a massive amount of features (including interactivity, model prediction and GIS)” and received only 48 hours to do it. I thought there was some weird trick because that assignment had an unreasonable amount of scope in that timeframe. I found out the company uses a BI tool to streamline such tasks that is only available to enterprises and not consumers.
I eventually made the dashboard but it took 16 man hours; on the on-site, the interviewers implied they didn’t like it as it was not feature complete. (I called them out about the BI tool; they weren’t happy about it but admitted I was correct that it would be more efficient)
Now that I have had more experience as a data scientist, the real-world response to such a framing is to push back against the PM and write an implementation spec with a defined scope.
A previous manager once told me how to deal with product managers: "You tell them what you need from them. Not the other way around." Don't let the PM write the spec. They state the problem and you ask them questions to come to the solution. You also give them the timeline. If they don't like it, then cut features.
I was given a take home exam that I took one look at and said nope, I wouldn’t enjoy working for the company. I actually appreciated this approach as a quick way to filter out job opportunities.
> They presented three design challenge options to pick from, with a weeks notice and advised that we should spend no more that 3–5 hours on the task (wink, wink)
I guess as a programmer I'm too logical. You tell me X hours, that's all I'm going to spend. For one of my past interviews I was given a task to make a multiplayer battleship game using whatever I wanted, and was told to spend 2 hours total and they didn't expect me to finish.
I got some rudimentary client/server communication going and that was it. No game logic at all.
Didn't get the job: "However, we would have liked to have seen you get further on the project in the same amount of time."
Yeah, 2 hrs barely touch anything new in my current job, where we have a lot of boilerplater and in-house infrastructure built by the devprod team. Some companies either take those for granted or just deliberately make the bar extra high for arbitrary reasons.
I hope one day, well I actually hope to be alive to see, that one day humanity will have enough understand of the brain to teach us our cognitive limitations and how to effective work around/out them. Not long ago I quit one of my jobs because I simply couldn’t learn to be effective due to meetings and all the interruptions commonly seen in an open office/agile/start-up company. Seriously, I can’t be a better engineer in such environment.
I think we interviewed for the same job. I did the same thing, and got the same response.
It was such a short timespan that I assumed it was a trick question, and they wanted to see if I could come up with a creative solution that technically met the requirements but was extremely simple. I implemented a board which you could put pins on, and a text-based chat system using websockets. The idea was that it would work like a table-top simulator.
Nope, turns out they wanted a real solution. I wonder how many companies who use these examples actually attempt them before using them to hire people. My guess is they might be more realistic if they did.
I once had to do a full-stack coding task for a YC company - I think it was something like build Tic-Tac-Toe with backend validation and storage of game state. I built it, and instead of being called onsite, I had a phone call with an engineer. I expected to discuss my solution with the engineer and prepared accordingly, but they did not mention the assignment at all, and proceeded to ask me algorithm and database trivia questions. I did not get the job.
Had a similar security interview with a healthcare company. Three tabletop exercises that were all dumpster fires (no controls, no logs, no ability to research, etc.)...it was at that time I REALLY looked at the interviewers and noticed just how burnt-out they looked.
You can learn a lot about a company's pain points by the questions they ask during the interview...chances are they're problems they're struggling with at the moment.
>> Another, a task requesting Visual Studio (iOS devs have no need for any experience with this)
Ironically enough I just moved to another iOS job and have been sitting in VS for the better part of the last couple of days. Some shared systems are written in C# so all developers basically have to use it at some points.
I agree it shouldn't be a part of the interview though.
I once completed the task sent to me by a prospective employer, and then thanked them and said I wouldn't be submitting it, as it told me enough about the way they worked to know I wouldn't enjoy it.
Never forget that the interview process is two way ...
Those few big companies probably have more than enough candidates. If you have too many candidates you need to adjust interview difficulty to still hire only as much as you need. I don't think these companies care that the task is too difficult for 99% of people, or that there are smart people who are not motivated enough to complete it as long as they can get as many smart and motivated people as they want.
That said, finding a job in IT if you are good at what you're doing is a dreamland currently, so declining if you think you won't enjoy working for a given company seems only natural.
Given dynamics above I think you're likely better off not working for one of those top few companies if you don't care about prestige and long term job stability.
Then again, what the heck kind of use do they have for developers that can't push back on unrealistic demands? None, unless they're in the business of missing deadlines.
This particular company was neither "big" nor one of the "top" companies to work for. I strongly suspect they were getting noddy developers and were happy with them. The reason I didn't want to work for them was categorically not because the test was too hard, it was a trivial spring-boot app. I didn't want to work for them because of what it, and the test process, said about them ...
I have never heard the term “noddy” but assume it is a cognate for “nodding off”? That would make sense in context but I wonder if you mean something else by it?
To save anyone else from reading all the irrelevant parts:
> Noddy being associated with small children's reading has led to "Noddy" being sometimes used as an adjective meaning "petty or trivial" (compare with "Mickey Mouse"), for example, in computer programming: "This simultaneous linear equation subroutine crashes out on the Noddy case when n = 1, but otherwise it works." or "Remember to check all the Noddy cases."
OP's design is much nicer than this. Maybe the "3-5 hours" requirement was hinting that it needed to be as "material design generic" as possible. Which, this design clearly does.
I disagree. The OP's app is hard to read and has way too many visual elements that are distracting. Initially it has a "wow" factor but after repeated use, those aesthetics are going to be ignored and all your left with is hard to read text and distracting images.
Google's app tends towards the bland, but I don't think OP's designs are a huge improvement.
Also OP's app is targeting the gym nut. Google's is targeting the average person who is looking to just do any type of physical activity.
The rule of thumb I subscribed to: have the interviewer(s) do the interview. Give the candidate 3x time to do it that the in-house people took. Or, framed in reverse, if you want the assignment to take and n minutes or hours, give yourself n/3 to complete it, and however far you get is the bar for the assignment. Interviewees are stressed, maybe outside their domain, and other things. Make something that they can show you their value. The harder and correct thing to do is to find how they can help your org. It is easy to find what they don't know or to play stump the idiot.
We did this at my company. A developer at the level that that developer was applying for would do a task that took them 2-4 hours. We then gave the interviewee four days to complete the task with a recommended time of 2 days. We also always made sure to include the weekend in the time they had to complete the task as we know during the week time is precious.
I read the grandparent as: The task should take 2-4h and be done within 2-4 days is how I read it.
I’m still not sure why people expect it’s easy to fit this in and it’s the last thing you want to do after a hard day of work.
I’ve just started taking a full day off for programming exercises I do when interviewing. It allows me to give well thought through and tested solutions even if I make some small mistakes or misunderstandings. Crazy I know but necessary usually these days.
This is why I only do these for exceptional offers. Like a studio I wanted to work at and a problem that seemed challenging. Otherwise it's a strict decline.
These days they don't give you pass even if you ace the take home test.
Apparently its got something to do with the whole team getting together and publicly code reviewing your assignment. And if they feel like the code doesn't fit even to the exact size per their liking, its a reject.
I have had a similar experience, where a perfectly done assignment with unit and functional tests, documentation and all the bells and whistles, It took me two full sleepless nights to get it done. But apparently they rejected, for me not using a specific design pattern which one reviewer likes.
It's absurd to the point of disbelief.
Trust me the take home assignment is a sham. People inside get their friends and alumni hired with no hassles. They only give you these tests because they need reasons to reject you.
Actually, I did one of these jumping from one megacorp to another. It took up my entire weekend, but I landed the interview. I then had to take 2 days off to fly out for the interview. Luckily, I got the job.
You either got very lucky or you're far more effective at pre-screening companies than I am. The last time I spent that kind of time on a test was for a megacorp in the top 50 of the fortune 500.
The process was much the same as you described: multiple day test followed by taking two days off to fly out for the interview. Except I didn't get the job and nobody who interviewed me ever looked at the take home test.
In a government role, I was required to obtain permission for any outside activity, with meaningful penalties. Significant engagements like that for an interview would be in scope.
The interview process being long or whatever or requiring on-site visits is reasonable, but pre-work is probably eliminating good candidates, or attracting people who don't pay attention to their contracts.
I'm interviewing with 6 companies simultaneously and like you they all think they're deserving of free labor.
I'd wager your company must have the worst devs, those who have little self respect and zero other prospects.
Do you not understand that you're requesting free labor from an applicant? Did you forget the purpose isn't to have the sickest challenge ever but to evaluate someone's code/ingenuity?
2-4 hours is anywhere from $100 to $800 worth of free labor depending on how the dev values their time. The GP was bragging about how generous they were in providing multiple days and weekends to finish it.
How did this become acceptable practice for hiring people? Do any other industries besides tech do this?
So teams should just not vet candidates? An in person interview is also going to be 2-4 hours, plus travel time. Should we stop doing those, too? How exactly do you suggest teams screen candidates?
Designers are hired based on their portfolio, why are devs treated differently? I have a plethora of options on my github as I'm sure most here do. Why is it not acceptable to judge a candidate by their already written code?
Lots of people would see this as unfair, as they don't have anything GitHub. Either for preferring to do something else with their precious free time, or perhaps slaving full days in their closed-source jobs.
I think the only fair option is an in-person interview without homework assignments. Treats everyone the same and doesn't require inordinate time commitment.
Studying for a programming interview is also transferrable, whereas maybe pieces of your weird homework assignment will be applicable in another requested project.
If I want to interview at 6 places that just use onsite interviewing it's easy to figure out how to prepare.
They are asking the interviewee to complete the same task as done by an existing staff member, and compare the results, how is that "free labour"?
I'm not sure where I stand on this sort of thing to be honest, my only experience of anything similar was a pre-interview task to implement a simple 10 entry LRU cache, and after getting the job I was told the only reason it was there was to weed out time wasters with next to zero skill being sent by the recruitment company.
Any industry where hiring candidates with bad fit is extremely expensive will have a long interviewing process. For the candidate there is not much difference between spending 2-4 hours at home at a time of their choosing and 2-4 hours in a first of the N rounds of on-site interviews. Except they will have to expense transport and work around their job schedule.
Many people prefer this to an in-person whiteboard challenge. It's lower stress, and doesn't require taking additional time off from your current employer.
A 2-4 hour challenge is less time than I've spent in interviews at some companies, and would gladly have done it prior to an in-person interview given the option. That way, the actual interview time could have been spent talking about things of value, rather than having them stare at me while I white-board out problems around graph data structures and recursion and whatever other trite trivia they can come up with.
To be useful for discriminating between competent candidates, a challenge has to either be hard to complete (pass based on completion) or hard to complete to a high standard of quality (pass based on completion+quality). In other words, it has to be at the limits of what's possible for people you expect to apply for the job.
If you give me a 2 hour challenge with a timer so I can't possibly take more than 2 hours, I'm fine with that - but you won't accomplish the "lower stress" goal.
But if you give me a 2 hour challenge without timing? I know for sure other people will have spent 8 hours making super-polished, gold-plated solutions. Can I afford to fall behind the competition? If not, I should spend 8 hours too.
> To be useful for discriminating between competent candidates,
I helped redesign the code challenge at one of the companies I worked for. We (the people across the different technical disciplines we hired for) put a lot of effort into ensuring that:
* the challenge could be completed in 4 hours
* the challenge resembled the sort of work people would do on the job
* the goal of the challenge was to inform a follow up interview, not punish people
* candidates were explicitly told that they were not being timed, but that we expected the challenge should take them up to 4 hours to give an idea of the upper-bound level of effort expected
The single biggest challenge was balancing "what do we need to know" versus "what would we like to know" versus the amount of time we were asking of our candidates.
We didn't hard-fail anyone unless they were blatantly not a good fit from their submission, and I habitually wrote multiple pages of feedback for them so they at least got something for their time if they didn't get a follow up interview.
Again, the purpose of the challenge was not a screen, so much as it was to help guide the in-person interview and so we had something concrete that we could discuss.
Follow up edit:
Designing code challenges is hard. You have to avoid something so objective it can be copy-pasted from stack overflow, but objective enough that it can be graded free from personal bias (as much as possible anyway). On top of that, you can't test for MVC+CQRS+FP+SOLID+every-other-possible-thing under the sun, because you have to be respectful of candidate's times.
The previous code challenge (the one I replaced) would frequently take people 8-20 hours to complete, and it was actually pretty simple. As you rightly pointed out though, candidates often read far more into the requirements than were actually there, and would often over-achieve in an effort to stand out. Not only would those submissions waste their time, it wasted ours as well as they took longer to develop feedback from.
I think you're missing the point from the previous poster about (perceived) competition.
Unless your challenge literally stops at, "make X appear onscreen" with no regard for quality, testing, etc. Giving unchecked/unverified time restraints isn't fair. It doesn't matter you're giving more time than it should take to complete. If the task can be done in 2 hours, but you give "6" and Candidate A does it in 3, but Candidate B does it in 32 (but tells you 6) you're ranking two totally different submissions. Candidate B might have a super polished submission, while Candidate A has a baseline submission.
The poster you replied to was suggesting that tests should be either 1) not based on quality of submission and simply rely on difficulty so that only a few candidates can complete them or 2) based on quality and difficulty, but with a checked and verified time to keep the playing field level. However those options are both at odds with "low stress."
Again, in our case, we didn't use it as a screen unless the code was an unmitigated disaster or didn't complete the basic requirements.
So, if someone submitted something that could have been done better, see might ask what could be done to improve it in the follow up interview. A good answer would include the technical bits, and a better answer would describe the time recommendation and why a more polished version would take longer or be considered over-architecting.
This purpose- to inform a conversation with a concrete, familiar code base- is better than both take-home screen assignments as well as the in-person whiteboard exercises, which encourage route memorization and don't reflect the nature of the job we were hiring for.
Right. Some companies use it as a screen, we used it to inform the interview.
Two of the last three companies I interviewed at had at least 4 hours of in-person interviews. One of those (for a regular developer position, around 7 years ago) had multiple whiteboard sessions with different people. The problems were trivial to solve if you had access to google or had memorized basic data structures and related algorithms. Instead of taking half an hour or an hour talking about the code I'd written to solve a problem representative of what the actual job entailed, we spent 4x as much time (during business hours) talking about things freshmen learn in CS programs (I'm assuming here, I didn't get a CS degree).
Even if the total amount of time is the same, or even greater, I still prefer the take-home assignment because I can do it on my own time, rather than taking off of work, and - if done correctly - makes for a much interview.
As a candidate, you learn far more about the people you're going to be working with than in a whiteboard session as well.
How many jobs do you apply to when you're searching? More than a few I'm sure.
Maybe 10% of them get back to you with an interview request and that leads to a code challenge. It's highly plausible for a senior Dev to be simultaneously interviewing with multiple companies and have 5-10 pending code challenges. That shit adds up...
>the purpose isn't to have the sickest challenge ever but to evaluate someone's code/ingenuity?
This rings so true for me re: the last shop I was at. People got off giving "hard" problems and watching dev suffer and then giving high praise for the ones that could take the heat. That place was really toxic.
We give a test that should take 1-2 hours, and give them an entire 7 days to do it. I feel like you might be being unnecessarily restrictive in your time limits.
What I've seen is that people spend the time they'll spend on it, and that's it. Only 1 or 2 people over the last few years have said they ran out of time, and the quality of their code showed that they weren't a fit for the company anyhow.
My high school physics teacher did the same. He would take the tests he prepared himself to check whether the scope was appropriate for the allocated time. The factor of 3 was spot on for this kind of estimation.
This how interview task should be made : generate something joyful and useful ; instead we usually have boring throw away to do task.
By the way I had the same @ https://www.captaincontrat.com/ the task was to create a pokemon game, and from that task, I am building my current startup ;) (more on that later)
Someone on my team once asked an iOS engineer to add a button to a codebase during an onsite interview. That is actually a horrible test to complete in 45 minutes if the codebase is large (and particularly hard if it’s not super well maintained because even just familiarizing yourself with the codebase can take a great deal of time).
It’s one of those things that sounds easy but really, really isn’t possible to do in the time allotted. I learned a lot about interviewing people that day.
I can't tell if this is brilliant or sadistic. On the one hand, it really tells you who's smart enough to realize the task can't be done in the allotted time. On the other hand, not being able to do something as simple as adding a button in 45 minutes has to screw with the candidate's mind. That sort of thing would shatter what little confidence I have. I'd probably tank the rest of the interview.
> I learned a lot about interviewing people that day.
Yeah, adding a button to a codebase is an awful test.
If someone made it to an onsite and you don’t know whether they can add a button in swift, something failed in your screening process. If you’re testing how someone navigates a codebase, you can just look at it with them, and let them drive the chat.
If you’re testing an engineer for a serious job, do an algorithms test. If you’re testing an engineer for a specific thing, test that specific thing. Both of those should be handled in the screen, not the onsite.
IMHO, the onsite is about seeing how people think. Whether you can jam a button into a repo doesn’t tell me whether you can think or not. I guess it tells me whether you get flustered, but it’s pretty unfair to design things that are impossible just to see if people break.
That candidate turned out to be awesome but I remember the interviewer telling me after they interviewed them “well, they couldn’t add the button, but as they were doing it, I realized I wouldn’t be able to add the button either so my interview was inconclusive”, and I replied “well it sounds like you need to design a better interview question”. The worst part was, the interviewer spent the first 20 minutes of the interview talking with the candidate before giving them 25 minutes to add the button!!
There’s a question we gave candidates really early on which we no longer do because it biases towards math nerds that I absolutely loved. It’s based on a movie called 13 Tzameti. I’m probably screwing it up because it isn’t my question but it’s basically like this:
You’re in a dark room after being abducted by a gang. The lights come on and there’s 12 other people in the room in a circle and everyone has a revolver with 1 bullet in it (6 slots in the chamber). Your instructions are to spin the chamber on the revolver and, when the lights go out, shoot the person to your right in order.
What are the odds you make it to the next round?
It’s a crazy question and, what’s even crazier is that for some reason, as you increase the number of people in the circle, the odds of making it to the next round converge on 1/e. No one has figured that out in the interview. Also no one has figured out why it converges on 1/e so if you have any ideas, let me know.
I like this question because it shows you how free thinking people are. I dislike this question because it biases towards smartasses and probability nerds.
Your odds go way up if you repeatedly fire at the guy to your left.
Being a senior engineer is knowing the difference between doing what your told and figuring out what needs to be done to achieve project success. In this case, getting to the next round.
He never said you had to spin the chamber by an unknown amount, aren't your odds even better if you make sure the bullet is in the next chamber before you shoot left?
Of course, many game theory calculations assume all players know the payoff matrix and equilibrium strategies of the others; making sure the bullet isn't in the next chamber is the rational universal strategy if the game has a fixed number of rounds.
Presumably the actual question has a bunch of provisos making sure you can't intentionally miss, or accidentally miss, or dodge, or shoot early, or fail to pull the trigger, or shoot the gang.....
I'll bite, but how do you know it converges to 1/e if no one has figured out why?
Your description sounds close to the wikipedia description of the first round of that movie (https://en.wikipedia.org/wiki/13_Tzameti), so hopefully it's not just the wrong probability to analyze, but naively, the setup sounds like it would have slightly above 5/6 probabilty of survival for the first round. But some aspects of the question setup also almost remind me of the classic networking algorithm of slotted Aloha, which does yield an optimal utilization (packet survival) rate of 1/e in each round (for an altered question setup).
The murder question sounds quite interesting, but I'm not sure I understand it. You have n people (initially n=13) in a circle, firing shots that are fatal with probability p (here we apparently fix p=1/6, but I guess that for large n the final answer doesn't depend on p provided it's neither 0 nor 1?), and then 1 fires at 2, then 2 (if alive) or 3 (if not) fires at 3/4, and so on. And you're person 1 (this isn't stated explicitly, though...) so you're the last to have a chance to get shot at, and then you live if person n dies or if person n lives but misses.
So, let's see. Suppose n is very large; then the probability that you live is approximately equal to the probability that your predecessor does; call that q. Then, as above, you live iff your predecessor dies (probability 1-q) or your predecessor lives but fails to kill you (probability q(1-p)). So q = 1-q+q(1-p) = 1-pq and 1 = 1/(1+p).
That's a long way from 1/e, and a quick simulation seems to confirm this answer. It doesn't change a lot if we assume that a random person always fires first, instead of you, or if we assume that you're always last (which I think was the situation in that movie).
If everyone has a revolver with n slots and one bullet, and they all fire at _you_, then you have a 1/e chance of survival for large n, but that sounds too different (and too easily found to be 1/e) to be the right thing.
The probability p(n) that a permutation of n things is a derangement -- which tends to 1/e as n->oo -- satisfies the recurrence relation p(n) = [(n-1)p(n-1)+p(n-2)]/n; is it possible that the correct statement of the problem here leads to that same recurrence?
Ok, I talked to the engineer. I got it mostly right but everyone shoots to the right as soon as the lights go out.
The question is "what's the probability you die?".
Edit: You can also challenge people to think about the problem where everyone fires at exactly the same time OR random order since people have different reaction times.
Edit 2: "The probability p(n) that a permutation of n things is a derangement -- which tends to 1/e as n->oo -- satisfies the recurrence relation p(n) = [(n-1)p(n-1)+p(n-2)]/n; is it possible that the correct statement of the problem here leads to that same recurrence?" <--- My engineer says that derangements are the correct key to the convergence.
I think I still don't understand what's happening in this scenario.
If everyone shoots simultaneously (so in particular everyone does get the chance to shoot) then I die iff the one person shooting at me hits me. Probability equals probability that a given shot hits (so in this case 1/6). No dependence at all on the number of people.
If everyone shoots sequentially, this seems just like what I described above. Probability of death is now p/(1+p) instead of p, at least if you're first to shoot and n is very large. (Unless something's very broken in the heuristic argument I gave. Let's try another. First approximation says a fraction p of people die. But that's not quite right because people who die don't get to shoot, so next approximation says we get p(1-p). Next approximation says we get p(1-p(1-p)). Etc. We can either solve the obvious equation, or else notice that we're getting more and more terms of the binomial expansion of p/(1+p).
I don't see anything here that doesn't look, in a crude approximation, like a fraction p of people dying (p, again, is probability that a given shot hits, which in this case is 1/6).
I must be misunderstanding something in the problem statement here. Perhaps it would be clearer if I'd seen the movie?
Oh, what about this version? You shoot first, things proceed cyclically, and we keep going until just one person is left. What's the chance that it's you? Naively it seems like this should be approximately 1/n no matter what p is; shooting first could confer some advantage but surely it can't be much for large n. So this can't yield anything like 1/e either. Drat.
"The current statement of the problem is that you have n participants, with 6 slots (1 loaded) in their revolver, each firing to the person on the right."
How about this: People shoot in a random order (now everyone has the same chance of making it to the next round. Is it 1/e?)
import numpy as np
class Shooter:
def __init__(self):
self.dead = False
self.right = None # The person to the right
def simulate(n):
# Simulates a round with n shooters
# Returns the ratio of survivors
shooters = [Shooter() for i in range(n)]
for i, shooter in enumerate(shooters):
shooter.right = shooters[(i+1) % len(shooters)]
np.random.shuffle(shooters)
HIT_PROBABILITY = 1/6
survivors = n
for shooter in shooters:
if not shooter.dead:
if np.random.random() < HIT_PROBABILITY:
shooter.right.dead = True
survivors = survivors - 1
return survivors/n
Simulations suggest that the survival probabilities do not converge to 6/7 if you add shuffling. This makes sense, since the survival probability for the random shuffling version must be strictly less than if you are guaranteed to go first.
>>>sum([simulate(10000) for j in range(1000)])/1000
0.8463075999999998
I rather like this idea in the sense that it tells you a lot about your own codebase. There is a lot of stuff out there that only makes sense to the author.
Let's say that the project is a very large, somewhat famous public open source piece of software that has been coded on by many, many different people with different coding styles.
>No one acknowledges the fact that in reality, you’re about to dedicate up to 5 working days on this task, with the potential for them to ghost you straight afterwards.
Is this as common as the author makes it sound? This seems like shady practice. I've heard of marketing firms doing this as a way to get 'free' ideas/work
I recently went through an interview with a company posting on HN and was shocked by their challenge.
They provided their current UI (barebones dashboard) as well as instructions to launch the backend server locally and requested I upgrade their UI to include a side panel for filtering a data table.
The task itself wasn't difficult, but the realization that these scum bags wanted me to upgrade their current product under the guise of a challenge. I instantly knew this wouldn't be a company I'd want to work for even if they did provide an offer.
They had given me a live demo of their product on a call beforehand, so I know they didn't have this. They wanted me to design a feature they didn't have yet on their current product.
Depends on if you're happy just being a hired gun instead of an employee.
The real problem is that they've broken the social contract implicit in the interviewing process, which is that the work you're doing is only to prove yourself and that they won't benefit by it except to be able to gauge your skills. If instead they had been honest up-front that they wanted to hire you short term as a trial period type thing with the possibility of hiring you as a full employee down the line, that would be fair.
Not worthwhile, but it would have been interesting if you'd completed the project and included some telltale sign that you'd authored the code.
Then, if you found they'd deployed it without you having granted them a right to use your copyrighted work, you'd have an interesting basis for a lawsuit.
This is a really great marketing example! The creator has combined a top page HN post with a PH launch at the same time with really polished looking apps & landing pages.
Essentially this will give them a huge traction boost on the app stores and a bunch of new users. Super impressive.
It's definitely good marketing, so kudos to the creator. I will say though that so many Medium articles I read now are essentially marketing pieces. They'll cover some topic very, very lightly and have a call to action at the end to view the author's product or company.
Link poster here: I am not the creator of the app and don't know its author Andrew Burton. So there is no intentional coordination. Heck, Andrew may not have yet noticed that his article is a top page HN.
I have just stumbled upon this article in a UX mailing list and thought it'd be interesting to share it on HN.
614 comments
[ 2.0 ms ] story [ 465 ms ] threadShows again that good efforts pay off anyhow.
To make this more fair, why not let the designer work at the company's office, so the interviewer can actually see how much time it took, and the interviewee doesn't waste more time than necessary?
Less convenient for people who have a different job at the same time though.
You took out the time to go to some office. You just spent an hour talking about your hobbies and attitudes and the company's working culture etc. Then, a programmer asks you to balance a red/black tree. You do.. what? You angrily throw the marker on the ground, cry insult, and run out the building? No, right? So then what?
I see this repeated a lot on HN and I'm not sure I'd have the guts to walk out of an interview. To be honest, I doubt many people do.
How about a phone call or a quick email to ask what is their hiring process, what is the work and how it is usually fulfill?
In the current market you are not a seller, you are the buyer. Why should I consider working for you?
My experience is that hireing descicion is so noisy that there are no reason to invest too much since the rate of sucess is barely increased anyway.
The more picky the employer seems the less reason to apply. It might be a internal candidate allready chosen or they are just hoarding resumés to keep recruiters occipied.
The decision is allready made from the from the first minutes ... but you can ruin it of course.
I don't think memorization of an algorithm is what should make a senior level candidate stand out. Senior people need to be able to lead, mentor, self manage (this is a huge one IMO), and understand the bigger picture. "How do we avoid having to balance this tree at all?"
The role of the senior Engineer isn't to tell you how to balance the tree. You, or anyone you instruct to, can simply ask google that or use a library.
Their role is to ask why we need to balance the tree. You very definitely can't ask google that, and that's why you need to hire a senior Engineer.
"Hi <dev name>! I think we may need to optimize memory consumption of this distinct element counting code a bit; I remember there is some HyperLogLog algorithm which should help here... let's check how it goes... (reading Wikipedia page)[0]"
[0] https://en.m.wikipedia.org/wiki/HyperLogLog
I'm with your comment's parent: I don't think I'd have the guts to walk out of an interview either, especially for a job I applied to first.
For company who reach me, it is mandatory.
I'm not sure this is the best approach...
Have you no common courtesy? I terminate the process as soon as I find out I'm not a good fit for the company or vice versa, no matter who initiated first. Continuing with an interview when I'm sure I'm going to decline is just wasting everybody's time.
I've heard of companies asking for proof of other offers so saying so and so offered me 2x is a very risky play if untrue.
My point is that it is also risky if it is true, but the other offer is not a job you would take.
I have walked out of interviews as well. Sometimes the interviewer and I discover together that the recruiter we worked with didn't know their job, at all!
More often, though, it sort of was clear from the start of the interview that the company would not be a good fit for me. I would tell them so, and my reasons why I thought so, and leave after thanking them for their time.
If they ask me to do some simple programming task, I ask them if they have looked at my Github repository and what they think they will learn during the simple task they could not from my repository. If they do would have a good answer for that, for example they want to get to know my thought processes while coding, I am happy to oblige. But if they clearly have not looked at my Github repositories, nor have any inclination to customize the interview process, I tell that I do not believe in the validity of the process.
I have also walked away twice during the one-month trial period. Once the company was unable to find a project for me, even though they kept on promising there would be one for me soon. The other time I discovered I was unable to combine working full-time with finishing writing my PhD thesis.
Anyway, I also found that in half of the cases I walked out, the other party did understand and accepted why.
Of course, it is easy to walk away when you know you will find a job soon anyway and even if you would not you will get some support from the government anyway.
If they don't wave you off at the suggestion, you also get to meet everyone and see their work environment.
What I feel is more important is a persons thought process on how they approach a problem and come to a solution.
One hour interview cannot be more than just screening, when split 50-50 to give candidates enough time to ask their questions. It leaves ridiculously small amount of time to the really interesting technical topics. And this discussion is important: CVs are not trustworthy, plenty of people lie or exaggerate the facts — only a live talk can verify the necessary knowledge, experience and skills. It may not be enough, true, but hiring someone after barely speaking to him is unnecessary risk. And hiring someone without necessary practical knowledge and without proving the ability to learn quickly is the same.
Are you sure you meant to say what you wrote? I'm not aware of any place that has figured out how to properly screen candidates in one hour. If you know how to do it, please share, it would help all of us.
Corporations love obsessive-compulsive workers who feel thankful to have the job, are willing to sacrifice personal time towards their business goals and would never dream to unionize or otherwise engage in collective bargaining. They want solitary and competitive workaholics, that's the whole point of 'homeworks'.
I have to wonder if they didn't get the position because they spent more than the advised time for the task.
If that makes them look like assholes, yeah, I can see why someone would feel that way but at least they are clear about their intentions and not insulting anyone's intelligence in the process.
It'd be more useful to know they could execute roughly what I'd expect in 3-5 hours. As in they think quickly, come up with something, get the basics down and are ready to progress or not.
...Of course, if they're doing it at home they could spend 3-5 days on something I'd spend 3-5 hours on and I'd never know...
Maybe the same situation applies in Design somehow? I mean yeah it takes 4 hours to make the product if you happen to have all the graphical elements you will be using already downloaded and organized.
on edit: although I have noticed a disappointment in some places that I have not done a lot of time cleaning up the code after writing it and making everything beautiful and writing a good readme to tell them everything to do and so on and so forth and normally I don't do those things because I spent more than 4 hours because there was stuff that needed fixing and anyway if they wanted all that 4 hours would not be enough.
Coding is like math homework. When your doing the math homework you know when your done, it's very obvious and anyone can check your work and clearly see it's either right or wrong.
Design is like a book report for English class, it's bottomless and can always be improved given more time, albeit with diminishing returns. Design challenges are evil and bullshit, you can poor hundreds of hours into a design challenge and still iterate further.
But people complain that I am not done with the programming assignment if I have not made it DRY enough, or put in tests, or done a readme outlining more advanced than run npm install then do npm run start.
Programming assignments may not be infinitely improvable but they can often be improved, I just don't consider it worth the effort to improve the work before submitting
Agreed, unless they want a good polished solutions, meaning it has been refactored, has decent comments, is well tested, etc.... then it becomes a lot like design where the sky is the limit.
My wife got her first job in the states because of a take home design challenge. Other companies were wary of her because of her foreign degree and no US experience, and she was able to show off in the design challenge they gave her (she spent more time than estimated, but not incredibly much more than that). In this case, it really worked out for her.
If I asked a candidate to spend 4 hours on something and they come back to me with 40 hours of work, it isn't what I asked for. Despite it being potentially amazing, that person ignored the task.
A 4-hour task would probably yield 1-3 mockups. Maybe a launch/splash page, the home leaderboard page, and then a page showing the details of a specific user.
Even these 3 pages would be pushing your 4 hour time limit, but that is really the most I would expect.
So if I was interviewing and comparing candidates and one candidate submits a 40-60 hour project while the other candidates submitted a 4 hour project. I can't really compare the two. I would probably throw out the guy that ignore what I asked them to do by spending 40-60 hours of work on something I only wanted 4 hours of work on.
I had an interview once where we were on the phone, I got the task, and they told me they'd call me back 2 hours later.
Might be easier if the office is far away.
My last company they flew me from another continent to do a 3-days assessment, I worked with the team on a legitimate feature(that would be trashed after as they couldn't use the code because I was unpaid). I liked it, I met the team, I interacted with them, I did the task and got a job offer in the end.
All engineers at the company highly valued the 3 days assessment because we got to select great people to work with, but we were getting too many candidates giving up or false negatives, they eventually cut it down to 1-day despite our protests.
Honestly it's stuff like this, that has me contemplating giving up this career path because there's just no more room for people in their 50s with 25 years of experience in information technology, who aren't willing to sleep at the office, drink your "insert trendy microbrew here" on tap, and suffer through a ludicrous ask like "we want you to work for three days for absolutely nothing to see if you're a good fit".
If you are traveling internationally, then you have to add 1 day of travel on each side of your trip. Plus the 3-day "interview" or challenge or whatever. So that is 5 straight days of interviewing for a job. That is actually asinine.
If you have a current job (most software developers do, especially the good ones) then that is an entire work week that i have to request off at my current job to go to unpaid work with no guarantee of getting a job afterwards.
I can't believe someone has actually done this. It is crazy!
I don’t think Google necessarily requested a full end to end product. A nice logo/app icon for the “branding” portion and some UX concepts can definitely be fleshed out in a single work day, especially with zero tech/biz requirements IMO.
Maybe you’d need to take an extra day just to brainstorm first... but actually pushing pixels, if this designer compressed his output a bit, could have happened in 6 hours.
Also, I do think that some people are able to complete it in a third the time, but I think the more useful evidence is that many candidates complete it and do a perfectly good job, some even with a healthy chunk of time to spare. If it were a totally unrealistic time goal I'd expect we'd quickly notice when no one finished.
The author of this article fucked up when he tried to pass off 5 days of work as an example of what he could accomplish in 5 hours. I am glad he was able to find inspiration from it, but for the success of his startup I hope he also is able to understand other, better ways he could have approached the interview task.
I can't help but admire the way this was done :) I hope my launch story is this good.
One thing I came to think about regarding the "4-5 hours" and throwing 5 working days on it, is that, maybe as an interviewer it is quite obvious that you put more than 4-5 hours into it and what they were "really" after were the trade-offs you would have made if you put 4-5 hours into it. Just a thought.
It's one thing to accept that some people are busy and shouldn't be punished, a bout are we supposed to only hire people who have zero excitement for the industry and job?
Sure, feel free to spend extra time on the take-home assignment to signal to the potential employer you are passionate, but that's a different thing.
I never had to provide an actual signature, aside from a verbal agreement with the recruiter to not share interview questions.
This applies to the design prompt specifically, which is an early-stage take-home thing. I don't recall whether google had an NDA for the onsite interview portion itself, but I think their badge signin thing might have one baked in, and other companies of equivalent size had paper NDAs as part of checkin. Presumably they only care about you stealing the cool stuff you hear about, and you wouldn't be in danger for running with their (intentionally generic) interview prompts on your own.
Here's the thing: the NDA you sign when you go onsite covers the company's intellectual property. It might cover the interview questions they ask you, but if they're not paying you for the work you do as part of a take-home interview question, and if you're doing it on your own hardware - it's not theirs, it's yours, and they have absolutely no say in what you do with that work afterwards.
Moreover: if you are subsequently hired by the company, they still don't own the work you did on your own time and hardware. (However: if you continue to work on it while employed by them, they might then own that follow-up work. Check your employment contract carefully, and if you're in a position to insist that employers do not own your off-hours work, insist away.)
Now, if you're currently at another company, and you complete the interview task on their hardware, and especially if you make the mistake of doing that work during company work hours...well, your current employer might then own your interview work. This is a matter usually covered by your employment contract (and another excellent reason to read those carefully).
Company Tried to Patent My Work After a Job Interview
I fixed that problem for my candidates then turned it into a startup:
https://takehome.io
So clearly the process isn't working here.
Also, OP launched on product hunt today. Calling them a "successful company" is generous if not outright false, though I wish them every success.
Stated less dramatically, what happened here is "I turned my design interview prompt into a real piece of software". That doesn't imply that google's interview questions are too hard. A software company asking for a deliverable that approximates software is sane.
I think the time that google demands for their take-homes is a bit much (explicitly, this is 4-6 hours. in practice, it's 20 to 30 if you want to deliver at high caliber). But the questions/prompts themselves are intentionally quite boring, and exist to see how far you can take it.
I found them to be pretty good. These kinds of questions depend somewhat on chemistry between candidate and prompt, so they ask more than one of them, which is great. The takehome I picked was the only one of the 3 offered I could even pretend to care about. Of the two asked onsite, one I felt I delivered on at only the most basic level, and one I think I could have credibly patented / raised a series A for were it a thing I cared to spend 2 years on.
This is a problem with a lot of take home assignments of many types (not just programming). If someone has landed an interview at a company they really want to work for, it's almost not rational for them to just bang out something that's "good enough for government work" some evening rather than taking the time and care to really do it properly.
But this doesn't scale if they're interviewing at a number of companies and/or otherwise just don't have much free time.
And sometimes its easy to memorize such solutions. Translating a real life problem into a computer science one requires some skill.
Why? The big tech companies offer high salaries and get lots of applicants. They can afford to be picky.
And by the way, OP went above and beyond what they asked of him. In fact, there's a chance that this hurt his chances.
>This is a visceral demonstration of how absolutely ridiculous interviews have gotten.
This kind of format isn't standard across the industry.
I do a lot more writing than programming and, for someone for which that's one of their primary jobs, I would absolutely want to see writing samples--and, if they didn't have one they could share, they're going to need to write something custom.
I honestly don't get the max 1 hour interview process. You're probably not that special. I guess I did just have an interview over lunch once but I had known (and worked with in various capacities) the person making the hiring decision for years. Other than that, I've always had multiple interviews, if only so that multiple people could talk to me. As an interviewer, I really like having the perspective of multiple people precisely because it is a very imperfect process and people miss things.
As I said in another comment, (paid) interning and hiring someone as a contractor/consultant for a fixed period are great for situations where it works for everyone. But, if I'm looking for a new full-time position, I'm almost certainly going to pass on a position that doesn't carry with it the presumption of ongoing employment.
[ADDED: And, yes, some companies have an official probationary period but AFAIK that's mostly reserved for when a hire really isn't working out for some reason.]
I don't like all aspects of its design but after getting through its initial quirks the Android Simple-Workout-Log app is dead simple and bare-bones and works quite well without the busy graphics.
EDIT: additional point.
Before I have used Fitocracy, I'd say this may be the biggest competitor to this, as it is (at least 5 years ago when I used it) more tailored for strength, where one can log specific exercises and track them over time.
https://itunes.apple.com/us/app/riker/id1196920730?mt=8
https://play.google.com/store/apps/details?id=com.rikerapp.r...
Are we sure that it is worth all this effort? Are they so much better than any other company or startup?
Is our own self so much more valuable if a random intervier liked our works an epsilon more than the other candidate?
People inside FAANG are unhappy as well, they leave their company as well.
I believe we should be less impacted by the ads that Google is running to sponsor itself as the best workplace ever.
Moreover, after some level of income the marginal improvement of more money approaches zero...
I opened the PDF to find not one, but three separate tasks. Completion of all three was expected, with an estimate of about two hours each. One of the tasks was to replicate Apple’s ‘Reminders’ app in its entirety, backend sync functionality included. Another, a task requesting Visual Studio (iOS devs have no need for any experience with this).
I promptly replied declining to continue the interview process. If you’re ever in a similar situation, interviews can sometimes tell you more about the company than they can learn about you. Good chance I dodged a bullet, and could have been working for someone setting highly unrealistic client deadlines, with the expectation that I can build something in any technology proficiently.
For a long time I thought it was perhaps due to poor sync with the Mac, since sometimes I manage reminders from there, but the same thing happens with the wife's phone and she doesn't sync Reminders. She has a single daily reminder at 10pm. Sometimes it shows up 4 times. Sometimes 4 times and 1 disappears for a net of 3 reminders. Sometimes just 1 shows up. Sometimes none of them show up. It's bizarre.
I've stopped thinking about it as "glitchy" and more "the new Apple way".
Perhaps you should try logging off and logging in again.
I totally agree.
He let me reschedule for later that day but seemed hostile and grumpy throughout the whole thing. Didn't get the next round.
And they are all, all, "fixing their Jira workflows". Constantly. What a time-sink of a tool, as commonly used. I'm convinced at this point they'd be better off letting their dev teams use whatever, and just have human-driven processes for collecting all the (mostly meaningless) metrics they always seem to need to report upward, rather than trying to make one tool do everything automatically. Pretty sure Jira and other heavy PM tools are typically the sort of software/process that Graeber calls out in Bullshit Jobs: adding a ton of work out of proportion with any real benefit, to make everything fit in a computer and on a spreadsheet, rather than reducing work.
Means a lot of letters from kids get read only by the secretary till the identify it and destroyed.
The good part is that it was the last step, and 50% of the people from the last step were given an offer, so it wasn't that bad (though I'm afraid that the offer itself was maybe too low compared to my previous works).
We do pay a good rate for the time we instruct people to spend on the coding test. We value our people and prefer starting the relationship generously and in good faith.
So I suppose if you're honest about it, and you give a fair estimate of the time required, then what's the problem?
We're not evaluating them on whether they got the same answer as us. We care about hearing aloud their thought processes.
0: https://slatestarcodex.com/2014/07/30/meditations-on-moloch/
I often give companies a list of open current open source tasks I'm working on. Pick one and I'll complete it for your interview. Every singe company turned me down, except one, who just accepted one of the tools I had on Github and examined that.
The startup sounded interesting, and I might have been prepared to spend the recommended 5 hours on the code test, had I had a chance to actually go into the office and meet the team...!
At least at the end of a Google interview you get to work for Google.
I did an interview and one guy just didn't want to be doing interviews it seemed. Later when I was asking questions it became clear that he was a "senior dev" who just didn't want to talk / work with anyone he deemed less knowledgeable or just not capable or something. I also find out he's the lead for the spot they're hiring... bad feelings started for me.
Later I got some positive feedback that the take home assignment I completed was one of the only fully completed and "thoughtfully done" assignments they received (one of the only times I received useful feedback during a recruiting experience).
Bad vibes aside, I was a noob and beggars can't be choosers so I was surprised when they asked for a second interview and felt I had to go to the interview (need a job!). Second interview and it was the same thing, and when I asked questions he didn't even answer them really / his random technical statements seemed like sort of ultra truisms / not related to the actual problem we were working. It also seemed this dude's team kinda worked on their own island (kinda appealing) and he was the guy running the island evaluating people (very much not appealing). More bad vibes....
It was a big corporate place (good pay, benefits I had heard) so that meant, MORE interviews if we were going to move forward..
But by that time I had a good interview at a small place (less benefits, probabbly less pay, fewer people to learn from / with, long commute, but it seemed friendlier and the lay of the land was way more clear)... I decided that I just had too bad a vibe from the guy who would be my boss so I declined the interview.
I was pretty honest with the HR person that just from the interview this guy really seemed like he didn't want to hire me / didn't really want to work with anyone like me and if they were going to hire someone they might want to work on that. The HR person said "yeah we know".
I still wonder what that job would have been like, would have been really nice to work at that place...but that guy... you just get that sense in an interview sometimes.
I eventually made the dashboard but it took 16 man hours; on the on-site, the interviewers implied they didn’t like it as it was not feature complete. (I called them out about the BI tool; they weren’t happy about it but admitted I was correct that it would be more efficient)
Now that I have had more experience as a data scientist, the real-world response to such a framing is to push back against the PM and write an implementation spec with a defined scope.
I guess as a programmer I'm too logical. You tell me X hours, that's all I'm going to spend. For one of my past interviews I was given a task to make a multiplayer battleship game using whatever I wanted, and was told to spend 2 hours total and they didn't expect me to finish.
I got some rudimentary client/server communication going and that was it. No game logic at all.
Didn't get the job: "However, we would have liked to have seen you get further on the project in the same amount of time."
Oops, 2 hours.
It was such a short timespan that I assumed it was a trick question, and they wanted to see if I could come up with a creative solution that technically met the requirements but was extremely simple. I implemented a board which you could put pins on, and a text-based chat system using websockets. The idea was that it would work like a table-top simulator.
Nope, turns out they wanted a real solution. I wonder how many companies who use these examples actually attempt them before using them to hire people. My guess is they might be more realistic if they did.
You can learn a lot about a company's pain points by the questions they ask during the interview...chances are they're problems they're struggling with at the moment.
Ironically enough I just moved to another iOS job and have been sitting in VS for the better part of the last couple of days. Some shared systems are written in C# so all developers basically have to use it at some points.
I agree it shouldn't be a part of the interview though.
Never forget that the interview process is two way ...
That said, finding a job in IT if you are good at what you're doing is a dreamland currently, so declining if you think you won't enjoy working for a given company seems only natural.
Given dynamics above I think you're likely better off not working for one of those top few companies if you don't care about prestige and long term job stability.
If you have "too many people" you dont make the quality of your hiring "better" by making the process worse.
Being more selective about who you hire is not related to making a stupid test.
A company like that is probably wondering why they can't find the people they're looking for.
> Noddy being associated with small children's reading has led to "Noddy" being sometimes used as an adjective meaning "petty or trivial" (compare with "Mickey Mouse"), for example, in computer programming: "This simultaneous linear equation subroutine crashes out on the Noddy case when n = 1, but otherwise it works." or "Remember to check all the Noddy cases."
https://www.wareable.com/media/images/2017/03/google-fit-app...
WTF Google?
Google's app tends towards the bland, but I don't think OP's designs are a huge improvement.
Also OP's app is targeting the gym nut. Google's is targeting the average person who is looking to just do any type of physical activity.
I’m still not sure why people expect it’s easy to fit this in and it’s the last thing you want to do after a hard day of work.
I’ve just started taking a full day off for programming exercises I do when interviewing. It allows me to give well thought through and tested solutions even if I make some small mistakes or misunderstandings. Crazy I know but necessary usually these days.
Apparently its got something to do with the whole team getting together and publicly code reviewing your assignment. And if they feel like the code doesn't fit even to the exact size per their liking, its a reject.
I have had a similar experience, where a perfectly done assignment with unit and functional tests, documentation and all the bells and whistles, It took me two full sleepless nights to get it done. But apparently they rejected, for me not using a specific design pattern which one reviewer likes.
It's absurd to the point of disbelief.
Trust me the take home assignment is a sham. People inside get their friends and alumni hired with no hassles. They only give you these tests because they need reasons to reject you.
How magnanimous. Who the hell is subjecting themselves to this?
The process was much the same as you described: multiple day test followed by taking two days off to fly out for the interview. Except I didn't get the job and nobody who interviewed me ever looked at the take home test.
The interview process being long or whatever or requiring on-site visits is reasonable, but pre-work is probably eliminating good candidates, or attracting people who don't pay attention to their contracts.
I'd wager your company must have the worst devs, those who have little self respect and zero other prospects.
Do you not understand that you're requesting free labor from an applicant? Did you forget the purpose isn't to have the sickest challenge ever but to evaluate someone's code/ingenuity?
How did this become acceptable practice for hiring people? Do any other industries besides tech do this?
I think the only fair option is an in-person interview without homework assignments. Treats everyone the same and doesn't require inordinate time commitment.
If I want to interview at 6 places that just use onsite interviewing it's easy to figure out how to prepare.
I'm not sure where I stand on this sort of thing to be honest, my only experience of anything similar was a pre-interview task to implement a simple 10 entry LRU cache, and after getting the job I was told the only reason it was there was to weed out time wasters with next to zero skill being sent by the recruitment company.
A 2-4 hour challenge is less time than I've spent in interviews at some companies, and would gladly have done it prior to an in-person interview given the option. That way, the actual interview time could have been spent talking about things of value, rather than having them stare at me while I white-board out problems around graph data structures and recursion and whatever other trite trivia they can come up with.
If you give me a 2 hour challenge with a timer so I can't possibly take more than 2 hours, I'm fine with that - but you won't accomplish the "lower stress" goal.
But if you give me a 2 hour challenge without timing? I know for sure other people will have spent 8 hours making super-polished, gold-plated solutions. Can I afford to fall behind the competition? If not, I should spend 8 hours too.
I helped redesign the code challenge at one of the companies I worked for. We (the people across the different technical disciplines we hired for) put a lot of effort into ensuring that:
* the challenge could be completed in 4 hours * the challenge resembled the sort of work people would do on the job * the goal of the challenge was to inform a follow up interview, not punish people * candidates were explicitly told that they were not being timed, but that we expected the challenge should take them up to 4 hours to give an idea of the upper-bound level of effort expected
The single biggest challenge was balancing "what do we need to know" versus "what would we like to know" versus the amount of time we were asking of our candidates.
We didn't hard-fail anyone unless they were blatantly not a good fit from their submission, and I habitually wrote multiple pages of feedback for them so they at least got something for their time if they didn't get a follow up interview.
Again, the purpose of the challenge was not a screen, so much as it was to help guide the in-person interview and so we had something concrete that we could discuss.
Follow up edit: Designing code challenges is hard. You have to avoid something so objective it can be copy-pasted from stack overflow, but objective enough that it can be graded free from personal bias (as much as possible anyway). On top of that, you can't test for MVC+CQRS+FP+SOLID+every-other-possible-thing under the sun, because you have to be respectful of candidate's times.
The previous code challenge (the one I replaced) would frequently take people 8-20 hours to complete, and it was actually pretty simple. As you rightly pointed out though, candidates often read far more into the requirements than were actually there, and would often over-achieve in an effort to stand out. Not only would those submissions waste their time, it wasted ours as well as they took longer to develop feedback from.
Unless your challenge literally stops at, "make X appear onscreen" with no regard for quality, testing, etc. Giving unchecked/unverified time restraints isn't fair. It doesn't matter you're giving more time than it should take to complete. If the task can be done in 2 hours, but you give "6" and Candidate A does it in 3, but Candidate B does it in 32 (but tells you 6) you're ranking two totally different submissions. Candidate B might have a super polished submission, while Candidate A has a baseline submission.
The poster you replied to was suggesting that tests should be either 1) not based on quality of submission and simply rely on difficulty so that only a few candidates can complete them or 2) based on quality and difficulty, but with a checked and verified time to keep the playing field level. However those options are both at odds with "low stress."
So, if someone submitted something that could have been done better, see might ask what could be done to improve it in the follow up interview. A good answer would include the technical bits, and a better answer would describe the time recommendation and why a more polished version would take longer or be considered over-architecting.
This purpose- to inform a conversation with a concrete, familiar code base- is better than both take-home screen assignments as well as the in-person whiteboard exercises, which encourage route memorization and don't reflect the nature of the job we were hiring for.
Two of the last three companies I interviewed at had at least 4 hours of in-person interviews. One of those (for a regular developer position, around 7 years ago) had multiple whiteboard sessions with different people. The problems were trivial to solve if you had access to google or had memorized basic data structures and related algorithms. Instead of taking half an hour or an hour talking about the code I'd written to solve a problem representative of what the actual job entailed, we spent 4x as much time (during business hours) talking about things freshmen learn in CS programs (I'm assuming here, I didn't get a CS degree).
Even if the total amount of time is the same, or even greater, I still prefer the take-home assignment because I can do it on my own time, rather than taking off of work, and - if done correctly - makes for a much interview.
As a candidate, you learn far more about the people you're going to be working with than in a whiteboard session as well.
Absolutely worth it if it gets you the right job. Hell, most people pay multiples of that through recruiters and referrals.
Maybe 10% of them get back to you with an interview request and that leads to a code challenge. It's highly plausible for a senior Dev to be simultaneously interviewing with multiple companies and have 5-10 pending code challenges. That shit adds up...
But the company sees the value in doing it, and many people dont see the value in doing it for themselves.
This rings so true for me re: the last shop I was at. People got off giving "hard" problems and watching dev suffer and then giving high praise for the ones that could take the heat. That place was really toxic.
What I've seen is that people spend the time they'll spend on it, and that's it. Only 1 or 2 people over the last few years have said they ran out of time, and the quality of their code showed that they weren't a fit for the company anyhow.
I normally choose divide by 10 for exams as I could do divide by 3 for exams from a different professor/class.
I know the material cold, know the test cold, and don't have to worry about hidden traps--so I expect to take less than 1/10th the time of a student.
It’s one of those things that sounds easy but really, really isn’t possible to do in the time allotted. I learned a lot about interviewing people that day.
> I learned a lot about interviewing people that day.
Could you share what you learned?
If someone made it to an onsite and you don’t know whether they can add a button in swift, something failed in your screening process. If you’re testing how someone navigates a codebase, you can just look at it with them, and let them drive the chat.
If you’re testing an engineer for a serious job, do an algorithms test. If you’re testing an engineer for a specific thing, test that specific thing. Both of those should be handled in the screen, not the onsite.
IMHO, the onsite is about seeing how people think. Whether you can jam a button into a repo doesn’t tell me whether you can think or not. I guess it tells me whether you get flustered, but it’s pretty unfair to design things that are impossible just to see if people break.
That candidate turned out to be awesome but I remember the interviewer telling me after they interviewed them “well, they couldn’t add the button, but as they were doing it, I realized I wouldn’t be able to add the button either so my interview was inconclusive”, and I replied “well it sounds like you need to design a better interview question”. The worst part was, the interviewer spent the first 20 minutes of the interview talking with the candidate before giving them 25 minutes to add the button!!
There’s a question we gave candidates really early on which we no longer do because it biases towards math nerds that I absolutely loved. It’s based on a movie called 13 Tzameti. I’m probably screwing it up because it isn’t my question but it’s basically like this:
You’re in a dark room after being abducted by a gang. The lights come on and there’s 12 other people in the room in a circle and everyone has a revolver with 1 bullet in it (6 slots in the chamber). Your instructions are to spin the chamber on the revolver and, when the lights go out, shoot the person to your right in order.
What are the odds you make it to the next round?
It’s a crazy question and, what’s even crazier is that for some reason, as you increase the number of people in the circle, the odds of making it to the next round converge on 1/e. No one has figured that out in the interview. Also no one has figured out why it converges on 1/e so if you have any ideas, let me know.
I like this question because it shows you how free thinking people are. I dislike this question because it biases towards smartasses and probability nerds.
Being a senior engineer is knowing the difference between doing what your told and figuring out what needs to be done to achieve project success. In this case, getting to the next round.
Next question?
Of course, many game theory calculations assume all players know the payoff matrix and equilibrium strategies of the others; making sure the bullet isn't in the next chamber is the rational universal strategy if the game has a fixed number of rounds.
Presumably the actual question has a bunch of provisos making sure you can't intentionally miss, or accidentally miss, or dodge, or shoot early, or fail to pull the trigger, or shoot the gang.....
Your description sounds close to the wikipedia description of the first round of that movie (https://en.wikipedia.org/wiki/13_Tzameti), so hopefully it's not just the wrong probability to analyze, but naively, the setup sounds like it would have slightly above 5/6 probabilty of survival for the first round. But some aspects of the question setup also almost remind me of the classic networking algorithm of slotted Aloha, which does yield an optimal utilization (packet survival) rate of 1/e in each round (for an altered question setup).
So, let's see. Suppose n is very large; then the probability that you live is approximately equal to the probability that your predecessor does; call that q. Then, as above, you live iff your predecessor dies (probability 1-q) or your predecessor lives but fails to kill you (probability q(1-p)). So q = 1-q+q(1-p) = 1-pq and 1 = 1/(1+p).
That's a long way from 1/e, and a quick simulation seems to confirm this answer. It doesn't change a lot if we assume that a random person always fires first, instead of you, or if we assume that you're always last (which I think was the situation in that movie).
If everyone has a revolver with n slots and one bullet, and they all fire at _you_, then you have a 1/e chance of survival for large n, but that sounds too different (and too easily found to be 1/e) to be the right thing.
The probability p(n) that a permutation of n things is a derangement -- which tends to 1/e as n->oo -- satisfies the recurrence relation p(n) = [(n-1)p(n-1)+p(n-2)]/n; is it possible that the correct statement of the problem here leads to that same recurrence?
The question is "what's the probability you die?".
Edit: You can also challenge people to think about the problem where everyone fires at exactly the same time OR random order since people have different reaction times.
Edit 2: "The probability p(n) that a permutation of n things is a derangement -- which tends to 1/e as n->oo -- satisfies the recurrence relation p(n) = [(n-1)p(n-1)+p(n-2)]/n; is it possible that the correct statement of the problem here leads to that same recurrence?" <--- My engineer says that derangements are the correct key to the convergence.
If everyone shoots simultaneously (so in particular everyone does get the chance to shoot) then I die iff the one person shooting at me hits me. Probability equals probability that a given shot hits (so in this case 1/6). No dependence at all on the number of people.
If everyone shoots sequentially, this seems just like what I described above. Probability of death is now p/(1+p) instead of p, at least if you're first to shoot and n is very large. (Unless something's very broken in the heuristic argument I gave. Let's try another. First approximation says a fraction p of people die. But that's not quite right because people who die don't get to shoot, so next approximation says we get p(1-p). Next approximation says we get p(1-p(1-p)). Etc. We can either solve the obvious equation, or else notice that we're getting more and more terms of the binomial expansion of p/(1+p).
I don't see anything here that doesn't look, in a crude approximation, like a fraction p of people dying (p, again, is probability that a given shot hits, which in this case is 1/6).
I must be misunderstanding something in the problem statement here. Perhaps it would be clearer if I'd seen the movie?
Oh, what about this version? You shoot first, things proceed cyclically, and we keep going until just one person is left. What's the chance that it's you? Naively it seems like this should be approximately 1/n no matter what p is; shooting first could confer some advantage but surely it can't be much for large n. So this can't yield anything like 1/e either. Drat.
"The current statement of the problem is that you have n participants, with 6 slots (1 loaded) in their revolver, each firing to the person on the right."
https://xkcd.com/356/
1. The button doesn't have to do anything
2. You give them a fast computer with an IDE loaded with the project
3. The developer is familiar with the language, UI framework and IDE
4. You aren't doing anything crazy and uncommon like using a non-standard UI toolkit or using an ad-hoc source code preprocessor
5. The project can be built and run with a single command and can be built and start in less than a minute
Is this as common as the author makes it sound? This seems like shady practice. I've heard of marketing firms doing this as a way to get 'free' ideas/work
They provided their current UI (barebones dashboard) as well as instructions to launch the backend server locally and requested I upgrade their UI to include a side panel for filtering a data table.
The task itself wasn't difficult, but the realization that these scum bags wanted me to upgrade their current product under the guise of a challenge. I instantly knew this wouldn't be a company I'd want to work for even if they did provide an offer.
The real problem is that they've broken the social contract implicit in the interviewing process, which is that the work you're doing is only to prove yourself and that they won't benefit by it except to be able to gauge your skills. If instead they had been honest up-front that they wanted to hire you short term as a trial period type thing with the possibility of hiring you as a full employee down the line, that would be fair.
Then, if you found they'd deployed it without you having granted them a right to use your copyrighted work, you'd have an interesting basis for a lawsuit.
That's what I usually do with code challenges!
Essentially this will give them a huge traction boost on the app stores and a bunch of new users. Super impressive.
I have just stumbled upon this article in a UX mailing list and thought it'd be interesting to share it on HN.
But after reading the discussion it prompted, I'm left questioning exactly why it does so.
And like you said, slick marketing on the part of the creator at the very least needs to be acknowledged.