I hate take-home projects more than I hate whiteboard interviews. I think the best approach would be giving the candidate a broken app and have they debug it live or in a take-home debug-and-fix or debug-and-improve exercise. Could also have some refactor assignment. Has any company tried something like this before?
> I think the best approach would be giving the candidate a broken app and have they debug it live I had a company do this and it went really poorly for me. It was a python app and at the time I wasn't very expert in python. They told me to use my laptop and all I had for python was a vim environment. I knew enough python to do white-boarding problems. But debugging a complex app exercises a whole different set of sk…
I would rather spend 3-4 hours working on a take home test rather than writing on whiteboard. Last year, I did take home test for 5 different companies and all 5 of them invited me to the next round. I yet to have a successful whiteboarding interview.
But did you get any of those jobs? I wouldn't call being invited to the next round successful if you don't get the job. In fact it's a loss, more lost time for the candidate.
Yeah seriously - "rounds" don't mean anything unless they publish numbers, and even then it's sketchy. You need to be able to verify that they're actually there to shrink the pool, not just provide the impression of it. Take-homes are free for the company to issue.
This is yet another tech interview discussion, so I'd like to highlight a subthread from the one earlier this month: > I'm actually a little scared to leave my current FAANG gig for that exact reason tbh. I'm fairly certain I wouldn't make it back in the door without more leetcode grinding + repeated loops than I'm willing to do at this point in my career. >> I'm in a similar position - a tech lead role at a Big N -…
> I'm actually a little scared to leave my current FAANG gig for that exact reason tbh. I'm fairly certain I wouldn't make it back in the door without more leetcode grinding + repeated loops than I'm willing to do at this point in my career. Makes you question if this is the precise point of it.
Disagree. It makes zero sense for Twitter to make it harder for them to poach Google employees.
We use a 3 step process, sans whiteboard: 1. First interview, the candidate interviews us. What market we serve, what our development processes are, what our technology stack is. If they express interest by being prepared and asking good questions, we send them home with 2. a programming task. Choose 1 of 5 tasks. The tasks are not abstract problems or puzzles, but come out of the designs we've implemented. We ask fo…
Much better thought out than any I have performed in on either side. Thank you for sharing, this would be a good template for others who need one to follow (which many do). You also hiring?
I hate take-home projects more than I hate whiteboard interviews. I think the best approach would be giving the candidate a broken app and have they debug it live or in a take-home debug-and-fix or debug-and-improve exercise. Could also have some refactor assignment. Has any company tried something like this before?
We are a remote company. I give take home projects too. Mostly I give them couple of days but mention they shouldn't work more then 4 hours on it. Our test is actually quite simple and everyone that did any kind of development should have done these basic things. But it tells me a log of the current state of the candidate. Most code samples on internet are not production ready code. Security and error handling are mo…
> they shouldn't work more then 4 hours on it
So you're saying spending 3 and a half hours on the assignment is fine. It's not.
Take-home assignments have little to no value for the candidate, they're only feasible if you are jobless or in college. The last thing I want to do in my spare time is to stay focusing on a bogus problem that may end up discarded.
I had the same experience on some vague Postgres question for a Rails job when I was junior. I asked a similar question along the lines of: how often do you use this day to day here? Similar response.
For many engineering candidates, we ask them to design the data schema for a calendar. I’m sure my employer and the question are not a secret. We have various follow-ons, like handling the wild number of ways meetings can be periodic, exceptions, and so on. Nobody has ever asked me how often we need to build calendaring software, because I explain right up front that while this is a “toy” question, our core product f…
Schema is something you work with everyday so that is fair. Even if the particular schema is for a made up problem it's fairly close to reality.
I interviewed with one of the companies on that list a few years back (noredink). They gave a timed hackerrank style coding question as round one (so I guess technically not a whiteboard). I passed that, then I had an interview with an actual person. He asked me vague question, like what is architecture, I started to reply with what design tradeoffs I made on the app I was working on. He literally laughed at me, and…
Yeah, some interviewers enjoy the interviewee/interviewer power imbalance and like to play with it, as in this case in a sadistic way. I think that he wanted you to guess what he had in mind but when you put him on the spot to give you his definition of architecture he didn't have a solid answer or was afraid you could easily scrutinize him.
I interviewed with one of the companies on that list a few years back (noredink). They gave a timed hackerrank style coding question as round one (so I guess technically not a whiteboard). I passed that, then I had an interview with an actual person. He asked me vague question, like what is architecture, I started to reply with what design tradeoffs I made on the app I was working on. He literally laughed at me, and…
Name and shame the company. It's the best way to get them to change their behaviour.
>1. First interview, the candidate interviews us. What market we serve, what our development processes are, what our technology stack is. I somehow feel this rewards opinionated developers. Also right now I'm looking at a couple places because their recruiters called me up and said they were willing to meet my requirements which are basically pay - I don't care about most of these things, if they want me to do stuff…
Aren't opinions something an employer should want in developers? And not just opinions on tech stack but all the way up to requirements etc. If I hire a developer "to build X," I would rather work with the developer who explains that X is the wrong thing and we should actually build Y, than the one who shrugs, asks no more questions, and builds a really excellent X - that later turns out to be the wrong thing to have…
At the interview stage, the candidate has been looking at your use case for at most a couple of hours with very little context. Assuming you've done any work on X and that you are competent, X is probably a good choice or at least there's good reason to believe it is a good choice. It might be nice if the candidate asks why you chose X over Y, but they shouldn't seriously propose that you should switch over to Y. Best case scenario they're assuming their little glimpse gives them a deeper understanding of the problem than you, which suggests they're cocky, worst case they may be deliberately selling you on a potentially worse solution that they just happen to be more comfortable with, ie they're inflexible. A good developer should wait until they know what they are talking about before they form an opinion on what would be the right tool for the job.
I am starting to think the interview is a waste of time. Sure, you want to make sure the person is more-or-less who they claim to be on the surface, but you will never really understand their capability for reasoning with your problems until they are working in your process. One of my earlier jobs dealing with code involved a very brief interview (no whiteboard involved) followed by a 6 month contract offer. The deal…
Arrangements like this are much harder in US because 1) by default there is no health insurance if you’re a contractor, and obtaining your own is incredibly expensive and 2) there are also pretty complex tax implications of being a contractor; there are many other factors as well. It also puts a candidate at a disadvantage, because looking for a job is heavily one-sided burden. On a personal level, as both (occasiona…
My company does this as policy, except we hire them and put them on full benefits. However there is a 6 month period where you can be fired a lot easier than after that 6 months.
It seems like a reasonable compromise that doesn't leave the job seeker without health insurance etc.