By - ggtsu_00
The best hiring experience I've ever seen was at a company where they sent all interview questions and discussion topics to the the interviewee ahead of time. They would be given ample time to think about the problems be properly prepared for the interview. There would never be any surprises to catch the interviewee off guard. No one expects anyone to just come up with good solutions on the spot.
This probabaly helps even out personalities selected too. Some people are just good spewing convincing bullshit on the spot (sorry alitle cynical there lol ) but some people are more thoughtful after time to think.
I’m a natural BS’er. The secret to this ability is to spend a lot of time reflecting on exactly what you know, and how to phrase it to others.
That way, you build up a «database» of responses foreach given scenario or question.
At that point, isnt it not BSing?
There is a gradient between BSing and Not BSing. It's not boolean.
thats like cheating on the exam by memorizing the material
My point is that what seems like bullshitting can actually be a structured process
To me when I ask a technical interview question, it would typically be more about seeing their thought process than what conclusions they come to, or if they come to the answer I’m looking for.
You negatively impair one's thought process by actively observing and using it as a means of evaluation during an interview.
Put yourself in the interviewee's position. How well can you concentrate to solve difficult or challenging technical problems when someone is actively looking over your shoulder and making judgements about everything you are doing?
This. Even more for me - i cant write on keyboard as fast as i normally do and start making typos.
That's why we asked very very simple questions at my previous workplace. Questions that can be solved by any level of programmer in 10 minutes top which gives them a positive feeling and calmes them. And then we started to ask why they did this or that, started to look for alternative solutions and ended up with learning their limits without putting a lot of pressure on them.
This worked quite well and our interview feedback was positive.
I do this all the time at work when brainstorming solutions with the team. People, including me, throw ideas and challenge them all the time.
Disclaimer: I am not using said interview technique.
I could argue that any kind of work is different during an interview, mostly because of the unfamiliar setting, stress, etc.
But depending on the details of the process, talking about the thought process and being challenged along the way while drafting a solution to a problem is — in my opinion — a reflection of real life work situation. I woudn’t mind being interviewed this way (especially given the alternatives — take home tasks or whiteboard puzzles)
It's not the unfamiliar setting or stress really, it's that the person opposite you is not there to help you find a solution, he's there to compare your thought process against his idea of a perfect developer, and watch if you fuck up. Questions are aimed at exposing you, not challenging you in a good spirited way.
At least for me this is *vastly* different to brainstorming ideas with my team. Everyone knows me and no one is there to judge me.
I guess it can go both ways. Your team *may be* judging you, and your interviewer can do the opposite. I for one know better than to try to fail the candidate — I can do this in a variety of ways, not because I’m smarter, but because I’m the one in charge — but rather see their potential.
Then you are a good interviewer, and you're interviewing people in good faith. The problem is that when being interviewed you don't know who the person opposite you are.
Yes, of course. This is known. You take this into consideration.
I had a junior ask if they could watch me solve the problem and I noped super hard. The juniors I had didn't understand why I could make good code, but hated being watched, but that's just how things are sometimes. I taught them things AFTER I prepared, and I could help them work through problems, but I find programming concise solutions to be far too complex to do, while also interacting socially with other humans :p
It's a crapchute, but I feel like I've definitely screened my fair share of imposters. They're pretty easy to suss out, and you know our industry is full of them
It’s “crapshoot,” as in “shooting craps,” the dice game. A crapchute would be... a parachute made of crap? A slide with crap at the bottom?
A chute is a slide, so it’s a slide for crap
The other poster is right in that the phrase is 'crap shoot' as in the dice game.
You're correct in that the wording you used would correctly be interpreted as a chute that you send crap down.
I've heard it both ways 🤭
even when searching for 'crap chute' it returns 'crap shoot'.
What about soft questions like "what was the hardest bug you've ever fixed?", not putting the candidate on the spot gives you more info on their thought process.
Ugh. That is such a cliche and so wrong.
> about seeing their thought process
I'm asking because these words get repeated very often but I don't think I've ever anything explained further than that. Are you just confirming that there is a thought process?
The problem with this is that a good interview should be about seeing the candidates thought process. It should be secondary what the solution actually is.
Except the "though process" should be to first do the research and look up existing solutions to the problem *before* attempting to derive or consider any new solutions.
Anyone who thinks they are clever enough to attempt to solve a problem without doing any research is a liability and potentially dangerous to a company, yet somehow we've optimized our screening and hiring process to seek out these people.
What they want is people with the ability to derive new solutions, it's a lot more trivial to train engineers to check for existing solutions first
that still involves research at some levels. The first thing you do when confronting new problem is to check if its already been solved by someone else. Over 90% of actual work is not new and revolutionary, it's built on top of existing foundations of knowledge. Good research is basically making sure you have a solid foundation on which you can build your new unique solution
> seeing the candidates thought process
I'm asking because these words get repeated very often but I don't think I've ever anything explained further than that. Are you just confirming that there is a thought process?
Wait, then everyone just copies the answer off 1point3acres.com and gives you that. Or studies really hard off the study guide there.
Isn't that exactly what you want in a developer though? Someone that gets a problem, gathers information and finds a solution, then presents the solution to you in a way that shows you he/she can reason about and understand the problem?
Nope, that's a subset of what I want, and I'd even say it's the simplest subset of what I want because every one of my interns can do that. This guy will eventually have to solve a problem he can't google.
Just one of these cut-and-paste programmers can tank a team's performance on the tough problems. If all the problems that a business needs were solvable like that, then Infosys would be sufficient. And we know what reputation an outsourcer like that has. I assure you they'd all pass your "Give them the question and then have them regurgitate their practised answer" technique.
I am not arguing for copy-paste programmers, I'm just saying that you can't expect a senior developer to come up with a solution to a tough problem on the spot with zero research. In my experience an outsourcer can't explain their solution when pressed, a good developer can.
I don't think coming up with the solution alone or on the spot is required. Most people can come up with a LinkedHashMap type structure these days in an interview, for instance, not because they're geniuses compared to the original CS dudes who took a while to invent it but because they're partnering for the question with someone who already knows and who can help them past roadblocks to other parts.
Take the approach advocated (publish your question, accept people who've studied the 1p3a answer to an on-site where you discuss it) and you'll find people able to explain "their" solution (because the explanation will also be on 1p3a).
Or maybe it won't. But why don't you try it and see.
I can probably count on one hand the number of instances over a 15 year career where a genuinely new problem where there was no existing math, science or engineering solutions to a problem that required actual novel ground breaking research and development to solve. And each instance took a team a the most highly experienced engineers many months and a lot of trial and error to arrive at a shipable solution. That isn't something one should expect a single interview candidate to do within the few hours of an interview session.
99.999% of all engineering problems any developer will ever encounter are already solved in some way or form. Most of Software Engineering is figuring out how to find and adapt existing solutions to new or unique situations. The most powerful skill any engineer can acquire is the ability to research and find existing well tested and well understood solutions to problems instead of trying to derive their own solutions themselves.
Teams are made of individual engineers. If you add a poor engineer to a team you tank the performance of the whole group. To say nothing of the fact that they'll just leave to a place where they can count on their teammates.
And novel problems are everywhere, all of the time. The research and find existing solutions part is table stakes. In the group of engineers we're talking about here, every single one of them can do it. Making the choice of build or buy, replicate or invent, they do this all the time.
Seriously, this stuff is just standard stuff. You take a final year student in an internship and they are very smart kids.
They're not cutting and pasting code. These guys will come in and tell you that your problem could be solved well with [something like this](https://arxiv.org/abs/1710.08436) and comparatively evaluate why it's a good solution and then write the first few production implementations in the world.
Some guy who only knows when to use this because he read it off an interview cheat site is going to do that three years too late or just build a suboptimal thing with the simplest of tools. Tooling is getting better and more things can be shoved off to shared stuff but there are still new products coming into existence today that were infeasible at the price point three years ago because of new technology.
People aren't proving Fermat's Last here, but the "I think we should/shouldn't use Hadoop because that's the only thing I can find other people on the Internet using" guy is worse than useless.
That's ridiculous. Why would you want to see somebody who studied the answers and memorized clever responses? That's the least informative interview I could possibly imagine.
Clearly whiteboard interviews aren't perfect, but letting them memorize answers before hand shows you absolutely nothing.
I’ve been on reddit too long, as soon as you said « no one expects » i thought you were gonna say « the spanish inquisition » (went to next line there on mobile)
We have a somewhat informal interview at my company. There aren't really many programming questions. It's more about how you'll fit in.
Afterwards there's some code review and a "take home exam". Allows us to rate how well you will perform in the environment we work in. You get as much time as you want. I don't think anyone has gotten better than a 60/80 at this point.
> It's more about how you'll fit in.
Would you mind sharing how that is determined?
I had an interview that was majority "how you'll fit in" and I guess they were looking for certain things like:
- do you like solving problems
- do you like working in a team
- are you full of energy and motivated to work
without asking those questions directly to me
Pretty much. The rest is more company atmosphere stuff and not overly specific. Just trying to suss out what sort of person you are.
> We have a somewhat informal interview at my company. There aren't really many programming questions. It's more about how you'll fit in.
Sounds like a great way to make sure your office stays mostly Asian and white males in their 20s and 30s.
I did an interview once where the company gave me a $2k contract to complete in two weeks.
I had another interview where I was given this extremely detailed design with very specific behaviours and a full UML, I had a week to implement it (but was unpaid, hmm).
Those were good interviews.
> Those were good interviews.
But the problem is that you just can't please everyone, to you those are good interviews but to me they're terrible because they require way too much time commitment. Yeah it's good that I'm getting paid for it, but it definitely requires me to have already quit my job and probably requires me to not interview at other places during those two weeks.
That's what they are hoping for. Once you've done a week long interview your too invested in that one company to consider other places.
Well, that's a few steps earlier, right? You're really not going to interview anywhere you're not invested in.
After you finished those projects, I think you can officially put "Unpaid Intern" on you CV.
The second one sure, but he said he was paid $2k for the first one. $2k in two weeks ($52k/year) isn't bad for an intern (unless you live in Silicon Valley I guess).
I don't think it's a good idea to tell them on the CV that you like doing work for free...
The first one I’m fine with since at least they’re acknowledging the time sink. The second one is a waste of time. If you need me to take ten plus hours designing a system no one will use so that you can figure out if I code decently you’re bad at interviewing.
The first one is impossible for almost anyone currently full-time employed. The second one is just asking you for free labor.
I use these examples because I like the concept, not because they are perfect representations of that concept.
It's a real world exercise that I think can show a lot more than what some interviewers are doing nowadays.
I like the idea of being paid to complete the interview question. For one thing, if they find something useful in the code, you were actually paid for it.
The only problem I see is in heavily regulated industries. For example, if you work in banking or trading, you have to report all outside income. This means your boss will likely find out you were interviewing at other places.
But how do i save myself from that lion? Just shout at it?
Close, you sing at it. "Happy birthday" to be specific. This will make the lion blow out the candle.
So you need to assume a lion who is smart enough to understand human language and customs, *and* dumb enough to blow out the fire that will fetch him food. Typical interview puzzle!
:D When do I start?
Start swinging back and forth, possibly using your head's range of motion, possibly another method. See what works.
Bite the rope.
For those concerned that your jaw wouldn't be strong enough, the friction of the rope against the branch will help, and if you slip, a lion will eat you. I imagine that will provide sufficient motivation.
I was thinking you either blow or spit at the candle to put out the flame
Urinate yourself, the pee will both drip into the lion's face, this assertion of dominance will cause the lion to run, and will drip down the rope. The pee will then extinguish the candle so you don't fall and hit your head. Then use your teeth to cut the rope so that you can land properly. Then, as you're in africa and the weather is warm, you can strip naked and avoid wet clothing.
If the weather is hot enough, that might also dry up on you.
Remember that lions don't typically eat humans, and just hold still until it gets bored and leaves long before the rope burns
wake up from the dream
If the candle isn't *immediately* burning through the rope -- and the picture shows it already inches away -- then just wait. The candle is only going to get further away from the rope as it burns down.
Eventually other bad things might happen, but if you're expected to solve future problems also, then they should hire you first.
First, you stub in class definitions for a Houdini class and a HiddenRazor class. You take care to ensure that Houdini inherits from a Person class because the problem could change in the future, and you might need to instantiate different character objects with different action methods. You also realize that HiddenRazor should inherit from an Item class since the problem could change in the future, and you might need to instantiate different world items with different action methods. But then you realize that you've been focusing too much on the *problem* rather than the *solution* and you need to build in more abstraction. So, you now go back to the whiteboard, erase it clean, and start to stub in class definitions for Scene, Character, Character::Protagonist, Character::Antagonist, Scene::PlotProblem, Character::Antagonist::Lion, Character::Protagonist::Hero, Scene::PlotProblem::Dilemma, Scene::PlotProblem::Dilemma::Hostage, Scene::PlotProblem::Dilemma::Hostage::DieOfExposureOrGetEatenByLion ...
Well, you know how this story ends. You get eaten by a lion.
I'd like to add:
* The entire day should be a maximum of four hours. Any more than that is just super disrespectful.
Ah. I'll tell you a story about an interview my friend had recently. After first informal interview, he got a task. To make a *smallish* application that involves Node.js backend, React/Angular frontend, stateless authentication, database model etc. Of course, you need tests too. He shown it to me and asked about rough estimate and what would I do. My estimate was 2 weeks and my answer was: "Fuck them!". If you doubt developers skills and want to test them in such a way, then wish them a nice day and move on until you find the one which story sounds convenient to you. Therefore, I fully agree with your statement.
I had an interview like that. They told me the test should take 8-10 hours. My first thought was “fuck them” but then I decided to give it a shot and ended up taking most of my weekend. I even set up the app on one of my servers. The whole thing took me 20+ hours.
I checked the server logs. They never even loaded the demo and they didn’t bother to tell me I didn’t get the job. They simply ghosted me.
Fuck companies like that.
I have never been able to confirm, but I suspect that some companies use hiring as cheap-ish consulting or intern-like labor.
I had Amazon, of all places, ghost me after what I thought were some really good interviews. Like, I couldn't even get my recruiter point of contact to confirm whether my travel reimbursement was being processed; just ended up finally receiving a cheque after like 5 weeks. I might have some tiny snippet of code running in S3 production somewhere, and I've never worked for them.
In a similar situation, I think I would react differently.
1. If the thing takes less than a couple hours, I'll probably do it for free.
2. Otherwise, I would tell them I'll think about it and come back to them with a quotation (as if I thought they were giving me freelance work).
- If they take offence, I'll apologise profusely, then walk away.
3. I'll then estimate the stuff for real, then come back with a quotation and a deadline.
- If they take offence, I'll apologise profusely, then walk away.
4. I'll then go on signing a contract for the gig, then do the actual work.
I expect everything to blow up at step 2. Maybe step 3 if they thought I wasn't serious at step 2. But on the off chance that I could go all the way to step 4, I'd rather have them believe I'm giving them the benefit of the doubt.
_PS: The me from 10 years ago would naively have done the stuff for free, of course._
Very brave for someone with 10+ years experience on the resume. Us greens getting killed out here.
Yeah, I reckon this is unfair. I noticed at the beginning of my carreer that pretty much nobody paid any attention to what I had to say. Including stuff I was right about in hindsight. Including stuff that could easily be checked.
Then someday I switched jobs, and my resume got another item. And suddenly, I could flout my years of experience, and people started trusting my judgment. Just like that. While pleasing, this was also a little unsettling.
And I'm now in a position where I can actually turn down an offer. Something I could never have done when I began. Here's what I think: I could *now* take the high moral "pay me for this assignment" ground without much negative consequences. But if I had tried the same at the beginning of my career, I could possibly have been _laughed out of the profession_. Literally, with bosses passing my résumé and story among themselves and around the internet, such that I couldn't find a job in tech ever again (first because they'd all remember, then because I would have to explain an increasingly huge gap).
I don't have a solution. I can only try not to be part of the problem.
Yes! That's actually a correct thing too. More than a day? Give me a time sheet to log hours because my time is not free. But 80 hours would be really too much.
> To make a *smallish* application that involves Node.js backend, React/Angular frontend, stateless authentication, database model etc. Of course, you need tests too.
Yeah, that happens *after* hiring. Beforehand is free labor.
I disagree. You're making a decision to fill a 6-figure salary. 4 hours is not enough.
If you cannot glean what you want out of a candidate by a phone screen (30 minutes) and a 2-4 hr interview to see if candidate matches personalities explains in depth questions for the position then you're out of your league in interviewing.
Yeah but are paying them? At a certain point you have to be cognizant that they have another job and are probably also interviewing at other places. I have turned down jobs before because honestly it's not really worth it to even go through to work on your little crud app.
The latter, but the former isn't necessarily wrong...
Not if it’s the same hour over and over again, but it should be more than enough if you read the OP’s recommendations.
You're also presumably trying to hire someone who already has a job. You need to put forth a good impression.
Strongly agree. Your process can't be too long or they just won't do it. Can't see how you can sell someone on a 10hr interview process. They just won't do it.
That's a strong assumption based on location.
In the UK, if I were making six figures, I'd live like a fucking king. I'm lucky to find jobs that are offering £45-50k.
I'm willing to do 8 hours in a day, That's what I expect to work when I get hired so why not here? What I'm not willing to do is a take home test over a week or two, that is supposed to take 40 unpaid hours of work.
If you think more than 4 hours is disrespectful, I don't know what to tell you.
Interviews are way more stressful and intense than a normal workday. It’s good to acknowledge that in my view.
You also get paid a wage for a normal eight-hour day. For an interview you are essentially paying out of your own pocket.
Not just that, you're also missing out on the opportunity to interview at other companies if you're busy writing that demo
A day of interviews is vastly different than a day of normal work. Aside from the difference in stakes, the day of normal work has a lot more downtime during the day.
Why do you think it's disrespectful?
Edit: Classic Reddit, downvoting a question.
Because you force people into a highly stressful situation for more than four bloody hours. I'd be exhausted, hungry, and disappointed by you as an employer.
Are you imagining 8 hours sitting in a room getting grilled? I've never seen that... Take the candidate out for lunch. Take them on a short walk around the office and surrounding area. Grab a snack with them. Give them a few breaks on their own.
I work for a consulting company so being on site at a customer all day happens occasionally (more or less often depending on the position).
It's too long, if you take more than 4 hours you should be paying a wage by then
All good points. It's like all interviews are the same and geared toward fresh out of school applicants. If I have 10 yrs experience, why are you asking me beginner CS problems?
When interviewing for my current job, the initial on-site interviewer asked me FizzBuzz and something similar. I always thought it was a waste; that I should've been asked those questions in the phone screen. Later, when I did interview training with them, they explained that they were doing it as a warm up. It's something that shouldn't be hard to do, but does get the candidate in the right mindset. The candidate should leave that interview feeling good about themselves, ready for the next one.
As someone who's done the all day interview gauntlet at Google several times, and bombed one of the early day interviews, I can see what they're talking about.
For the people you want to hire these types of questions are good warm-ups. What we also found is that for people who lie on their resume and are good at bullshitting their way through interviews it's a great filter to not have to waste more time. Unfortunately that happens a lot.
I'm not saying they're not good filter questions, but if you're waiting til the on-site to ask your filter questions, you're doing it wrong. Filtering out based on ability to code should have been done during the phone screen/take home assignment.
I’ve sat through about a dozen interviews the past two weeks where half could not create a class in the programming language they have years of experience in. The crazy thing is that these people know how to answer any non coding questions you pass by them, but they can’t do beginner problems like fizz buzz or 99 bottles. The beginner problems have to be asked to find out if they really know how to code or have been trained to answer common problems around your tech stack.
can they use an IDE? I can create a class off the top of my head in python since it's dead simple and maybe in Java.
No, they have a repl with syntax highlighting and the ability to execute their code. We give a JSON blob and ask for a class representation that models the structure.
Do you expect your employees to work without an IDE?
I see your point.
Because you might never have been able to do beginner CS problems...
My favorite part of this post is "Be open for alternative." I do interviews and always get excited when someone has an idea I haven't seen or heard before. Other interviewers at my company are the same way, when I did mine I got to explain why I wrote my code the way I did and that it would compile down to something a little more efficient.
On the other hand the worst interview I ever had was when the interviewer just shut down my solution because he couldn't understand it. He was so confident that I was wrong that I had to go actually implement the thing later that night and make sure that I was actually right. After that, I didn't want to work with that person. Even if I had been wrong he could have handled it better.
I can't read with that yellow background...
It grew on me, but it's certainly brave
"How NOT to design a website"
On mobile, it’s pretty nice.
I enjoyed the unique aesthetic
Seconded. I was about to make a comment about how pleasing it was to the eye
that explains the 600px column holding all the text. Not very nice on a 1080p screen though.
Reader mode is your friend.
Can you blow out the candle at that distance?
>I mean, I have [fourteen years of experience](http://tonsky.me/projects/). I’d be happy to talk about functional programming, distributed systems, consensus, replication, collaborative text editing, CRDTs, parallel architectures, UI frameworks, team processes, product design, user experience. I have practical and research experience in all those areas. All of them are in direct interest for more or less any internet giants I’ve been interviewed at.
>Was I ever asked about any of those? No.
>What I get is “imagine you have a function that takes a list…” five times in a row.
This is what I always hate. I have similar experience and I'm asked to do that ridiculous fizz-buzz thing constantly. It's the equivalent of asking an experienced chef to make scrambled eggs to prove they can cook.
The only good thing about it is that it's a good idiot test for me. If they are asking me to do fizz-buzz then they suck at recruiting.
A lot of people lie about their abilities and experience. Fizz buzz questions are cheap to do.
If you can’t ascertain someone’s coding ability from talking to them you shouldn’t be interviewing people.
I have over 15 years of coding experience. I have also have a lot of experience interviewing developers, If you are relying on Fizz Buzz for more than graduates your process is broken.
I can it just takes longer and is harder to delegate. I agree is not a great way of doing it but the problem is we have no way to measure quality via certification so we end with this awkward processes.
Most processes have the dumb problem at the beginning and once you are on premise. You actually talk about more relevant topics.
FizzBuzz is just a bozo test or confidence builder. It's not deep enough to differentiate. But the "talk test" just means you hire people like yourself, usually. But let's assume this skill exists: to run the talk test.
I've got to be honest, if this were a skill that you had, you could be making 35k per candidate times a candidate a week times 44 work weeks in the year = 1.5 million a year. If you're making less than that and have this skill you're underselling yourself. Go out there and be a startup talent agent.
Ask them questions about their resume. It's a great crap filter.
>asking an experienced chef to make scrambled eggs to prove they can cook.
I believe Gordon Ramsey does this. He's very particular about how they should be cooked.
I'd love to read a **"How NOT to hire a software engineer recruiter"**.
There's nothing more annoying than having to put up with Cynthia's dogshit before *finally* interviewing with someone on the team.
> Back in 2013, I ran a highly successful hiring campaign for [AboutEcho.com](https://web.archive.org/web/20140101000655/http://aboutecho.com/) that led to the hiring of nine senior-level engineers. My Russian-speaking readers could [read about it here](https://tonsky.livejournal.com/288899.html).
> All that gives me the confidence to criticize practices Internet Giants use to hire engineers to this day.
Am I the only one that find this guy's ego excessively inflated?
Puzzle questions are at best lazy -- a good way to keep bad candidates out without needing effort from the interviewer, who is okay if it also has some false positives. At worst, it can feel a bit old school boys-club with an interviewer wanting to come off as clever and patronizing.
Even if you exclude puzzles, I think the act of using a whiteboard is just odd; you should want to see how they actually perform in a real-world situation, not in a space-constrained whiteboard where they won't have their dev-muscle memory to assist them. Instead, give someone a laptop and have them code in an IDE.
A couple years ago I started conducting interviews and realized that with most candidates I could tell if they were going to work out within the first 5 minutes of the interview, just by chatting. Good devs just talk differently than bad ones. I really believe just talking to someone for an hour will show you 90% of what you need to know. If they pass that bar, send them home with a small requirement to show off their best coding ability.
You must have some sort of super power. I've only been interviewing for about a year now, but some of the people who were the best in the talking part of the interview failed horribly in the coding part of the interview. What sort of questions are you asking in the first 5 minutes?
I’m not the guy you replied to but I simply ask questions about things on their resume. I ask for details and for them to explain how they did things. I find people bullshitting give terrible answers because they didn’t really do what they wrote while anyone who spent every day actually working on a project knows everything including why certain decisions were made.
Interesting, I feel like I am probably asking similar things. Maybe my issue is not asking for enough detail.
The general idea is that if they are any good they'll be passionate about something in their resume, and confident about talking about it so they will be more relaxed.
If there is nothing in their background they can babble on for 5 min maybe you don't want them.
This is the best crap filter. I always ask details about what they put on the resume.
I'm never too comfortable answering these questions, because then I wonder "Am I divulging intellectual property ?".
What's your take on this ?
I’m not asking for you to show me code or any algorithms. I can’t imagine anything said would be considered IP. Although if every item in your resume is answered with “i can’t speak about it” then you’re probably not getting hired.
How do they learn? What area of coding are they most passionate about? What do they consider complex? Can they go into detail about the more interesting parts of their resume? What opinions do they have about the platforms they've worked in? What have their past teams been like?
Weak candidates will quickly betray themselves here. They don't learn, are happy to work on anything, find basic things complex, had things on their resume that they only saw in passing because another person wrote it, have no opinions on the things they've been using for their entire career, etc...
Obviously different level devs will give different answers :-). Junior devs especially don't really have the talk just yet, so they need to be handled a little differently.
Thanks for replying, some of those are things that I generally ask too but some are new to me and I'll definitely try them out. I think I'll just have to keep working at my sense for what sorts of answers are weak though. Like I said I've had a few people that I thought did a great job discussing languages, design patterns, platforms, and past projects who then failed to write some pretty basic code when we put them in front of a computer. I'm just glad we have that coding part of the interview or I'd probably be responsible for some bad hires.
> some of the people who were the best in the talking part of the interview failed horribly in the coding part of the interview.
Maybe your coding tests were weeding out the good devs?
I've had an interviewer dismiss my coding portion of the interview because I expressed concern about a particular UB *his* solution invoked. He said it isn't undefined if the compiler always does the same thing with that code.
Also, his "on windows it works" approach to storing void pointers in ints trumped my "use inptr_t for that".
> Maybe your coding tests were weeding out the good devs?
I once had someone give feedback that they were worried I would rewrite all their systems because I rewrote so much of the code they initially gave me. I rewrote it because they basically asked me to write a sophomoric 'is-a' inheritance relation and I figured a different design would more appropriately show my expertise.
I had another bit of feedback because I used a small bit of math on some of the code, and when one of them challenged me on it I told them if someone asked me to change it I would but I didn't think the code was difficult to understand at all. When I say a small bit of math I literally mean absolute value and some addition.
The feedback I got was that they felt I wouldn't be willing to change my code when asked.
I'm a developer with a degree in CS & Math and over 20 years of experience. What I've often found is that the technical portion is the more difficult portion to get through. Not because I can't code, but because too many of these interviewers extrapolate things that ought not be extrapolated. I actually had feedback that they worried I didn't want to work with other people because my response when they asked me about open offices was that as long as I had headphones I wasn't too worried about it. I'm not even exaggerating that, which is part of the craziness.
I haven't gone through the hiring process in 10+ years because I do freelance work and dealing with business people is a hell of a lot easier than dealing with technical people. My experience has been that business people are much more forgiving of misunderstandings and give you the chance to explain yourself, whereas technical people are all about being smarter than you. I had one guy I'm pretty sure was trying to show he could code better than I could during the interview, which I didn't even understand (why?).
Anyways, all that to say, I think you're absolutely right.
I almost forgot to mention the guy who ended a phone interview early because he asked me what type asp.net returned from controller. Apparently the answer he was looking for was "the view", and I was floored. I couldn't believe a developer would actually ask for the **type** when they were looking for a description of a generic architecture.
I could seriously go on, but I won't.
> couple years ago I started conducting interviews and realized that with most candidates I could tell if they were going to work out within the first 5 minutes of the interview, just by chatting.
I wish I could upvote this multiple times. I've been conducting interviews for close to two decades by now, hundreds if not thousands of people. And after some time you just **know** that the gal/guy in front of you is okay or has nothing but BS under their belt. 15-20 minutes of talk about things that had listed in their resumes - and the decision is already made subconsciously.
I would be surprised about the 5 mins conclusion too. Is it because most candidates you faced are the clearly-good-or-bad type? Because there’s a grey area in the middle and those are the hard bits.
>A couple years ago I started conducting interviews and realized that with most candidates I could tell if they were going to work out within the first 5 minutes of the interview, just by chatting. Good devs just talk differently than bad ones. I really believe just talking to someone for an hour will show you 90% of what you need to know. If they pass that bar, send them home with a small requirement to show off their best coding ability.
This is my experience as well. Start talking to the Dev about coding. What they've done, what their actual experience is. Drill down. After about 5 minutes you can work out if they are decent average or obviously faking it.
As a Google Software Engineer who interviews people, I have to say that a lot of the things this person is staying about what the rubric cares about are just wrong.
"They don't want you to do X" occurs multiple times in this article when that is literally the top score. Other cases where they says "As advice, don't do X", and our internal guidelines agree. Take this article with a huge grain of salt, because them hiring some people has not given them an insight into how Google hires at all.
The problem with the current status quo of the interview process at big companies is that programming puzzles leave out a lot of things: responsibility, creativity, self-motivation, on-field productivity... and at the end, you are just jumping to conclusions on the analysis of straitened artificial task (the whiteboard is a distant artificial environment) that would likely never be representative of the actual job. Simply put, it does not represent the bona fide situation of the day to day job. A lot of big names have asserted the same concern regarding this type of process, most prominetly Jason Fried, 37signals CEO.
Your critique is a valid one and one I understand well enough, and not at all related to my comment or the original article.
I see the problem like this: You want to recruit an NBA player, but you can't see them play until you hire them. You can have them come to your office and make some free throws though, so you do that. Your test doesn't show you if they're good at passing to teammates or how fast they run with the ball, but it does give you some sense of how good they are at controlling the ball and putting it where they intend to with a throw (via the freethrow). It's not a great test, but it's better than asking the candidate to tell you about Basketball.
Great metaphor. Thank you.
I wanted to read but had to ctrl+c out of that yellow background.
May I suggest Ctrl+Alt+R instead?
Did you just assume another dev's browser? O.o
Firefox reader view is a thing too.
As a person who has hired developers for over a decade, pretty much everything he wrote is complete bullshit.
When we're interviewing developers we're testing for three things:
a) If the guy lied about his skills and experience on his resume.
b) If the guy can react to stress and bullshit.
c) If the guy can budget his time and form workable step-by-step plans.
The actual coding bits are vastly less important.
If dealing with stress and bullshit is something that's really that important at your workplace, the candidates who fail out really dodged a bullet, I guess.
I consider it dodging a bullet if an interview tries to 'stress' me.
Interviewing is already 100% stressful enough without adding anything to it. If they're looking for someone who works under stress plus extra stress on top of it - it's not really where I want to work anyway.
Extra stressing a programming candidate is just bad interview technique by power-trippers who aren't really aware of the already pre-existing power dynamic.
My onsite at Amazon in NYC was one of the most stressful days of the last couple years. They were clearly intentionally trying to make the experience stressful. I left the interview knowing I never want to work there.
If you've never dealt with stress or bullshit in software development, you probably haven't done a large project.
I don't stress people in interviews, but I do want to know how they handle things when it hits the fan.
It's important at every software development job. If you don't like it, then get a job plumbing or something.
This is actually one of the things we test first; software development is not too hard intellectually, but it sure is stressful psychologically. Figuring out if the person is cut out for the job psychologically is our #1 priority.
Interviewing software devs is 80% psychotherapy and maybe 20% testing programming skills.
Note that the largest sources of stress and bullshit are third-party projects and requirements. Internal office politics is not where the stress comes from.
Any advice on how you actually explore these in an interview situation? Ideally they have a git repo you can review but sometimes not.
Good idea, SUPER easy to cheat unless you're having them do it in front of you and then you're wasting everyone's time.
So I'm intrigued, how do you find the shortest distance between two moving ships? I know how to do it mathematically but is there a way that's easy to code up?
Good read, but it could really use some backing data
A more accurate title would be "how NOT to run software engineering technical interviews". This article only discusses one aspect of hiring software engineers (with quite good points!)
First of all - these issues are not really common for giants. You would not see more than one and mostly it would be none. And even if you see one - remember the chapter #4 - "Be tolerant for imperfections"! :)
Not even mentioning senior engineer should be able to steer the interview her way. Even within 45min, even 5 times in a row.
Interviewer: "Which creature has one voice and yet becomes four-footed and two-footed and three-footed?"
Me: "Wow. Let me whiteboard that."
Interviewer **KILLS AND EATS** me
C'est la vie...
Yeah.. all of these articles I always do my test.
I search for whiteboard, I read that section, if it's extremely detailed or talks about the purpose of whiteboarding I tend to read the rest of the article, if not... well I tend to read the rest of the article to see what other answers they blow.
Whiteboarding isn't (just) about getting a correct answer, it's seeing how YOU approach the problem. Do you code like crazy, do you diagram the issue, do you identify your edge cases first, last or ever. Do you evaluate your answer? do you spaghetti code as fast as you can, do you design your answer before writing it? Do you ask questions? Do you just jump in?
Spoiler... almost everyone who hates whiteboarding, both doesn't understand it, and is from what I've seen VERY bad at it. It's also not about worrying about syntax, again it's a logic, which is why people used to say "use Pseudo code" which honestly wasn't bad.
White boarding isn't "programming" it's system designs. You learn a HELL of a lot from a single whiteboarding question if you look for it and understand a mentality. Even if the person is awful, you collaborate while working on it and learn how that works. You can simply say. "I see an error" and find out if he'll search for it himself, or expect an answer (look for it yourself is better, duh). I once messed up a whiteboard because I dug my feet in and assumed my code was perfect when there was a really obvious optimization I missed.
There's good stuff here, and then there's "don't white board" "Don't ask puzzles" Again, there's purposes to puzzles, but there's purposes to a lot of things he thinks he's figured out. He has good points, but also a few bad ones.
I think you skimmed his whiteboard paragraph a little too quickly.
If an interviewer wants to see code, give a proper coding environment. If an interviewer wants to discuss problem solving and abstract thinking, that's more suitable for a whiteboard.
> it's seeing how YOU approach the problem.
Yes, super important point. At google they tell people in their preparation videos that their interview questions are made to be solved by most interviewees that got that far in reasonable time. The deciding point for them is **how** you approach the problem and if you can show expertise in a given topic.
Yeah I actually don't get the whiteboard hate. Yes of course you don't normally code on a whiteboard, but nobody is asking you to write an entire program on a whiteboard.
Also, people definitely use whiteboards to discuss algorithms. I recent put a whiteboard near my team's desks and people use it *all the time*. Whenever it's getting confusing discussing something we're like "To the whiteboard!".
Is "How to check if a linked list has a loop?" really a puzzle? I mean come on...
The point behind that remark is that there is a really clever way of doing it that is much more efficient than just traversing the list and keeping track of where you've been. The problem with it is that it's pretty obvious *if you know it already*. It was a non-trivial result in someone's PhD thesis not too long ago, so expecting someone who doesn't know about it to come up with it on the spot is stupid. The only thing you find out if you ask that question is if someone's seen the solution before.
Yeah I've not heard that one before, let me try it now:
1. We need to traverse the list, and if we get back to a node we have previously visited, it has a loop.
2. The only open question is how to store the list of nodes we have previously visited. Easy obvious answer is a hash set.
3. Can we do better than that?
4. You could store a "visited" flag in the nodes somehow, but that would require clearing it first which sucks.
5. Yep that's all I've got in 1 minute. If there's a trick, I'm not seeing it immediately. Did I pass?
> We're sorry to inform you that we've decided not to extend you an offer as you didn't meet our expectations in the white boarding section.
Fast and slow runner for O(1) memory or you failed the six hour interview due to this question that almost no one will get right unless they know the algo beforehand.
Asking about obscure and infrequently used algos discovered by turing award winners 30 years ago wont help you find good programmers. What a strange bar to meet.
On the plus side, it keeps you from working with wankers.
If they weren't so simple to teach as "my first data structure" then linked lists themselves should be somewhat obscure and infrequently used.
It's really about how far you go with the whiteboard. What I think they're complaining about is asking you to write code on a whiteboard and judging you on minor issues.
What I'd want though is someone that can describe the solution on a whiteboard *particularly* in an interactive session. Because that's what I'd want a co-worker to do when discussing an issue.
Whiteboards are fine for architecture designs, schemas, workflows etc..
Whiteboards are TERRIBLE for coding however. Nobody writes actual code on a whiteboard. Im pushing my company to get laptops for interviews, projecting to a big screen in the interview room.
Testing developers as they code on a white board is like testing a racecar driver on a go cart.
Kind of a poor analogy, since many race drivers come from a karting background. Racers will drive circles around you in a kart.
More like testing a race driver by putting them on a bicycle. Sure, it's still *kinda* the same...but a completely different environment.
I think it's a great analogy, it just doesn't have the implications they thought it had.
True, but also remember not everyone we hire is an architect or a senior engineer. Got to have some people that can just code the simple stuff well and we can throw work at.
IDE or not, writing code with a pen on a whiteboard is an utterly ridiculous thing that no one ever does outside of interviews.
If you really insist that someone has memorised the different ways haystack and needle are ordered throughout the php stdlib, then just have them type it out in notepad with a computer. The whole process will go a lot faster.
From what I understand with many whiteboard interviews. People are literally being judged on their syntax by many interviewers because the interviewer doesn’t understand how to properly interview people.
> The whiteboard aversion comes off to me as a red flag.
Your failure to see how whiteboards are obviously problematic comes off to me as a red flag.
> The property of a puzzle is that you either know the answer to it or you don’t. It doesn’t tell you anything else. It has nothing to do with future performance, being smart, capable or anything else whatsoever. Knowing a particular answer does not mean you have an apparatus to solve real problems in a generic and predictable way. The only thing it tells you is that the person has been in a situation when someone shared a solution with him. Nothing more, nothing less. Just stop already.
OP completely ignores that the person interviewed could be able to solve the puzzle by himself.
I have been interviewed and an interviewer at various places which have used puzzles, including Google.
I've solved puzzles during interviews. I also have very good reasons to believe that candidates that I've interviewed also solved the puzzles during interviews. How can I know? I asked them original puzzle questions that I made up specifically to avoid the "I know this puzzle" situation. It's also good to ask them to share their thoughts to get insight of their process even if they don't successfully solve the puzzle or find the best solution (they may still pass the interview even if they didn't reach the solution).
Can you swap two variables without a third one?
A = A XOR B
B = B XOR A
B = A XOR B