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.
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?
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).
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.
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.
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."
> 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.
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.
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
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.
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.
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.
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.
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.
> 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.
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.”
> 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.
None of the places I've worked at had me do a coding challenge. Either they already knew who I was through networking or they asked me to show them a personal project and explain how it worked. Each job was a great opportunity.
When I start looking for a new opportunity in a year or two, I may consider coding challenges to be a soft red flag in that I don't think they're worth wasting time over. I spent so many hours in the last 6 months doing various code challenges, some of which were borderline unreasonable, none of which landed me a position. I ended up getting hired by one of the top 3 places I wanted to work, and it was mainly because I had already networked with my interviewers. Maybe they looked at my GitHub, but I never asked. Regardless, coding challenges of any kind have consistently been a waste of time for me.
Unless I really really want to work for a particular company, from now on I will immediately end my interview process if they ask me to do the following:
- On-site coding challenges
- Take home coding challenges
- Whiteboarding
- Brain teasers
I don't have time to waste on that shit anymore. If having years of experience and a GitHub don't demonstrate to you that I can write code, then I really can't help you with whatever it is you're looking to achieve. Developers have to shotgun apply to many places in order to play the numbers game of getting hired, and life is too short to work an extra hour or more every night to code something no one will ever use that won't get me hired anyway. People are generally biased towards feelings rather than facts, and any of the above bullet points mostly serve as a Rorschach test for interviewers who have already decided whether they like me or not. Someone just breaking into the industry might want to go through the hazing process of hammering out coding challenges, but I refuse to have my personal time wasted.
To anyone reading this, networking is a biggie. My dad used to tell me that and I never took him seriously because I hated the idea that schmoozing outperforms merit, but it's absolutely true. In reality, networking should be better because, at the end of the day, most people can tell whether you're competent and if they want to work with you based on how you naturally interact with them. Formal interviews barely work because everyone rehearses for them and they only prove that you were able to tackle one problem(which recruiters often alert candidates to anyway).
I interviewed at Uber before they launched. Their "take home" was to create... Uber.
Here's the exact challenge:
UberCab Coder Challenge
1) Write a program that determines the wait time, trip time, rating, and fare for a black car trip in San Francisco, given that the customer's pickup location and destination is randomly placed anywhere in San Francisco proper, and given that there are X number of cars all placed randomly across the city. Use GoogleMaps API for trip duration time. Run simulation 100 times for 1, 5, 10, 20, and 50 cars. Output average wait times and trip times for each # of cars the simulation was run on.
2) Take #1 and do the same pickup and trip time calculation given that there are Y customer requests per hour (extra credit if this is done with a Poisson distribution ;)). Take into account each car's availability (given that they may have been selected to carry a customer and are in transit on pickup or on actual trip, and thus unavailable). Run simulation given the number of cars in #1, but for each simulation in #1, run once for Y=1x, 2x, 5x, the number of requests per hour (X being the number of cars in the city, as defined in #1)
3) Take #2 and then make a GoogleMaps mashup that then shows the various trips that were taken for each simulation. Provide mashup interface showing all trips but also provide ability to only show trips for each driver.
4) Write a "Hello World" app on the iPhone that for a certain driver logging in shows all of his trips taken in the last simulation, the average rating that he got, and the total fares he collected during those trips.
Is there a reason there's no naming and shaming going on here?
One company asked me to do an implementation of the Bay Area MUNI network which fetched live updates of the locations of all buses every 10 seconds; there was more to it but I can't remember it now. This was to be done in React with D3 and no additional libraries were to be used to help with integrating D3 maps in React.
The role was junior level, the job listing did not specify D3 as a requirement (which pretty much guarantees a lot of people would start into it without realising maps are one of the more complicated things to do in D3 as a newbie or how poorly D3 played with React), the role was in Europe.
If someone can confirm I'm not breaking any rules I'll happily share their name.
The best interview experiences I've had are with groups who just went through my (not very impressive) Github. A small coding challenge can be good as a thing to talk through during the final interview but anything longer than that and I'll tend to pitch sending them something I wanted to make in my own time regardless.
Awesome to read about you turning this into your own startup.
One thing I came to think about regarding the "4-5 hours" and throwing 5 working days on it, is that, maybe as an interviewer it is quite obvious that you put more than 4-5 hours into it and what they were "really" after were the trade-offs you would have made if you put 4-5 hours into it. Just a thought.
I recently completed an interview junket. One of the companies I really wanted to get into gave me a take home. I completed it in the time they said it would take, submitted it, and then got bounced out. My inside source said that the submissions are run through an acceptance test suite (not exposed to the interviewee, of course) that can automatically bounce people out of the process with no or little human intervention.
I once completed the task sent to me by a prospective employer, and then thanked them and said I wouldn't be submitting it, as it told me enough about the way they worked to know I wouldn't enjoy it.
Never forget that the interview process is two way ...
Some companies do technical interview great, but there are a couple things that I have noticed that always make me question if I actually want to work somewhere:
- Being sent to a website to do a take home coding exercise, with a checkbox basically saying "I won't use the internet, stack overflow, or similar". I get that you need to test my knowledge, but shouldn't you care more that I know how to search for my problem and understand a fix instead of flailing around?
- (this one I have noticed in person) Being handed a thing to build, being told I have a limited amount of time. That all they want is a proof of concept, but the tooling they are asking me to use go completely against the idea that it is a "proof of concept" since they make certain assumptions about the end goal. EX: deploy something with terraform but we don't want you to build an AMI or anything like that so just manually go into each system once you create it
This is a really great marketing example! The creator has combined a top page HN post with a PH launch at the same time with really polished looking apps & landing pages.
Essentially this will give them a huge traction boost on the app stores and a bunch of new users. Super impressive.
[+] [-] sethammons|6 years ago|reply
[+] [-] jboggan|6 years ago|reply
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.
[+] [-] amelius|6 years ago|reply
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?
[+] [-] davidbanham|6 years ago|reply
I fixed that problem for my candidates then turned it into a startup:
https://takehome.io
[+] [-] pbhjpbhj|6 years ago|reply
[+] [-] greysteil|6 years ago|reply
[+] [-] ashelmire|6 years ago|reply
[+] [-] llamataboot|6 years ago|reply
[+] [-] josh2600|6 years ago|reply
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.
[+] [-] jordansmithnz|6 years ago|reply
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.
[+] [-] legohead|6 years ago|reply
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."
[+] [-] djsumdog|6 years ago|reply
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.
[+] [-] adwww|6 years ago|reply
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.
[+] [-] minimaxir|6 years ago|reply
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.
[+] [-] amondal|6 years ago|reply
[+] [-] jogjayr|6 years ago|reply
[+] [-] duxup|6 years ago|reply
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.
[+] [-] irrational|6 years ago|reply
[+] [-] vincentmarle|6 years ago|reply
[+] [-] beersigns|6 years ago|reply
[+] [-] Damogran6|6 years ago|reply
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.
[+] [-] threwawasy1228|6 years ago|reply
[+] [-] VBprogrammer|6 years ago|reply
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.
[+] [-] kemiller2002|6 years ago|reply
I am so glad they didn't want to go further as I am sure they are a nightmare to work for.
[+] [-] nwatson|6 years ago|reply
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.
[+] [-] rdez6173|6 years ago|reply
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.
[+] [-] agrippanux|6 years ago|reply
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.
[+] [-] jcadam|6 years ago|reply
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.
[+] [-] hguant|6 years ago|reply
>“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.”
[+] [-] Loughla|6 years ago|reply
Why would you sabotage possible good candidates just so you can get your needless debate rocks off?
[+] [-] gwbas1c|6 years ago|reply
[+] [-] gav|6 years ago|reply
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.
[+] [-] acomjean|6 years ago|reply
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.
[+] [-] robocat|6 years ago|reply
You self-selected out, because you didn't like their culture.
Seems like a great outcome for both parties!
[+] [-] conanbatt|6 years ago|reply
[+] [-] justbaker|6 years ago|reply
Ever more reason to go outside ones comfort zone.
[+] [-] officehero|6 years ago|reply
[+] [-] yumraj|6 years ago|reply
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.
[+] [-] starpilot|6 years ago|reply
[+] [-] dentemple|6 years ago|reply
[+] [-] unknown|6 years ago|reply
[deleted]
[+] [-] ravenstine|6 years ago|reply
When I start looking for a new opportunity in a year or two, I may consider coding challenges to be a soft red flag in that I don't think they're worth wasting time over. I spent so many hours in the last 6 months doing various code challenges, some of which were borderline unreasonable, none of which landed me a position. I ended up getting hired by one of the top 3 places I wanted to work, and it was mainly because I had already networked with my interviewers. Maybe they looked at my GitHub, but I never asked. Regardless, coding challenges of any kind have consistently been a waste of time for me.
Unless I really really want to work for a particular company, from now on I will immediately end my interview process if they ask me to do the following:
- On-site coding challenges
- Take home coding challenges
- Whiteboarding
- Brain teasers
I don't have time to waste on that shit anymore. If having years of experience and a GitHub don't demonstrate to you that I can write code, then I really can't help you with whatever it is you're looking to achieve. Developers have to shotgun apply to many places in order to play the numbers game of getting hired, and life is too short to work an extra hour or more every night to code something no one will ever use that won't get me hired anyway. People are generally biased towards feelings rather than facts, and any of the above bullet points mostly serve as a Rorschach test for interviewers who have already decided whether they like me or not. Someone just breaking into the industry might want to go through the hazing process of hammering out coding challenges, but I refuse to have my personal time wasted.
To anyone reading this, networking is a biggie. My dad used to tell me that and I never took him seriously because I hated the idea that schmoozing outperforms merit, but it's absolutely true. In reality, networking should be better because, at the end of the day, most people can tell whether you're competent and if they want to work with you based on how you naturally interact with them. Formal interviews barely work because everyone rehearses for them and they only prove that you were able to tackle one problem(which recruiters often alert candidates to anyway).
[+] [-] thoreauway|6 years ago|reply
Here's the exact challenge:
UberCab Coder Challenge
1) Write a program that determines the wait time, trip time, rating, and fare for a black car trip in San Francisco, given that the customer's pickup location and destination is randomly placed anywhere in San Francisco proper, and given that there are X number of cars all placed randomly across the city. Use GoogleMaps API for trip duration time. Run simulation 100 times for 1, 5, 10, 20, and 50 cars. Output average wait times and trip times for each # of cars the simulation was run on.
2) Take #1 and do the same pickup and trip time calculation given that there are Y customer requests per hour (extra credit if this is done with a Poisson distribution ;)). Take into account each car's availability (given that they may have been selected to carry a customer and are in transit on pickup or on actual trip, and thus unavailable). Run simulation given the number of cars in #1, but for each simulation in #1, run once for Y=1x, 2x, 5x, the number of requests per hour (X being the number of cars in the city, as defined in #1)
3) Take #2 and then make a GoogleMaps mashup that then shows the various trips that were taken for each simulation. Provide mashup interface showing all trips but also provide ability to only show trips for each driver.
4) Write a "Hello World" app on the iPhone that for a certain driver logging in shows all of his trips taken in the last simulation, the average rating that he got, and the total fares he collected during those trips.
[+] [-] JansjoFromIkea|6 years ago|reply
One company asked me to do an implementation of the Bay Area MUNI network which fetched live updates of the locations of all buses every 10 seconds; there was more to it but I can't remember it now. This was to be done in React with D3 and no additional libraries were to be used to help with integrating D3 maps in React. The role was junior level, the job listing did not specify D3 as a requirement (which pretty much guarantees a lot of people would start into it without realising maps are one of the more complicated things to do in D3 as a newbie or how poorly D3 played with React), the role was in Europe. If someone can confirm I'm not breaking any rules I'll happily share their name.
The best interview experiences I've had are with groups who just went through my (not very impressive) Github. A small coding challenge can be good as a thing to talk through during the final interview but anything longer than that and I'll tend to pitch sending them something I wanted to make in my own time regardless.
[+] [-] hising|6 years ago|reply
One thing I came to think about regarding the "4-5 hours" and throwing 5 working days on it, is that, maybe as an interviewer it is quite obvious that you put more than 4-5 hours into it and what they were "really" after were the trade-offs you would have made if you put 4-5 hours into it. Just a thought.
[+] [-] zrail|6 years ago|reply
PROTIP: don’t do that.
[+] [-] ahoka|6 years ago|reply
https://www.wareable.com/media/images/2017/03/google-fit-app...
WTF Google?
[+] [-] swish_bob|6 years ago|reply
Never forget that the interview process is two way ...
[+] [-] nerdjon|6 years ago|reply
- Being sent to a website to do a take home coding exercise, with a checkbox basically saying "I won't use the internet, stack overflow, or similar". I get that you need to test my knowledge, but shouldn't you care more that I know how to search for my problem and understand a fix instead of flailing around?
- (this one I have noticed in person) Being handed a thing to build, being told I have a limited amount of time. That all they want is a proof of concept, but the tooling they are asking me to use go completely against the idea that it is a "proof of concept" since they make certain assumptions about the end goal. EX: deploy something with terraform but we don't want you to build an AMI or anything like that so just manually go into each system once you create it
[+] [-] albertgoeswoof|6 years ago|reply
Essentially this will give them a huge traction boost on the app stores and a bunch of new users. Super impressive.