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.
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.
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.
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.
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.
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?
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.
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.
>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.
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...
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.
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.
During a recent interview process I was given a take home assignment for data engineering. Well, I had to wait two weeks for the team to come up with a take home since they didn't have a data engineering assignment at the time. Eventually they sent it to me with a 2 hour time limit. I read the multi-page problem description which had bulleted requirements at three different places in the document, somewhat at odds with one another. There was a request to code a certain NLP technique from scratch and create a recommendation engine based on similar user history. I read through the sample data which had no notion of individual users or any table like that.
The whole thing seemed like something copied and pasted together by committee, with a strong smell of "PhD CTO" trying to test for intelligence by quizzing on an esoteric corner of their own grad school experience. After about an hour of trying to figure out conceptually how I could begin to implement the things asked, let alone the 6+ hours I thought it would take in practice, I emailed the recruiter back and said "Thanks but no thanks!"
My other recruiter friends later confirmed that they had burned through almost every firm in town with their ridiculous take home exams that no candidate could pass within the allotted timeframe. I think bailing was a good choice.
> 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.
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.
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.
> 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]"
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.
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.
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.
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 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.
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.
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.
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.
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.
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.
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.
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.
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
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...
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.
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.
> 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!
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.
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.
I love take-home assignments. Especially reasonably scoped ones. They allow me to show off my skills. However, my opinion is that it should be paid labor. Give me a day of work and pay me to do it. This values my time, it actually doesn't add all the much more to the hiring expense (all that engineer interview time, resume review time, etc is expensive!), and it makes sure you are screening out early and often and not wasting 20 people's time doing a bunch of take home work for one dev position.
In an ideal world, the task can be something that the company needed done anyways, further motivating the financial insensitive. Your point about general cost of the hiring process is well taken, but I imagine that companies issuing take-homes are giving applicants the same task, and don’t see a point in paying for the same job to be done.
From a practical perspective, I'm not sure that spending 20 hours+ working on something for free is any more/less likely to make you less productive at work than doing it for pay, but I see where the letter of the law comes in.
Every job I've ever had required me to get advance permission to do paid outside work, so such a rule would eliminate most people who are both ethical and employed.
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.....
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.
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
"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."
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).
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.
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.
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.
> 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."
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.
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.
> 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.
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.
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 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.
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.
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
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.
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.
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.
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.
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.
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).
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.
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.
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.
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.
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.
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'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.
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!
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".
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.
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.
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.
>> 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.
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 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.
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.
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.
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.
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.
Urgh. I recently had a similar situation. I started interviewing with a company who have a take-home assignment which I could have completed in the required time without taking any care over the quality of code I was submitting, but to do it properly I spent a bit of time thinking about it and building a reasonably extensive test-suite along the way.
I was asked to come in for a face to face interview, for which I made clear I was having to take a day off of work, which was cancelled a few working hours before (so I wasn't able to cancel the holiday) without an apology. I was then interviewed again by phone and told that there was 'a bug' in my code and that I should try to find it and resubmit it without any other details. The spec was a puzzle with lots of weird edge cases and horrible inconsistencies.
I decided at that point that I didn't want to work with them.
I had one a little while ago where I spent a fair amount of time on the request, and I thought was pretty well done. It completed all their tasks, showed how to use their api, and it showed I know how to integrate several different technologies, from front things like React to building an API to interact with theirs and setting up and configuring cloud technologies. They came back, and said, "We don't want to continue, we expected more from him." I sat there baffled and so did the recruiter, as it clearly did everything and more than they asked for in the assignment.
I am so glad they didn't want to go further as I am sure they are a nightmare to work for.
There have been anecdotes on HN about companies using this type of process to get free work out of people. If your code solved the problem they needed solved, they may have taken your code/ideas and used it and left you by the wayside. I hope that's not the case but it's possible.
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 am a software engineer and I was once asked during an interview at a large hedge fund to pick a side and debate why war is justified.
When I pressed them about the relevance, they indicated that they often have heated debates on all manner of topics, so they wanted to see my thought process.
I enjoy solving complex problems, but socio-ethical problems are way outside of my wheelhouse.
I politely indicated that I didn't think the company was a good fit for me.
When interviewing execs who would be building new departments a few years ago, I would pose the question of "In the wake of Arab spring in Libya, the people decide that you are their next leader. What happens in your first 100 days?".
The answers ran the gamut from lazy to fantastic to terrifying. A lot of answers where generic "coalition building" variety. The better answers identified key areas to focus on like infrastructure, basic services, etc. The best answers had clear goals and possible government structures supporting accountability.
Bad answers had the exec consolidating power and crushing opposition. The worst answers had the exec killing people to achieve their goals. Not joking, I had several answers that where "I would find my rivals and kill them".
Overall I thought it was a good question as those who performed well on it and where hired built great sustainable orgs and those who did poorly where usually shown the door within a year. Those who did well where able to take a crazy situation, break it down into smaller problems, and then solve for them while those who did poorly where usually relying either escaping the problem via committees or flat out crushing opposition.
Asking a politically charged question on statecraft and judging the answer based on your own personal ideas about how to run a state strikes me as a bizarre way to conduct an interview, even for an exec.
This is why we need less humans and more AI/ML in the candidate selection process.
The guy posing Arab Spring interview questions sounds just like those 65 year old talent scouts in MoneyBall skipping over a talented 3rd baseman because the kid “doesn’t have good legs.” Humans are immensely stupid and irrational when it comes to judging other humans.
If it's a random number generator, it's not ML. If it's unbiased, it's also not ML. ML is always biased based on the data you train it with, just as any student is biased based on the information they are educated with.
Its actually not such a stupid answer.
Its completely inhumane etc but it worked well for Saddam Hussein (among others) who conducted a purge on taking office in 1979 and then never had his leadership questioned again.
Execpt the question isn't about an organization or company its about running a country and there are a lot of countries where democracy just does not seem to be suited/desired, unfortunately.
That’s what makes the question hard. It’s what would you do in this politically dire situation to lead a country while at the same time impressing an interviewer so you can get a job.
well he was the leader for 24 years and outlasted pretty much all democratic leaders from in his time. I'm not saying I recommend doing what he did and you are right history will definitely not remember him fondly along with many other cruel leaders. But his tactic was effective and I'd say you could argue that he would have been the leader much longer if he hadn't pissed the west off in 91 and if 9/11 hadn't happened.
It would t surprise me if a lot of these stupid questions were actually useful because they indirectly measure something else. On that note, assigning lengthy interview projects is probably a good proxy for “won’t negotuate to hard on his salary”.
But as an employee, I’d sure prefer being treated like a human being...
The OP mentioned that this interview questioned worked for them. So, at face value, seems to work?
The thing is all these weird interview strategies work at some level. Its very self-reinforcing. If a company kept hiring duds, they would change their interviewing style.. or simply go out of business after hiring enough dummies.
> Asking a politically charged question on statecraft and judging the answer based on your own personal ideas about how to run a state strikes me as a bizarre way to conduct an interview, even for an exec.
Seems like exactly what you want so you don't get people who will be playing the opposite sort of political games than you want (whichever sort you may prefer).
He's hiring an exec who will presumably have to operate within his company. If the exec's thought process differs too much from his personal ideas, both the exec and the company are gonna have a bad time.
A problem is that when you topple a dictator you need to first secure the levers of power lest you be toppled yourself.
Suppose your new country has a $1bil in its budget, then spending that billion on schools and hospitals and infrastructure for the people means that there is suddenly $1bil that is not being siphoned of by the corrupt old guard that might still hold levers of power.
If you give them nothing, then they will rebel against your rule. If you try to compromise and give them $500m, they will only be loyal until someone comes along and offer them $750m and then loyal only until someone else can give them $900m. So the game is stacked in such a way that the only way to stay in power is to siphon of the $1bil on corrupt cronies and spend nothing on the people.
That is why it makes sense to purge those old enemies, but that may be difficult in itself.
I have to admit I'd give a pretty Machievellian answer as well, on the assumption the question includes having to keep the position. In harsher political climes, you can't afford to put "building a strong society" on the top of your priority list. One of the ways strong societies become strong societies and stay strong societies is to make it possible to play a lot of politics as much less of a bloodsport, so things like "building a strong society" may reach as high as priority 4 or 5 for our politicians. It isn't perfect, but it's a lot better.
Of course, the fact that I wouldn't do any of this in real life is also why I'm never going to face this hypothetical.
I'm going to guess "Abdicate power as thoroughly and comprehensively as possible to whoever seems most likely to be next in line, so that nobody is ever tempted to come after me or mine, because I am not suited for such a role and I deeply know it" would probably not be considered a viable answer by the questioner....
"In the wake of Arab spring in Libya, the people decide that [George Washington is] their next leader." is not what happened. Libya is not the 18th century British colonies.
Perhaps I'm in the minority here, but I don't like this question because you know there is a politically correct answer and then an actual course of action people would take.
The proper answer is: introduce democratic government, clean up the country, introduce proper amenities (healthcare, etc) and spread the wealth for the benefit of the people.
Fact of the matter is: absolute power corrupts, and plenty of people would loot the oil money reserves for their own benefit if they had the chance. Just have a look at what happens in Russia.
I'm sure we can find a lot of things more horrible than Iraq. Like slavery as you say, or bombing Hiroshima and Nagasaki, or the war in Vietnam...
But what I think OP meant, is that the bad things which happened in Iraq were not the intended outcome of what the US did. Those other, more horrible things were intended consequences, not mistakes.
Kind of, yes. If you're wrong intentionally, we have all sorts of other words for that, including trolling, propaganda, misdirection, incitement, lying, fraud, perjury, all of which have their own connotations for your intent. We wouldn't really call any of those situations a "mistake".
Not only did we try, but we did it the wrong way imo. When you try to pull something this complex off and completely disregard the local culture, politics, and sectarian makeup, you introduce chaos. Did anyone learn from Sykes-Picot?
Sorry but this is a very poor answer. Lack of understanding of the local culture is very evident. Every country in the world cannot have a system like the United states. Cleaning up the system without understanding it would be terrible. Just like Iraq!
Has it ever worked in that order? It seems like most current democratic countries first cleaned up the country and then introduced a democratic government. I’m thinking of recent democratic countries in Asia, like South Korea, Taiwan, and Singapore.
Or if they did start with a democratic government, to limit the voting to certain groups, like the US, Canada, and Australia did before universal suffrage.
Are there any successful countries that haven’t “cleaned up” first but introduced universal democracy?
Rulers derive power from other people. Your first job is to keep the people keeping you in power happy. Fail that, and you'll be replaced by someone else.
Democracy means shifting it from a small number of people keeping you in power to all of the people. It's not easy.
The reason Russia loved Putin is because he cleaned up low level violence and corruption. It's hard to have democracy when people are getting shot in the streets. This is something you completely fail to understand. Furthermore, it's hard to have a "democratic government" when everyone is poor. This is so glaringly obvious that it's painful reading your post.
What would your thoughts be if the interviewee, after that question being posed, asked for a 10 minute break (or thought session) to gather his thoughts about how he would act within 100 days?
- Would you discount the person for not being able to answer your question right there?
- Would you think that this is a person who doesn't like to make rash decision (or the opposite)?
- Would you be thinking that this person is wasting your time?
- Would you allow it or have 'em answer right then and there?
It's a neat idea for the interview, but it could have caused problems, at least in the U.S., regarding labor law:
Suppose the interviewee had answered, "I would work towards a proper implementation of Sharia law." or "I would start by building Christian churches and state-sponsored public preaching." or "I would start by replacing all mosques with science-and-technology museums."
At that point any candidate who wasn't hired could have a good starting point for a lawsuit based on hiring discrimination by protected class.
Ehh, only if there was a demonstrable pattern. You can't just sue an employer for not getting a job because you mentioned your religion as the basis for something.
I mean in the US you can sue for whatever you want, but the likelihood of it happening or being an issue is quite small in this scenario.
This is true. But in this specific case, it is unlikely a single person, especially one in the position of interviewing for a lower level job, would have enough money to rival the company in a lawsuit or cause them severe financial pain. Usually it's the opposite situation that is financially ruinous.
The point isn't that the lawsuit is going to ruin the company. It's that the lawsuit is going to cost the company money in almost every case where it happens, no matter how frivolous the lawsuit. The smart choice for the company is to limit risk factors for having to face a lawsuit.
Do you mean it’s a bad answer because that behavior doesn’t fit the type of person you’re looking for?
I don’t know anything about Libya’s political and social situation. For example, how many people decided I was the leader? Is the military on my side? Is there an opposition with a tendency for violence? Have they attacked before?
There are too many unknowns for me to decide what is and isn’t a good answer. But definitely, the exec’s response would be good to identify culture fit.
>Bad answers had the exec consolidating power and crushing opposition. The worst answers had the exec killing people to achieve their goals. Not joking, I had several answers that where "I would find my rivals and kill them".
You cannot placate a place like Libya without violence. Thinking otherwise is first-world delusion. It's worse - it's the same line of thinking that plunged the country into chaos under the guise of liberating it from a dictator. That's not a defense of Gadafi - it's a reality of things going from bad to worse.
Unlike others relying, I think your interview question is good. Let's break down why.
In your phrasing you asked "what happens". Did any candidates you thought were good give the actual answer: a disaster for Libya, and the person is removed from power?
That is the actual answer.
Of course not. All of your "passing" answers to "what happens" includes building up infrastructure, basic services, etc.
In other words, what you really just asked didn't match your words. You really asked: "Convince me that you are qualified to lead Libya".
Unsurprisingly, the people who realized that this is what the question was, and gave you an objectively false answer, get a passing grade. Those who did not this, or who answered correctly as asked, fail.
Those who were understood what you really wanted, and who also successfully convinced you that they're qualified to lead Libya, "built great sustainable orgs" whereas "whose who did poorly where usually shown the door within a year".
You could have done just as well asking "The company has decided we are building a social network to compete with Facebook. We put you in charge. What happens?"
What actually happens of course is nothing good. It doesn't mean it's not a bad interview question, but a good answer is not the factually correct answer.
Without knowing what kind of company you're working at, here's the way I'd answer the "the company has decided to pivot to building Facebook. You're in charge. What happens?" first based on what I'd actually tell you, then truthfully.
Answer you want to hear:
"Boy, agrippanux, this is a tough one. I hope I'd get some equity because as you know, social networks have a network effect where success means they blow big, and that's what we're going to do. agrippanux, I've long been interested in social networks so even though your company is not really in this space, I think I could really identify some of the areas people feel strongly about, including advertising, privacy, filter bubbles, and also social media addiction. We will end up having to tackle the network effect, so we will start by identifying niches where our company already has a really strong presence. agrippanux, we don't really do much direct technical support to customer's issues, so I would start by having our web page redirect seamlessly to our in-house Facebook competition that I'm building with the team you give me, as a kind of closed beta, so that we can get a steady stream of users asking us questions and getting used to the network. We can then stealthily work on the underlying technology, while testing it with a continuous stream of real user input. As a next step, we would license this answer solution to other companies. Companies will appreciate being able to have the narrative be on their pages, and by building up factual answers and technical support, we would end up building up an expectation of value and reliability - the opposite of "fake news" plaguing social media. Many early adopters are avid supports as well, and the next step will be allowing some members to answer other people's questions as well. The third stage will be introducing some company events such as pizza parties and this type of thing, in the biggest cities. This kind of approach will let companies capture their own audiences, promote those who support their products as online grassroots supporters, and be a clear alternative to the marketing mess on Facebook. Over time we are a viable social network built on the technical foundation that you have, agrippanux, in this very building at this very moment, and based on the good will and brand that your company has spent years building - and leverage that to be a successful full social network. That's why you've put me in charge of replicating a social network using our technologies and employees, and I am confident we can do it." (Then, after a beat, since your jaw just hit the floor at how awesome my answer was.) "Hey so do I get some equity if I help you take down Facebook or what?"
That's a great answer. It's not truthful though. Bam. I just got hired for whatever role you're actually interviewing me for.
Truthful answer:
"Whoever made this change in direction is an idiot. While it is nice for me to get the resources to roll out a social network 'to compete with Facebook', it's probably doomed to failure, and my top priority would be getting out of it alive. I'd probably spend a lot of marketing money getting a few million transient users who aren't actually engaged, and then jump ship to an actual social media company that knows what they're doing and has a mature product with a real value proposition. This company has no chance of creating a viable social network."
See? One of them is the truthful answer that ACTUALLY describes what really happens. Just as you asked. It's similar to exec consolidating power and crushing opposition. And one of them is the fake answer that answers the real question: "Convince me you're qualified to replicate Facebook under our company, using a few hundred thousand dollars." It's similar to the question "Convince me you're qualified to lead Libya."
> What actually happens of course is nothing good. It doesn't mean it's not a bad interview question, but a good answer is not the factually correct answer.
OP is hiring executives, not yes-men. You want people who give you the factually correct answer, because you want people who will behave ethically. Execs have to worry about regulation and corporate risk and you do not want liars in those positions.
"Execs have to worry about regulation, corporate risk, and managing perceptions both internally and externally. You do not want someone spouting the literal truth without a filter in those positions."
That's why it's a great question. It requires a filter.
I get what you are getting at, but this is a terrible question to ask.
Libya is also a very complicated place, and so it's difficult to answer without quite a lot of knowledge.
The question reeks of that ridiculous 'American can-do neo-colonialism can solve anything' kind of problem, and in that context is basically offensive.
Any answer, given by any candidate could only totally gloss over the most important in a ridiculous and igornat way.
"Bad answers had the exec consolidating power and crushing opposition." ?
This is exactly how pretty much all leaders in the the Middle East establish power. Do you think they are stupid? Or maybe that there is some kind of underlying systematic issue here?
Secondarily, is the ugly reality of the answers: you can't 'build infrastructure' while opponents are thwarting you at every turn. 'Killing your opponents' in such a situation may actually be a rational thing to do. Of course it sounds very outrageous to be talking about this in an interview, moreover, it's doubly shocking coming out of people without that kind of relevant (i.e. military) experience.
This question is just loaded with problems, I suggest you adapt it to some other more neutral context.
> I am a software engineer and I was once asked during an interview at a large hedge fund to pick a side and debate why war is justified.
Heh, I actually wouldn't have minded that too much - but in addition to being a software engineer I'm also a former Army officer.
In any case, I think such a task can be relevant, if you're working in a fast-paced and competitive environment (esp. one with a lot of non-technical staff) you need to be able to hold your own in an argument. You wouldn't want to be the guy who is always right but gets overruled 99% of the time because you're unable to persuade others.
> ...but socio-ethical problems are way outside of my wheelhouse.
Mine too, and probably 99%+ of the world's population. But that doesn't stop most people from having strong opinions on subjects they don't understand.
> you need to be able to hold your own in an argument
Then you'll hire a bunch people who like arguing about things they aren't qualified to argue about. I'd much rather have a coworker who admits what they don't know and is willing to learn about it rather than someone who is willing to vigorously argue in support of an arbitrary position.
Great point, but I could imagine this being a test for many different traits. One might be that the interviewee would be entertaining to argue with. It's anyone's guess what really motivated the interview topic.
Sounds like they've bought into the Heinlein/Rand general specialist myth (quote below) and were looking for that. Problem is, it's very easy to mistake lunatic confidence for competence, especially in an interview, and especially given the personality traits that work well in hedge funds/general finance.
>“A human being should be able to change a diaper, plan an invasion, butcher a hog, conn a ship, design a building, write a sonnet, balance accounts, build a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act alone, solve equations, analyze a new problem, pitch manure, program a computer, cook a tasty meal, fight efficiently, die gallantly. Specialization is for insects.”
6 months seems too short, but in 5 years the only ones I haven't done are plan an invasion (how many people out of billions have?), butcher a hog specifically (fish though), design a whole building (designed and built a.. room.. for purposes.. no small or simple task), written a sonnet specifically (other creative writing), set a bone, pitch manure (bagged it, also bailed hay, grew food, etc.), fight physically, or die - gallantly or otherwise.
So that's 4 I definitely haven't done, 4 I kinda did, and 13 I definitely did (I count 21 total not 22).
Misaligned incentives: the people doing interviews have such indirect financial incentive to hire the right people (only that a good/bad hire affects the company's profit, which affects their own salary/stock), almost no way of telling if they made a bad hire decision, and definitely no way of telling if they made a bad no-hire decision. Remember Alan Greenspan's story of finding a competitive advantage because everyone else was happy to ignore half the population in hiring. If you have no direct incentive aligned with the business's needs, then the incentive of "I will derive pleasure from the interview process" (whether it's having a fun conversation, or having a conversation that makes you feel powerful / more confident about yourself, or hiring in a way that reinforces your existing biases) is all that remains.
> Though David Rowe, a veteran architect of the Wharton forecasting model, has played a key role in developing the firm's econometric model, the senior staff, including Miss Eickhoff, Judith Mackey and Lucille Wu, is mostly female. Mr. Greenspan explains the gender bias with the free-market pragmatism that has become his hallmark: "I always valued men and women equally, and I found that because others did not, good women economists were cheaper than men. Hiring women does two things: It gives us better quality work for less money, and it raises the market value of women."
That is, just a few decades ago, the leading economic consulting firms in the world—economists!—were regularly overpaying men because they didn't want to hire equally capable women, such that Greenspan could find an obvious mispricing in the labor market.
Imagine how much more poorly people who are not economists and not owners of their firm must be making hiring decisions on much less blatant biases than gender.
Well he is an economist so he is saying he is paying them the market rate which he believes to be underpriced relative to their intrinsic value. As an economist he would place the underpricing blame on society and the labor market. A similar situation would be if a company realizes it can get more value out of hiring junior developers cheaply over senior developers. An economist would also say they weren't underpaying the junior developers because no one else was willing to pay them more.
I think he's claiming his competitors are overpaying men by artificially pretending supply is half the size it actually is. Or looked at another way, the market value of men is determined by companies that hire everyone + companies that only hire men, but the market value of women is determined only by companies that hire everyone, so demand is lower. Either way, it's not "underpaying" relative to either intrinsic value or value in a fair (everyone is willing to hire everyone) market, which is most of the moral argument for why underpaying is bad. It's "underpaying" in the strict technical sense of paying less than what others are willing to pay men, but that only applies in the hypothetical where one single woman were being hired as if she were a man; if all women on the market were hired like men, supply would increase which would affect everyone's pay.
I think there are multiple solutions to a gender wage gap resulting from markets with irrational participants, and reducing the market value of the overpaid gender is a perfectly valid way to accomplish it. I think that's what he's doing.
By hiring women he's reducing the supply of women in the market which presumably raises their value, but I do agree the more progressive approach would be to hire women for the value he would be willing to pay men
Note that he's not necessarily willing to pay men more - the reporter says the senior staff was "mostly female," not balanced. He might have just been willing to pay men and women the same salary, which was less than what other companies were willing to pay men.
Not necessarily. He could be underpaying everyone. In which case, the degree to which women accept offers vs men would contribute to a systemic pay gap, without directly intending to.
Non-baited statement (and I'm aware it's discussed a lot here), but my experience with people saying the candidate wouldn't be a good 'fit' was just a way to enforce bias either unconsciously or consciously.
And led to problems with group-think and an inability to think in different ways.
Now granted my hiring sample is less than 100, but that has been my experience so far.
As a serious question, why do you think that dissimilar groups product faster or higher quality work? How far can you take that concept? Should they even speak the same language?
It probably makes it easier to act like a professional. If you reduce the social gel at work, perhaps more work gets done. Maybe I've gained a morning of productivity today because a conversation didn't devolve into a Simpsons quote-athon.
why should the candidate just apply for software engineering jobs? Isn't focusing on one field just enforcing their bias to a particular industry? Shouldn't we enforce basic rules that candidates apply to a diverse gamut of other jobs, such as truck driving, painting, and customer service? And shouldn't we shame them if they decline an offer for a labor job by calling out their biases? Shouldn't we require candidates to apply to more than one company? I mean, if they focused on one company at a time, that clearly enforces their bias (either unconsciously or consiously). How are we going to contain this blatant bias in job applicants?
I can't tell if you're being serious or not. If you are, then you have missed the point entirely and I would argue don't even understand what I was talking about in the first place. If you're not, then you got one over on me 100%.
It would actually be a pretty good way to see if a candidate can be persuasive, logical, able to acknowledge opposing points of view, and capable of divorcing argument from emotion on heated topics. Pretty crucial skills in the workplace!
But the problem is, that's not how it's presented. The OP stated that it was because they enjoyed having spirited debates and wanted to make sure the interviewee can hold their own (my words, not OP).
If the purpose is to do what you say, then you have to say that. If in an interview you find yourself trying to trick the people interviewing, for any reason whatsoever, you're not clever, you're a dick and your company, by extension, is a bag of dicks.
> How is that even remotely related to the job at hand?
It is not. But they cannot ask you "did you vote for party X? Because everyone here votes for party X and it would be awkward to have someone with Y sensibilities", that would be discriminating.
> When I pressed them about the relevance, they indicated that they often have heated debates on all manner of topics, so they wanted to see my thought process.
One of my favorite interviews was when I was posed the question: "you work for the railroad, we've just spent several months asking our customers how they feel about the service; the majority of them are unhappy, what do you do?".
I spent an enjoyable hour in front of a whiteboard working on ideas with the interviewer.
Yeah. I had an interview with a 2 tests. One had a you check a list of personal attributes you see about yourself (diligent, careful, fun, approachable.....) Second side of paper, same list of terms “check all that others see you as”. Then a one hour paper coding type exam.
I’ve also done a one hour codility online coding test more recently. I thought I’d hate it but frankly it’s wasnt over the top hard and kinda fun.
The correct answer in this case is of course YES, it's justified. It's a hedge fund after all. Motivate with evolutionary theory starting with Darwin and ending with Nietzsche, maybe even bring in Sun Tzu depending on interviewer.
I love that question, and may use it, or a variant, in one of my future interviews.
My reasoning: I would like my team members to be able to contribute in all aspects of product development. This includes not only engineering decisions but also work with the product managers in identifying both potential new features as well as short comings or issues with some requirements. It also tells me how narrow or broad a particular person's knowledge base is.
Let me try to put it in other words: it may tell me if a particular frontend engineer would be open to exploring backend development? What if the language stack changes, will they be open to exploring new languages, stacks, frameworks, OS, platforms. Or, will they be limited to what they know. Will they be able to just code what they're told, or will they be able to form and express their opinion about yet unknown things.
In all fairness, there have been so many articles about the craziness of that hedge fund, you should have known what you were getting into. Better to find that out in the interview.
