I normally choose divide by 10 for exams as I could do divide by 3 for exams from a different professor/class.
I know the material cold, know the test cold, and don't have to worry about hidden traps--so I expect to take less than 1/10th the time of a student.
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’m still not sure why people expect it’s easy to fit this in and it’s the last thing you want to do after a hard day of work.
I’ve just started taking a full day off for programming exercises I do when interviewing. It allows me to give well thought through and tested solutions even if I make some small mistakes or misunderstandings. Crazy I know but necessary usually these days.
Apparently its got something to do with the whole team getting together and publicly code reviewing your assignment. And if they feel like the code doesn't fit even to the exact size per their liking, its a reject.
I have had a similar experience, where a perfectly done assignment with unit and functional tests, documentation and all the bells and whistles, It took me two full sleepless nights to get it done. But apparently they rejected, for me not using a specific design pattern which one reviewer likes.
It's absurd to the point of disbelief.
Trust me the take home assignment is a sham. People inside get their friends and alumni hired with no hassles. They only give you these tests because they need reasons to reject you.
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?
A 2-4 hour challenge is less time than I've spent in interviews at some companies, and would gladly have done it prior to an in-person interview given the option. That way, the actual interview time could have been spent talking about things of value, rather than having them stare at me while I white-board out problems around graph data structures and recursion and whatever other trite trivia they can come up with.
If you give me a 2 hour challenge with a timer so I can't possibly take more than 2 hours, I'm fine with that - but you won't accomplish the "lower stress" goal.
But if you give me a 2 hour challenge without timing? I know for sure other people will have spent 8 hours making super-polished, gold-plated solutions. Can I afford to fall behind the competition? If not, I should spend 8 hours too.
I helped redesign the code challenge at one of the companies I worked for. We (the people across the different technical disciplines we hired for) put a lot of effort into ensuring that:
* the challenge could be completed in 4 hours
* the challenge resembled the sort of work people would do on the job
* the goal of the challenge was to inform a follow up interview, not punish people
* candidates were explicitly told that they were not being timed, but that we expected the challenge should take them up to 4 hours to give an idea of the upper-bound level of effort expected
The single biggest challenge was balancing "what do we need to know" versus "what would we like to know" versus the amount of time we were asking of our candidates.
We didn't hard-fail anyone unless they were blatantly not a good fit from their submission, and I habitually wrote multiple pages of feedback for them so they at least got something for their time if they didn't get a follow up interview.
Again, the purpose of the challenge was not a screen, so much as it was to help guide the in-person interview and so we had something concrete that we could discuss.
Follow up edit:
Designing code challenges is hard. You have to avoid something so objective it can be copy-pasted from stack overflow, but objective enough that it can be graded free from personal bias (as much as possible anyway). On top of that, you can't test for MVC+CQRS+FP+SOLID+every-other-possible-thing under the sun, because you have to be respectful of candidate's times.
The previous code challenge (the one I replaced) would frequently take people 8-20 hours to complete, and it was actually pretty simple. As you rightly pointed out though, candidates often read far more into the requirements than were actually there, and would often over-achieve in an effort to stand out. Not only would those submissions waste their time, it wasted ours as well as they took longer to develop feedback from.
Unless your challenge literally stops at, "make X appear onscreen" with no regard for quality, testing, etc. Giving unchecked/unverified time restraints isn't fair. It doesn't matter you're giving more time than it should take to complete. If the task can be done in 2 hours, but you give "6" and Candidate A does it in 3, but Candidate B does it in 32 (but tells you 6) you're ranking two totally different submissions. Candidate B might have a super polished submission, while Candidate A has a baseline submission.
The poster you replied to was suggesting that tests should be either 1) not based on quality of submission and simply rely on difficulty so that only a few candidates can complete them or 2) based on quality and difficulty, but with a checked and verified time to keep the playing field level. However those options are both at odds with "low stress."
So, if someone submitted something that could have been done better, see might ask what could be done to improve it in the follow up interview. A good answer would include the technical bits, and a better answer would describe the time recommendation and why a more polished version would take longer or be considered over-architecting.
This purpose- to inform a conversation with a concrete, familiar code base- is better than both take-home screen assignments as well as the in-person whiteboard exercises, which encourage route memorization and don't reflect the nature of the job we were hiring for.
Two of the last three companies I interviewed at had at least 4 hours of in-person interviews. One of those (for a regular developer position, around 7 years ago) had multiple whiteboard sessions with different people. The problems were trivial to solve if you had access to google or had memorized basic data structures and related algorithms. Instead of taking half an hour or an hour talking about the code I'd written to solve a problem representative of what the actual job entailed, we spent 4x as much time (during business hours) talking about things freshmen learn in CS programs (I'm assuming here, I didn't get a CS degree).
Even if the total amount of time is the same, or even greater, I still prefer the take-home assignment because I can do it on my own time, rather than taking off of work, and - if done correctly - makes for a much interview.
As a candidate, you learn far more about the people you're going to be working with than in a whiteboard session as well.
How did this become acceptable practice for hiring people? Do any other industries besides tech do this?
I think the only fair option is an in-person interview without homework assignments. Treats everyone the same and doesn't require inordinate time commitment.
If I want to interview at 6 places that just use onsite interviewing it's easy to figure out how to prepare.
I'm not sure where I stand on this sort of thing to be honest, my only experience of anything similar was a pre-interview task to implement a simple 10 entry LRU cache, and after getting the job I was told the only reason it was there was to weed out time wasters with next to zero skill being sent by the recruitment company.
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.
Absolutely worth it if it gets you the right job. Hell, most people pay multiples of that through recruiters and referrals.
Maybe 10% of them get back to you with an interview request and that leads to a code challenge. It's highly plausible for a senior Dev to be simultaneously interviewing with multiple companies and have 5-10 pending code challenges. That shit adds up...
But the company sees the value in doing it, and many people dont see the value in doing it for themselves.
How magnanimous. Who the hell is subjecting themselves to this?
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.
The process was much the same as you described: multiple day test followed by taking two days off to fly out for the interview. Except I didn't get the job and nobody who interviewed me ever looked at the take home test.
The 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.
To make this more fair, why not let the designer work at the company's office, so the interviewer can actually see how much time it took, and the interviewee doesn't waste more time than necessary?
Less convenient for people who have a different job at the same time though.
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'.
You took out the time to go to some office. You just spent an hour talking about your hobbies and attitudes and the company's working culture etc. Then, a programmer asks you to balance a red/black tree. You do.. what? You angrily throw the marker on the ground, cry insult, and run out the building? No, right? So then what?
I see this repeated a lot on HN and I'm not sure I'd have the guts to walk out of an interview. To be honest, I doubt many people do.
How about a phone call or a quick email to ask what is their hiring process, what is the work and how it is usually fulfill?
In the current market you are not a seller, you are the buyer. Why should I consider working for you?
I don't think memorization of an algorithm is what should make a senior level candidate stand out. Senior people need to be able to lead, mentor, self manage (this is a huge one IMO), and understand the bigger picture. "How do we avoid having to balance this tree at all?"
The role of the senior Engineer isn't to tell you how to balance the tree. You, or anyone you instruct to, can simply ask google that or use a library.
Their role is to ask why we need to balance the tree. You very definitely can't ask google that, and that's why you need to hire a senior Engineer.
"Hi <dev name>! I think we may need to optimize memory consumption of this distinct element counting code a bit; I remember there is some HyperLogLog algorithm which should help here... let's check how it goes... (reading Wikipedia page)"
My experience is that hireing descicion is so noisy that there are no reason to invest too much since the rate of sucess is barely increased anyway.
The more picky the employer seems the less reason to apply. It might be a internal candidate allready chosen or they are just hoarding resumés to keep recruiters occipied.
The decision is allready made from the from the first minutes ... but you can ruin it of course.
I'm with your comment's parent: I don't think I'd have the guts to walk out of an interview either, especially for a job I applied to first.
For company who reach me, it is mandatory.
I'm not sure this is the best approach...
Have you no common courtesy? I terminate the process as soon as I find out I'm not a good fit for the company or vice versa, no matter who initiated first. Continuing with an interview when I'm sure I'm going to decline is just wasting everybody's time.
I've heard of companies asking for proof of other offers so saying so and so offered me 2x is a very risky play if untrue.
My point is that it is also risky if it is true, but the other offer is not a job you would take.
I have walked out of interviews as well. Sometimes the interviewer and I discover together that the recruiter we worked with didn't know their job, at all!
More often, though, it sort of was clear from the start of the interview that the company would not be a good fit for me. I would tell them so, and my reasons why I thought so, and leave after thanking them for their time.
If they ask me to do some simple programming task, I ask them if they have looked at my Github repository and what they think they will learn during the simple task they could not from my repository. If they do would have a good answer for that, for example they want to get to know my thought processes while coding, I am happy to oblige. But if they clearly have not looked at my Github repositories, nor have any inclination to customize the interview process, I tell that I do not believe in the validity of the process.
I have also walked away twice during the one-month trial period. Once the company was unable to find a project for me, even though they kept on promising there would be one for me soon. The other time I discovered I was unable to combine working full-time with finishing writing my PhD thesis.
Anyway, I also found that in half of the cases I walked out,
the other party did understand and accepted why.
Of course, it is easy to walk away when you know you will find a job soon anyway and even if you would not you will get some support from the government anyway.
If they don't wave you off at the suggestion, you also get to meet everyone and see their work environment.
What I feel is more important is a persons thought process on how they approach a problem and come to a solution.
One hour interview cannot be more than just screening, when split 50-50 to give candidates enough time to ask their questions. It leaves ridiculously small amount of time to the really interesting technical topics. And this discussion is important: CVs are not trustworthy, plenty of people lie or exaggerate the facts — only a live talk can verify the necessary knowledge, experience and skills. It may not be enough, true, but hiring someone after barely speaking to him is unnecessary risk. And hiring someone without necessary practical knowledge and without proving the ability to learn quickly is the same.
Are you sure you meant to say what you wrote? I'm not aware of any place that has figured out how to properly screen candidates in one hour. If you know how to do it, please share, it would help all of us.
I have to wonder if they didn't get the position because they spent more than the advised time for the task.
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.
Maybe the same situation applies in Design somehow? I mean yeah it takes 4 hours to make the product if you happen to have all the graphical elements you will be using already downloaded and organized.
on edit: although I have noticed a disappointment in some places that I have not done a lot of time cleaning up the code after writing it and making everything beautiful and writing a good readme to tell them everything to do and so on and so forth and normally I don't do those things because I spent more than 4 hours because there was stuff that needed fixing and anyway if they wanted all that 4 hours would not be enough.
Coding is like math homework. When your doing the math homework you know when your done, it's very obvious and anyone can check your work and clearly see it's either right or wrong.
Design is like a book report for English class, it's bottomless and can always be improved given more time, albeit with diminishing returns. Design challenges are evil and bullshit, you can poor hundreds of hours into a design challenge and still iterate further.
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.
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
If that makes them look like assholes, yeah, I can see why someone would feel that way but at least they are clear about their intentions and not insulting anyone's intelligence in the process.
It'd be more useful to know they could execute roughly what I'd expect in 3-5 hours. As in they think quickly, come up with something, get the basics down and are ready to progress or not.
...Of course, if they're doing it at home they could spend 3-5 days on something I'd spend 3-5 hours on and I'd never know...
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.
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.
I had an interview once where we were on the phone, I got the task, and they told me they'd call me back 2 hours later.
Might be easier if the office is far away.
My last company they flew me from another continent to do a 3-days assessment, I worked with the team on a legitimate feature(that would be trashed after as they couldn't use the code because I was unpaid). I liked it, I met the team, I interacted with them, I did the task and got a job offer in the end.
All engineers at the company highly valued the 3 days assessment because we got to select great people to work with, but we were getting too many candidates giving up or false negatives, they eventually cut it down to 1-day despite our protests.
Honestly it's stuff like this, that has me contemplating giving up this career path because there's just no more room for people in their 50s with 25 years of experience in information technology, who aren't willing to sleep at the office, drink your "insert trendy microbrew here" on tap, and suffer through a ludicrous ask like "we want you to work for three days for absolutely nothing to see if you're a good fit".
If you are traveling internationally, then you have to add 1 day of travel on each side of your trip. Plus the 3-day "interview" or challenge or whatever. So that is 5 straight days of interviewing for a job. That is actually asinine.
If you have a current job (most software developers do, especially the good ones) then that is an entire work week that i have to request off at my current job to go to unpaid work with no guarantee of getting a job afterwards.
I can't believe someone has actually done this. It is crazy!
The author of this article fucked up when he tried to pass off 5 days of work as an example of what he could accomplish in 5 hours. I am glad he was able to find inspiration from it, but for the success of his startup I hope he also is able to understand other, better ways he could have approached the interview task.
I fixed that problem for my candidates then turned it into a startup:
Ideally that wouldn't be a legal policy for my company to enforce, but that's the reality for me right now.
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.
It’s one of those things that sounds easy but really, really isn’t possible to do in the time allotted. I learned a lot about interviewing people that day.
> I learned a lot about interviewing people that day.
Could you share what you learned?
If someone made it to an onsite and you don’t know whether they can add a button in swift, something failed in your screening process. If you’re testing how someone navigates a codebase, you can just look at it with them, and let them drive the chat.
If you’re testing an engineer for a serious job, do an algorithms test. If you’re testing an engineer for a specific thing, test that specific thing. Both of those should be handled in the screen, not the onsite.
IMHO, the onsite is about seeing how people think. Whether you can jam a button into a repo doesn’t tell me whether you can think or not. I guess it tells me whether you get flustered, but it’s pretty unfair to design things that are impossible just to see if people break.
That candidate turned out to be awesome but I remember the interviewer telling me after they interviewed them “well, they couldn’t add the button, but as they were doing it, I realized I wouldn’t be able to add the button either so my interview was inconclusive”, and I replied “well it sounds like you need to design a better interview question”. The worst part was, the interviewer spent the first 20 minutes of the interview talking with the candidate before giving them 25 minutes to add the button!!
There’s a question we gave candidates really early on which we no longer do because it biases towards math nerds that I absolutely loved. It’s based on a movie called 13 Tzameti. I’m probably screwing it up because it isn’t my question but it’s basically like this:
You’re in a dark room after being abducted by a gang. The lights come on and there’s 12 other people in the room in a circle and everyone has a revolver with 1 bullet in it (6 slots in the chamber). Your instructions are to spin the chamber on the revolver and, when the lights go out, shoot the person to your right in order.
What are the odds you make it to the next round?
It’s a crazy question and, what’s even crazier is that for some reason, as you increase the number of people in the circle, the odds of making it to the next round converge on 1/e. No one has figured that out in the interview. Also no one has figured out why it converges on 1/e so if you have any ideas, let me know.
I like this question because it shows you how free thinking people are. I dislike this question because it biases towards smartasses and probability nerds.
Being a senior engineer is knowing the difference between doing what your told and figuring out what needs to be done to achieve project success. In this case, getting to the next round.
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.....
So, let's see. Suppose n is very large; then the probability that you live is approximately equal to the probability that your predecessor does; call that q. Then, as above, you live iff your predecessor dies (probability 1-q) or your predecessor lives but fails to kill you (probability q(1-p)). So q = 1-q+q(1-p) = 1-pq and 1 = 1/(1+p).
That's a long way from 1/e, and a quick simulation seems to confirm this answer. It doesn't change a lot if we assume that a random person always fires first, instead of you, or if we assume that you're always last (which I think was the situation in that movie).
If everyone has a revolver with n slots and one bullet, and they all fire at _you_, then you have a 1/e chance of survival for large n, but that sounds too different (and too easily found to be 1/e) to be the right thing.
The probability p(n) that a permutation of n things is a derangement -- which tends to 1/e as n->oo -- satisfies the recurrence relation p(n) = [(n-1)p(n-1)+p(n-2)]/n; is it possible that the correct statement of the problem here leads to that same recurrence?
The question is "what's the probability you die?".
Edit: You can also challenge people to think about the problem where everyone fires at exactly the same time OR random order since people have different reaction times.
Edit 2: "The probability p(n) that a permutation of n things is a derangement -- which tends to 1/e as n->oo -- satisfies the recurrence relation p(n) = [(n-1)p(n-1)+p(n-2)]/n; is it possible that the correct statement of the problem here leads to that same recurrence?" <--- My engineer says that derangements are the correct key to the convergence.
If everyone shoots simultaneously (so in particular everyone does get the chance to shoot) then I die iff the one person shooting at me hits me. Probability equals probability that a given shot hits (so in this case 1/6). No dependence at all on the number of people.
If everyone shoots sequentially, this seems just like what I described above. Probability of death is now p/(1+p) instead of p, at least if you're first to shoot and n is very large. (Unless something's very broken in the heuristic argument I gave. Let's try another. First approximation says a fraction p of people die. But that's not quite right because people who die don't get to shoot, so next approximation says we get p(1-p). Next approximation says we get p(1-p(1-p)). Etc. We can either solve the obvious equation, or else notice that we're getting more and more terms of the binomial expansion of p/(1+p).
I don't see anything here that doesn't look, in a crude approximation, like a fraction p of people dying (p, again, is probability that a given shot hits, which in this case is 1/6).
I must be misunderstanding something in the problem statement here. Perhaps it would be clearer if I'd seen the movie?
Oh, what about this version? You shoot first, things proceed cyclically, and we keep going until just one person is left. What's the chance that it's you? Naively it seems like this should be approximately 1/n no matter what p is; shooting first could confer some advantage but surely it can't be much for large n. So this can't yield anything like 1/e either. Drat.
import numpy as np
self.dead = False
self.right = None # The person to the right
# 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)]
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
>>>sum([simulate(10000) for j in range(1000)])/1000
"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."
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).
1. The button doesn't have to do anything
2. You give them a fast computer with an IDE loaded with the project
3. The developer is familiar with the language, UI framework and IDE
4. You aren't doing anything crazy and uncommon like using a non-standard UI toolkit or using an ad-hoc source code preprocessor
5. The project can be built and run with a single command and can be built and start in less than a minute
I opened the PDF to find not one, but three separate tasks. Completion of all three was expected, with an estimate of about two hours each. One of the tasks was to replicate Apple’s ‘Reminders’ app in its entirety, backend sync functionality included. Another, a task requesting Visual Studio (iOS devs have no need for any experience with this).
I promptly replied declining to continue the interview process. If you’re ever in a similar situation, interviews can sometimes tell you more about the company than they can learn about you. Good chance I dodged a bullet, and could have been working for someone setting highly unrealistic client deadlines, with the expectation that I can build something in any technology proficiently.
I 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."
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.
Oops, 2 hours.
I often give companies a list of open current open source tasks I'm working on. Pick one and I'll complete it for your interview. Every singe company turned me down, except one, who just accepted one of the tools I had on Github and examined that.
The startup sounded interesting, and I might have been prepared to spend the recommended 5 hours on the code test, had I had a chance to actually go into the office and meet the team...!
At least at the end of a Google interview you get to work for Google.
I eventually made the dashboard but it took 16 man hours; on the on-site, the interviewers implied they didn’t like it as it was not feature complete. (I called them out about the BI tool; they weren’t happy about it but admitted I was correct that it would be more efficient)
Now that I have had more experience as a data scientist, the real-world response to such a framing is to push back against the PM and write an implementation spec with a defined scope.
I 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.
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.
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.
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).
So I suppose if you're honest about it, and you give a fair estimate of the time required, then what's the problem?
We're not evaluating them on whether they got the same answer as us. We care about hearing aloud their thought processes.
Means a lot of letters from kids get read only by the secretary till the identify it and destroyed.
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.
For a long time I thought it was perhaps due to poor sync with the Mac, since sometimes I manage reminders from there, but the same thing happens with the wife's phone and she doesn't sync Reminders. She has a single daily reminder at 10pm. Sometimes it shows up 4 times. Sometimes 4 times and 1 disappears for a net of 3 reminders. Sometimes just 1 shows up. Sometimes none of them show up. It's bizarre.
I've stopped thinking about it as "glitchy" and more "the new Apple way".
Perhaps you should try logging off and logging in again.
I totally agree.
He let me reschedule for later that day but seemed hostile and grumpy throughout the whole thing. Didn't get the next round.
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.
Also, OP launched on product hunt today. Calling them a "successful company" is generous if not outright false, though I wish them every success.
Stated less dramatically, what happened here is "I turned my design interview prompt into a real piece of software". That doesn't imply that google's interview questions are too hard. A software company asking for a deliverable that approximates software is sane.
I think the time that google demands for their take-homes is a bit much (explicitly, this is 4-6 hours. in practice, it's 20 to 30 if you want to deliver at high caliber). But the questions/prompts themselves are intentionally quite boring, and exist to see how far you can take it.
I found them to be pretty good. These kinds of questions depend somewhat on chemistry between candidate and prompt, so they ask more than one of them, which is great. The takehome I picked was the only one of the 3 offered I could even pretend to care about. Of the two asked onsite, one I felt I delivered on at only the most basic level, and one I think I could have credibly patented / raised a series A for were it a thing I cared to spend 2 years on.
This is a problem with a lot of take home assignments of many types (not just programming). If someone has landed an interview at a company they really want to work for, it's almost not rational for them to just bang out something that's "good enough for government work" some evening rather than taking the time and care to really do it properly.
But this doesn't scale if they're interviewing at a number of companies and/or otherwise just don't have much free time.
So clearly the process isn't working here.
And sometimes its easy to memorize such solutions. Translating a real life problem into a computer science one requires some skill.
Why? The big tech companies offer high salaries and get lots of applicants. They can afford to be picky.
And by the way, OP went above and beyond what they asked of him. In fact, there's a chance that this hurt his chances.
>This is a visceral demonstration of how absolutely ridiculous interviews have gotten.
This kind of format isn't standard across the industry.
I do a lot more writing than programming and, for someone for which that's one of their primary jobs, I would absolutely want to see writing samples--and, if they didn't have one they could share, they're going to need to write something custom.
I honestly don't get the max 1 hour interview process. You're probably not that special. I guess I did just have an interview over lunch once but I had known (and worked with in various capacities) the person making the hiring decision for years. Other than that, I've always had multiple interviews, if only so that multiple people could talk to me. As an interviewer, I really like having the perspective of multiple people precisely because it is a very imperfect process and people miss things.
As I said in another comment, (paid) interning and hiring someone as a contractor/consultant for a fixed period are great for situations where it works for everyone. But, if I'm looking for a new full-time position, I'm almost certainly going to pass on a position that doesn't carry with it the presumption of ongoing employment.
[ADDED: And, yes, some companies have an official probationary period but AFAIK that's mostly reserved for when a hire really isn't working out for some reason.]
I 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 am so glad they didn't want to go further as I am sure they are a nightmare to work for.
I don't like all aspects of its design but after getting through its initial quirks the Android Simple-Workout-Log app is dead simple and bare-bones and works quite well without the busy graphics.
EDIT: additional point.
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.
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.
>The worst answers had the exec killing people
Play stupid games, win stupid prizes?
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.
Maybe because they're faster?
Hardly a success story, in my opinion.
But as an employee, I’d sure prefer being treated like a human being...
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.
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).
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.
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....
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.
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.
Not quite sure why. Some tries:
1. A mistake implies a single decision.
2. Slavery worked as intended, right? It was more evil than mistaken.
Either way, you sure derailed my derailing of the topic, so I'll stop here :)
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?
Democracy means shifting it from a small number of people keeping you in power to all of the people. It's not easy.
CGPGray did a great video on this model: https://www.youtube.com/watch?v=rStL7niR7gs (Based on The Dictators Handbook by Bruce Bueno de Mesquita and Alastair Smith.
- 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?
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.
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.
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.
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.
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.
"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."
An insane question. But perhaps a good question.
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.
That's why this is a terrible question.
"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.
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.
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.
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.
On the other hand, I don't want to work in a group where the right answer only gets picked if it's backed by someone with an assertive personality.
>“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.”
I'm 5/7 out of 22, +2 if I go back a decade or two
So that's 4 I definitely haven't done, 4 I kinda did, and 13 I definitely did (I count 21 total not 22).
lol tyop , I also count 21
Why would you sabotage possible good candidates just so you can get your needless debate rocks off?
Maybe I'm living under a rock, but I've never heard of that. Would you mind sharing a link?
> 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.
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.
I would be very happy to have answered that question and would be a plus one in my books if I can have these types of heated talks with my coworkers.
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.
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.
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.
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.
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.
You self-selected out, because you didn't like their culture.
Seems like a great outcome for both parties!
Ever more reason to go outside ones comfort zone.
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.