I was just speaking with a co-worker about how I consider this interview culture to be a race to the bottom in how much unpaid work companies are getting from prospective employees. When I interviewed with Facebook they do back to back whiteboard interviews for about 6+ hours then sometimes they give "homework" problems, etc. Even skilled candidates can't refuse because a less skilled candidate will come along willing to make the sacrifice.
I don't have any solutions only complaints and bitterness, sorry.
Interesting and the first I’ve heard of this and the first confirmation I’ve heard that cost-wise it’s not egregious to do so.
It still seems strange to me to pay for throwaway work but I can also see how that’s really just my personal sentiment / bias and this is probably a pretty good and balanced approach.
Except some of us already have full-time jobs and don't want to spend the weekend working on quizzes, whether it's paid or not. And unless you're very generous with timing taking a day off of work can be a logistical issue, not just a pay issue.
This type of interview self-selects for people with fewer family/non-work obligations, who are willing and able to spend their free time still programming.
You're ignoring the context of the comment you're replying to.
That guy already has a good job. Another company is trying to poach him. Why would he, or any other qualified and gainfully employed candidate go through that unnecessary homework bullshit for a company that's trying to recruit them? The company has its priorities misplaced. They should be trying to convince the candidate to join them, not putting up barriers to their most qualified candidates.
I would totally do homework bullshit for a company/opportunity/compensation that I saw as “better” than what I have currently, but would not do so for anything else.
Insane. Let’s say it’s half that and you make $100k a year. You wouldn’t put in 2 hours for an extra 25k/yr?
I mean this isn’t a lottery, and hopefully you’ve reasoned there will be a high probability of getting hired; say 50%. So then the expected value of your time is $6.25k/hr.
Go, take the moral high ground, and don’t do the homework. That helps rational minded folk achieve an even higher hit rate.
I'm already at top dollar in my area and have been for years. Maybe that's why I despise it so, I have nothing to gain from the trouble. I haven't had to do a cold interview since 1999.
There are much better and less humiliating ways to get top dollar. Work your ass off and build reputation is the biggest one.
If you are a company and you have to call a recruiter, you're already behind. Putting people through that stuff just makes it worse.
We aren't paying for the work-product, we're paying for the time and inconvenience. It's more to show respect for the candidate's time than to actually "hire" them to do an interview.
I mean, even "discount" recruiting platforms like Hired and Vettery will cost 5-figures when we make a hire through them, and traditional recruiters often charge 20% or more of the new-hire's first year salary. A few hundred bucks to get some more information about a prospective coworker is cheap.
I'd recommend dropping the full day onsite. I mean what the hell do you talk about for a full day? The small talk must be unbearable after the first 30 minutes.
So you want a company to hire somebody after talking them for 30 minutes? Based off of what? You honestly can't imagine talking about technical software problems for more than 30 minutes? That's a pretty big red flag to me.
I'm assuming you are technical yourself, otherwise please disregard. What you are unintentionally implying is that you can't spot a fraud by talking to them about your chosen profession within 30 minutes. If you can't, you shouldn't be doing the interviewing. If you can, why waste 5.5 hours of the company's time per candidate?
When you start probing enough it quickly becomes practical/coding interview we all come to detest. Sure enough, that way you might not even need 30 minutes. But shop talk alone doesn't cut it.
Maybe your “shop talk” is different from mine, but I can suss out fakes from the first sentence usually. You’re correct in that they go straight for the broad architecture strokes, and they speak in vague terms. Trying to get a solid grounded answer is like trying to nail jelly to a tree. That’s when you know they just read some wikipedia articles and don’t know the practical applications of the words they’re using.
There's a number of people with CS or SW engineering degrees who can't actually code. Those can often quote you Gang of Four patterns, discuss broad slices of tech and draw architecture diagrams on the board. But still can't code.
I know, I work with several. I’m pretty good at spotting them because I studied them while working with them. Fun fact: if you poke in the right places, you’ll see that they don’t even understand GoF and architecture, they just regurgitate the what they memorized.
Its not causation, but I'd say it correlates to being a thoughtful person. Drilling down on the architecture blabble to see how deep their understand goes will absolutely tell you whether they could code a solution.
Is there a person who claims to be a coder that has configured and launched a multi-environment microservice with several attached artifacts like DBs and queues, that knows in depth what each is doing, that can't code? At that point you're just testing whether someone has memorized syntax details that they might usually get from an IDE or a 3 second google search in regular development. I have been writing production JS for years but still have to occasionally look up Array.slice vs Array.splice parameters, especially if I haven't done a lot of data munging in a while. That may indicate to a person giving an interview that somehow I'm "faking" it, when in reality its just a momentary stall-out in my brain's lookup tables.
> Is there a person who claims to be a coder that has configured and launched a multi-environment microservice with several attached artifacts like DBs and queues, that knows in depth what each is doing, that can't code?
Funny that you mention it. I know a person who can't shut up about microservices, Kubernetes and CI and can't code their way out of paper bag. They had no problem passing one of those interviews.
And sure rote API memorization isn't the point. But if a candidate can't code say bubblesort (or any kind of sort) in 30 minutes they are not very good at coding - and it doesn't matter if they can quote their architecture patterns by heart.
> But if a candidate can't code say bubblesort (or any kind of sort) in 30 minutes they are not very good at coding
Thats bullshit. Sorry. Most developers will NEVER implement a generic sorting algorithm except in a code interview. You say you don't want rote API memorization, but you do want rote sort method implementation memorization. Yes you can be a system or tools developer and maybe have a higher chance of doing it, but its 99% likely even then that you just use a library for it for the language you're using, or copypastaing it from someone who's studied the specific implementation for your lang.
When I'm looking for a job, I usually have 3 or 4 strong prospects and looking back on my spreadsheets that I keep when I am looking, it usually takes about 2 weeks from the time I reach out to my network of recruiters and I have an offer (the shortest was 4 days from looking to having an offer from what was then a top 10 Fortune 500 company).
Why would I go through that trouble? I have 20+ years of experience that I can explain how I architected and developed from the website, to the middle tier, to the database to multiple VPCs on AWS and dev ops. I'm not going to do homework.
When I was first starting out I might, but living in a major metro area that's not on the west coast, there are more openings for senior devs/architects than people to fill them.
If a company wants to try me out, I'm more than willing to do a contract to perm, but my hourly rate is going to be enough to cover self employment taxes, make up for not getting paid for time off and at least two or three weeks between employment.
> If a company wants to try me out, I'm more than willing to do a contract to perm, but my hourly rate is going to be enough to cover self employment taxes, make up for not getting paid for time off and at least two or three weeks between employment.
Take a reasonable salary for my market as $140,000, that is about $152000/1720 = $88.37/hour minimum.
Adjust the number based on market, skill set, and the amount of time you estimate between jobs. I'm also not taking into account health benefits that you would need to pay yourself because I'm covered under my wife, or 401K matching. I would add 4% to the hourly rate to cover 401K matching.
A good rule of thumb is 3x the rate you would get as a full time employee this might not be enough in the US given the high cost of health cover for a self employed person.
We have a take home test. It is an obviously fake problem, but we review it to the grade we would for our production code.
We don't find that candidates turn down taking the test - it's capped at 3 hours so that it can't take up lots of time. We do find that we have a low pass rate, and even among candidates with 10+ years experience, we still find candidates who write code that is just not good, and who haven't read the spec.
I'm not at all suggesting that you might be in this category, and if you can find jobs you want that don't require tests that's great.
However, there are people with plenty of experience, who can architect things brilliantly, and who can't write a ~300 line program in Python in a way that satisfies a spec or in a way that anyone would be able to maintain. That's important for many companies, and so I think tests can be one useful part of an interviewing process.
No, I don't think any of the code is of any value, it's the time and energy up-front investment is increasing significantly. I understand they are trying to protect their investment (2 years at Facebook would have been over $500K in cost to that company all things considered) but when is it too much and how would we stop it before it gets there?
I recently interviewed at a company who wanted to be as hot as Google and Spotify and had copied their interview process and their organization schema.
I said no thanks and moved on to other companies. Felt good. I just avoided working in a culture where there will be high pressure to always perform. :)
Yes, companies don't realize people can get incredibly wealthy working for places like Google. That's why people tolerate that as well as the prestige of having a place like that on the resume. They are so self centered, they think Acme Trucking holds the same allure with "market rates" and shitty benefits.
Reminds me of the old joke about a scam company who breaks up all of their problems into interview questions and never actually hires anyone. Obviously the composition, decomposition work and quality control would be more labor for worse results but it is easy to see how frustrated interviewees got the concept.
Do you think Facebook is taking pictures of whiteboards after interviews and putting the code into production? I agree day-long interviews are a problem, and homework problems are offensive (plenty of folks refuse them btw), but it's a stretch to say companies are using interviews as a way to get unpaid work.
The premise is not that they're getting unpaid work in the form of programming, just unpaid work in general. If they replace 8 hours of reviewing a candidate's open source contributions and/or side projects with 4 hours of random walks through an undergrad CS textbook, then they're using the candidate's unpaid work to cut down on their HR spending. "How many round piano tuners are there in Fizzbuzz" isn't programming, but it is HR.
Do most programmers have significant amounts of open source contributions? I only had a couple of years of life when I had the luxury of enough time for that sort of thing.
I'll just point out that companies are spending a lot of employee time doing these interviews, and if they're picky, that greatly increases the cost. Every day of interviews of someone they don't hire is money down the drain.
They can afford it, but still, it's far to say that the wasted effort isn't entirely one-sided. Hiring is an expensive and inefficient transaction.
Figuring out how to make this both more fair and more efficient is a really tough problem.
Having gotten contacted by Facebook, I eventually refused when I realized they were going to ask about algorithms for a technical role that is in no way relevant to that on the job. Skilled candidates can refuse just fine and wait for something better and more realistic that comes along.
So the standard FB onsite interview loop is 5 * 45 min, with a 45 min break at some point. Those aren't all whiteboard interviews. It might vary from role to role, but I don't think homework problems are common.
I did get the 45 minute lunch break and dined with another FB employee during that time, but I was in the room doing whiteboard problems the entire time otherwise minus them showing me the office space as we went up a few floors when I first arrived. This was in Seattle, if that matters. I think the room was labeled Occam's Razor and was super small, barely enough room for 3 people to stand.
So not only are you dealing with the standard fare interview nervousness, etc..., but you're also feeling claustrophobic the entire time. Brilliant process they've got up there. People look at me sideways when I tell them that I have no interest in working for places like Facebook or Amazon or Google and these sorts of anecdotes are some real high-quality validation after having had to justify that stance for years.
I would never work for one of those large companies. You really only need one household company on your resume during your career, then you can ignore them.
Those companies are the most visible places to get a high-paying job. They pay at the top of the market. Sure, a niche software company may pay its senior engineers higher, but even well-connected developers may never get any exposure to them.
If you want to get that first house downpayment for the Bay Area, I'd say it's almost essential at this point.
I think a lot of these reactions (and this website) are bitterness following a rejection. I'm not sure why people take it so personally when a company doesn't accept them. I've done whiteboard interviews and got a rejection before, and I thought it was fine. Maybe if you're putting all your eggs in the same basket and want THIS company to accept you, that might be annoying. But that's not a very good life strategy.
Might be worth clarifying whether this is “don’t use a whiteboard during interviews” or “don’t ask candidates to code obscure algorithms” on a whiteboard.
We use a whiteboard in our interviews for sketching UI, and sometimes drawing a database table. Generally candidates find this much easier than talking through their design, and we think that interview very closely represents what we do on a day to day basis.
Yeah, that's key. "Explain how your piece fit into the bigger picture— what other things does it talk to, how tightly are they coupled, how are errors propagated, etc."
There was a good article that popped up on here a couple months ago about this: "Organizational Skills Beat Algorithmic Wizardry". [1]
If you're asking candidates to balance a binary search tree when no one in the history of your company has ever had to do that, you're asking the wrong questions.
We do a mock technical meeting with multiple members of our tech team and the candidate presenting options, talking through pros and cons, etc. Much of the interview is about assessing communication rather than technical skills.
The interview is basically a standard tech meeting that we hold regularly in the team to discuss designs of new projects.
Agreed, whiteboard are way too useful to leave out. That's why we have them in every room in the office, not to scare candidates when we happen to conduct interviews in them.
In my opinion it is all about aligning your questions with the day to day task you expect from people. If the work is very algorithm heavy, by all means probe for that in the interview.
I base my interviews around one main question: assume the tech challenge you written beforehand is a prototype for a complete product/service. what are the steps necessary to get us there and beyond?
I do not care about the candidates tech preferences or the exact solution as long as the argument for it is coherent and not just based on heresay. Then I probe for a couple of things within their solution where I see potential weaknesses based on their argument, experience or code in relation what we look for. It is more about problem solving, decision making and communication than computer science.
Candidates are free to just talk trought it or use whiteboard/paper to draw it out. But if you choose the former you better not forgett what you said five minutes ago.
I feel like it’s ok to just say “you dont have to do programming on a analog device”; if they want to write on paper/whiteboard/with a tattoo gun I don't give a damn, but they wont be asked to write actual code. That’s what it means to me.
I recently had an onsite tech screen at a FANG company that requires whiteboard programming. The problem itself wasn't hard but I missed a requirement that was actually a hint. I shutdown and couldn't move on or work through it.
That said, I don't think whiteboard programming is always bad but it is a skill that I don't exercise and it showed.
My advice, talk through the problem with the interviewer and don't start writing code on the whiteboard until the interviewer has ok'd your proposed solution.
I usually need like good 5-10 minutes of quite time to think about the problem in peace. I just can't seem to do with interviewer staring at me and hounding me to 'think out loud', sorry I can't talk and think at the same time. I have no practise at 'thinking out loud' , i never do it in real life.
200 technical interviews?! What the hell? You shouldn't have to do 200 in your lifetime. This kinda reminds me of those MCSE certification bootcamps they used to have. They didn't teach you anything useful, they just taught you how to hack the test.
Comment: I think whiteboards get unnecessary flak when the real culprits are games and riddles. I would argue that using a whiteboard to convey ideas is a fundamental skill if one has to work in a creative team.
Question: How do you validate that the posted company or job position doesn't need whiteboard? Is it after the fact, as in a disgruntled candidate complaining? I couldn't find any information about this on the site.
> I would argue that using a whiteboard to convey ideas is a fundamental skill if one has to work in a creative team.
Yet a lot of people are never really taught to do it. Perhaps they pick up this fundamental skill just fine after a couple whiteboarding sessions in the company.
If a company is rejecting candidates for not having a skill that is really easy and quick to obtain, they'd better not be one of these companies that keep complaining about shortage of talent.
Even better, I would love a site that classifies job offers/companies by:
- Has an onboarding process for new hires
- Has quiet working conditions / open office
- Has clear requirements
- Salary range
- Allows remote working
- Type of interview and time to get a response
StackOverflow's job board has the "Joel Test" part where employers posting jobs can check off the points from https://www.joelonsoftware.com/2000/08/09/the-joel-test-12-s... that they fulfill. One of them is "quiet working conditions", which comes close. Before looking it up just now, I could have sworn the point was something like "every developer has a door they can close", but oh well.
Anyway, I hoped you could search only for jobs where this box was checked by the company, but apparently not...
EDIT: It does allow searching for minimal salary and remote jobs, among the wishes listed in a sibling comment.
Wow that would really turn the tables; a job board where companies must not only disclose their interviewing practices and durations but their office environment as well. It would be developer centric so developers can pick and choose the companies they want to work for based on often hidden parameters. Just the transparency requirements would automatically filter out most the chaff companies. I might have to build that out of spite. :)
> Before looking it up just now, I could have sworn the point was something like "every developer has a door they can close", but oh well.
EDIT: Ok, my mistake, my memory is failing me. "Doors that close" is used in a whole bunch of Joel blog posts, and "walls and doors" is used in the original Joel Test description.
But WaybackMachine seems to confirm that the official label from the "Joel Test" has always been "quiet working conditions" and does not appear to have been changed.
Sounds plausible, but the blog post from 2000 also has it as "Do programmers have quiet working conditions?"
So unless Joel went back and rewrote the past, it might be our memories. I am fairly sure that he did have another blog post that stated explicitly that every developer at FogCreek had a door.
Check out https://www.jobiki.com. We built it in collaboration with people like yourself to search for companies based on information like that. Whether you want companies with pod or cubed desks, or open office. (Among MANY other things)
Unfortunately we haven't yet expanded much out of the Midwest, so it MAY not be of use to you yet. But check it if your interested.
I went there, typed in "developer" in the search box, and got dropped on a map zoomed in on the Kansas/Oklahoma border and a message saying my search didn't match anything. Took me a while to notice the "zoom out on the map" part. Not sure why I landed in the middle of nowhere in the US, I'm located in Europe. In any case, super unintuitive.
Also, this might be an American thing I'm missing, but which (if any) option of "Pod Office Layout" or "Closed (Cubicle) Office Layout" corresponds to "proper walls and a proper door"?
I'd also suggest adding a filter for minimum salary.
Thanks for checking it out and your feedback! I can make some changes to hopefully clear up some confusion.
On Jobiki, we don't have job postings. Just companies and data about them. So the "minimum salary" and "developer" searches are more job related, while we are more company related. Either way, helpful feedback.
-----------------
As for the "proper walls and a proper door" aspect, are there developer/traditional employee jobs in Europe that can have a real office? In the US, unless you are a manager, executive, very experienced employee, you don't usually get an actual office. Maybe its more common in Europe?
At least in Scandinavia I'd say it's fairly common to have a real office. It seems the cubicle thing never really caught on here, but now there's a trend toward open plan offices, unfortunately. Software companies seem to be among the worst in this regard.
I have a real, quiet office with lots of daylight. That's actually one of the reasons I'm staying at this job. That, and the fact that I'm not subjected to low-status micromanagement techniques like Scrum. In short, I have working conditions befitting a qualified adult.
> are there developer/traditional employee jobs in Europe that can have a real office?
Yes. Maybe not every single developer; there might be two or three or four to an office, but it's still an office with walls and a door. There are companies with more open spaces and twenty developers to a room, but the (much) smaller ones are the usual case from what I've seen. ("Europe" is a big place, of course.)
Individual offices for developers are unusual in the US these days, but that's exactly why someone would want that information. There are also shared offices and team rooms.
"Pod" seems to mean completely different things to different people.
"Pet friendly" workplaces tend to be noisy and discriminate against people with allergies, so some users will want to filter them out.
Even if you don't want to track current openings, what kind of jobs a company has is important information.
Thanks for the response. That's very true. We've also been toying with different verbiage for "Pods", as I would even agree, could be many different things.
And good note on the "pet friendly" environment.
We in the processes of adding that information to outline what positions a company hires for. (Whether or not they are currently open or not) Well, more what departments that a company hires for. Going all the way down to job title seems a bit too granular, maybe I am wrong? But by department seems a happy medium?
That's not a bad idea. I think I'll make something like this, a site that let's you search for dev jobs with filters that devs actually care about. Any other suggestions for filters?
I still whiteboard my programming question when giving interviews, can someone summarize the case against whiteboards?
I'm just looking for the candidate's thought process and some pseudocode. I could do the same thing in an empty text file but the substance of the interview wouldn't change.
My feeling right now is that being anti whiteboard is focusing on trivialities like complaining that the office style guide uses Allman vs K&R bracketing or something. But I'm open to having my mind changed if there's something more to it.
I like to use whiteboards for non-coding design questions, like talking through how you would architect an app, drawing DB schema diagrams, etc. It's a tool that we use for collaborating on things like this in the office, so demonstrating an ability to do it is meaningful.
Actually hand-writing code with a pen has always seemed weird to me. As a programmer, I compose code with a keyboard. So I give candidates a laptop and use an interactive screensharing tool (I like https://codepad.remoteinterview.io) where they can run code in the language of their choice in a browser, and I can watch and talk through the process.
Being anti-whiteboard is a proxy for being against the "regurgitate this CS trivia on a board in front of me" style of interview, not against the use of a whiteboard.
Most problems in practice that require non-trivial application of algorithms, dynamic programming and the like have two characteristics that make them differ considerably from whiteboard style quizzes. For one, they're going to be much less contrived (pick a random leetcode question for an example of this, odds are it's contrived). Secondly, they're going to be resolved when developers talk to each other about them and there is recognition of the solution, which most of the time is an application of algorithms and data structures with library implementations.
The ability to whiteboard things like "given an array of integers and a target find the indices of the pair of integers in the array that sum to the target" and "find the first missing positive integer in an unsorted array in O(n) time and O(1) space" provides almost no useful information about a candidate's ability to solve an actual problem the company faces in most instances. There are exceptions, but interviewing everyone for the standard of that one exception is asinine.
Whiteboards are not the problem- rather the questions that candidates are asked are bad.
Asking someone to solve an obscure mathematical problem (the Two Egg problem seems to be in fashion) doesn't do much except test whether the candidate has memorized the answer.
Whiteboard problems are used to show that you can work through a problem, while communicating well about your thought process. They're also good general intelligence tests, if administered correctly.
Divining rods are trusted by many, and have been in use for centuries. If they weren't a good way of locating water, why would so many people use them?
I think an obvious reason for this type of interview problems is because developers at work usually talk loudly while solving problems and write code without the help of any external resource while the clock is ticking in the background. Oh, wait...
What both you and the parent post you're deriding are missing is white-boarding (when done correctly) isn't about the problem at all. It's just an easy way to get a candidate in the room and construct a technical conversation.
As an employer I don't care how great your skills are, if you can't walk me through your thought process for 45 minutes you're not going to be overly successful. If you can't incorporate feed back or engage when pressed to change your design you're probably not going to be successful.
Do your recruiting right and you shouldn't need the white board to simulate whether the candidate can code at all (I think white-boarding with the intent of looking for named algorithms is a waste of everyone's time), instead you want to see if they can synthesize information, engage with other people, and otherwise display the soft skills that tend to be much more useful metrics for employee success than coding aptitude.
Granted, my industry is known for not having deep coding problems to solve, this strategy might not be as useful in verticals that require more technology chops.
"When done correctly" is the key here. Alas, in my experience I was usually heavily penalized if I kept my mouth shut for as little as 15-20 seconds because interviewer "couldn't see my thought process". At the same time expecting from me to write syntactically and semantically correct, industrial strength bug-free code with optimum space and time performance for a problem I never ever encountered with the interviewer "helpfully" distracting me 4-5 times a minute.
>As an employer I don't care how great your skills are, if you can't walk me through your thought process for 45 minutes you're not going to be overly successful. If you can't incorporate feed back or engage when pressed to change your design you're probably not going to be successful.
The post you're responding to makes a great point that this isn't the normal working environment for 99% of actually-writing-code developers. I discuss and iterate designs with my coworkers/leads/managers/architects just fine, but a surprise algorithmic problem you have to simultaneously solve, draw on a whiteboard, and constantly present to an audience while being timed isn't something I have been great at. I bet many others aren't either. I got good at it after a few interviews last time I was looking for a job; but if I hit the interview trail again today, I'm confident that I would flounder in that setting for a while.
Imagine if, instead, the candidate worked out a project -- maybe at home, or maybe in an interview room for some time -- then you take time to review and understand their work and then go through this back-and-forth process of discussing their work. This would also benefit the candidate's understanding of how you collaborate to problem solve in your work environment.
The problem with this approach is that it requires the interviewer to actually invest time to understand the candidate's work.
Anyway, I hope you see why many see it as a problem that the process for a candidate to succeed at a job interview is to practice interviewing skills rather than demonstrating their engineer skills.
> As an employer I don't care how great your skills are, if you can't walk me through your thought process for 45 minutes you're not going to be overly successful.
As an investor, I don't care how great your skills are, if you can't come up with your new business idea on the spot and walk me through your thought process as you're doing it, you probably suck.. right?
Nah.
Unless you already have the answer, the first step is to come up with the solution. This could involve time spent alone just thinking, or brainstorming with coworkers, or researching the problem on the net, etcetra. What the right steps are depend on the problem, available resources, your background, even your preferred way of working.
The second step is to present and dissect the solution. I dare say this is the point at which the majority of engineers have no problem whatsoever talking about their thought process.
Do you work in an industry where engineers genuinely have to walk somebody through their thought process while they're trying to think up a solution?
If a problem comes up at a meeting and you don't have a solution on the spot, you take note and discuss it later or add it on the agenda for the next meeting. I think that's how people work.
I don't care about where, when, and how you came up with the idea. I care that you can present and discuss it once it's ready for that.
I think this is why many prefer the take-home test. They can focus on the solution. Then, at the interview, they can focus on the talk about the solution. It's also a great equalizer as e.g. people coming to work in a domain they have less experience with can take more time to research the solution space.
The complaints about homework taking up too much time may be valid, but I'd be most happy to trade 2 hours of interviews for about 75 minutes of homework and 45 minutes of interview.
> They're also good general intelligence tests, if administered correctly.
And communism probably redistributes wealth if it is administered correctly.
If companies want to hire based on general intelligence (not personality, team work, communication and so on) then they should administer IQ tests, which are based on a century of rigorous research. That would at least give you a fighting chance of measuring G.
Why do you think white boarding can measure general intelligence?
When not in an an interview I like playing with these kinds of problems, but if I look it up I'll probably find interview prep where it shows the answer as well.
"You are given two eggs, and access to a 100-storey building. Both eggs are identical. The aim is to find out the highest floor from which an egg will not break when dropped out of a window from that floor. If an egg is dropped and does not break, it is undamaged and can be dropped again. However, once an egg is broken, that’s it for that egg.
If an egg breaks when dropped from floor n, then it would also have broken from any floor above that. If an egg survives a fall, then it will survive any fall shorter than that.
The question is: What strategy should you adopt to minimize the number egg drops it takes to find the solution?. (And what is the worst case for the number of drops it will take?)"
Hmmm, that's an interesting question. It's the Price is Right closest without going over solver...
Practical answer, drop from the first floor and then the second. You're probably not going to make it to the third.
I don't want to put my actual answer in case others want to solve it. But I will say there's an obvious solution, but if you apply one of the hard problems of computer science you might eke out a bit of an edge.
EDIT: Actually I don't think that's right. I think the answer varies based on your expectations, and should be tuned after each run if you run the same test multiple times. I do have a good starting point in mind though.
After thinking about it on the ride home today, I was not quite on the right track before. Again don't want to post my solution because the entire point in asking was so that people could see the question and work it through themselves.
Uh, if you drop an egg out of the first floor window onto cement, it will break.
The answer should be a form of binary search, but since you only have two eggs, you'd have to do a sequential search from the bottom floor. You have one chance at a mistake, so I would almost say start with the 2nd floor, but I know it will break on the first floor.
I don't see how that in any way gauges programming what so ever.
>The answer should be a form of binary search, but since you only have two eggs, you'd have to do a sequential search from the bottom floor. You have one chance at a mistake, so I would almost say start with the 2nd floor, but I know it will break on the first floor.
yeah, sorta. essentially you partition the 100 floors into some number of groups (i forget what partition length is optimal) and drop the first egg at each segment until it breaks, then go linearly from the previous one
A quick naive not completely optimal but still relevant solution:
Since you have 2 eggs you can start on the 33rd floor. It breaks you can use the 2nd egg from 1st to 32nd floor.
If it doesn't break, use the first egg on the 66th floor. If it does break, the answer is between 33 and 65, if it doesn't the answer is between 66 and 100. That cuts the maximal testing time time from splitting at 1/2 (1st egg at flr 50), to 1/3rd.
To optimize further, since in the bad case we'd have to search up to 34/35 floors, you can mathmatically find a number where you split the drops at an interval (IIRC the "real" optimal answer is 14, then 13, then 12, etc), which means you're doing less explicit checking.
At 14 - i, you have 10 drops to find a range of 13 - i floors in which the optimal path is found. So instead of a worst case of 35, you have a worst case of around 17.
I find the best way to approach this sort of problem is to first find one optimization, and then use the same process to find if there are further optimizations.
It's not the worst type of puzzle except if you do not know of a solution it might take a while to figure it out.
It does relate to programmer's ability to amortize worst case running time.
Once you realize that 1 egg requires linear search you just have to realize that with 2 eggs you have to decrease the level increase by 1 on each success.
Of course those must be some crazy genetically modified eggs.
>It's not the worst type of puzzle except if you do not know of a solution it might take a while to figure it out.
I would guess the interviewer probably rates people who have memorized the solution far higher than people who have never encountered it and solved it with their brains.
Because eggs that don’t break when dropped even 3 ft (never mind multiple floors) are a thing? Perhaps I am just projecting my Earth based experience...
Maybe it's a shittest if you actually try to apply some theory rather than using your common sense and say that "Based on the last time I was in New York, it will definitely break dropped from the first floor"
That's the first thing I noticed about the list. I interviewed with Lyft last year and they did whiteboard style interviews. Since when did this change?
At plated we do two coding interviews. The first is concrete, we have a library that is poorly written and their job is to implement a new feature and refactor it. This is a great interview to understand core skills. The second interview is a modeling exercise where we build an app from scratch with escalating amount of complexity but only asking for what the database and api endpoints would look like.
This is great. I suspect the "coding exercises" in interviews are really dominance hierarchy games. It goes against politeness theory and is a threat to an individual's 'negative face' or need for autonomy.
Do people hate whiteboarding in general or the questions they're being asked to draw?
I can fully understand dislike for puzzles and being asked to implement irrelevant algorithms in pseudo code. The interview should reflect the job being interviewed for.
I've found whiteboarding to be mutually helpful in questions about system architecture. Plus, it's something that we actually do on-the-job.
Yes, but you don't write what you expect to be fully functional code on a whiteboard. A whiteboard is good for sharing ideas. Using it to write and assess code is pretty stupid if you step back and think about it.
I mean ask yourself this: do you ever use the whiteboard to write code to the extent you expect some poor kid trying to get his first job to do? Hell no, you screen share an IDE or paste code in an email.
People used to have to write code on paper (I did this a few times in college ages ago) and that comes from the cost of compiling stuff way back when. Computing time is friggin cheap, that's why no one does it. To expect some new guy to be adept at that ancient practice is silly.
I agree. This is a form of the psychological concept of encoding specificity principle[1] which states that recall is most effective when the conditions at the time of encoding match the conditions at the time of retrieval.
UI Design or a Frontend Software Engineer? I'd expect people working on the frontend to just as proficient in time complexity, space complexity, and performance analysis as a backend engineer. I don't particularly gravitate towards companies working in CRUD apps, but single page applications with complex UI flows and data collection can certainly need those abilities. For one, it's not particularly uncommon to have an actual tree in the UI. How would you represent that tree? How are you going to handle it as it grows to thousands of nodes?
I think few frontend developers would consider the work they do to be "UI design".
We don't whiteboard at my company, as we favor a take home technical exercise and debrief/walkthrough format for interviewing our engineers. That being said, I'm super turned off by the incessant whining from the community about various interviewing practices. Here's the tough truth I think: Some companies simply do not understand how to properly engage in employee selection. They get some quick guidance from a google search and have too much autonomy in the process to make their own decisions because the company hasn't really empowered their talent processes to be well thought out and planned. This happens frequently. The real shame in it all it that it focuses the conversation on these high level exercises - be it coding on a white board or rallying against take home exercises or demanding to be paid for interview work, and ultimately to the employer you're put in a spot where you can't help but feel a little reactionary as the transactionality of the relationship is constant: I need to know you can do the work, prove to me you can, I will then hire you and pay you to work.
What a cluster it's all becoming on the software engineering side.
I have an interview coming up and the process as described to me is take home exercise with an on site debrief. I am thrilled. I've done whiteboard interviews and some I've aced and some I've crashed an burned. I didn't crash and burn because I didn't know the material. I just froze on a tree traversal question one time. And then the nerves and empty conversation just made the situation snowball as I thought to myself, "OMG I know this why am I taking so long, what is this guy thinking right now." I relish the opportunity to provide useful information for the employer to update their prior.
>I'm super turned off by the incessant whining from the community about various interviewing practices.
Wow, what an incredibly tone deaf response.
>Some companies simply do not understand how to properly engage in employee selection.
Maybe changing this prospective is the point of the "incessant whining."
>I need to know you can do the work, prove to me you can, I will then hire you and pay you to work.
I'd have to know how you are testing, but I'd bet dollars to doughnuts your method has no way of predicting output in any meaningful way.
>What a cluster it's all becoming on the software engineering side.
Absolutely. I would say it's endangering the overall quality of the industry. The saying goes, if you are a bad manager or a bad company the first people to leave are the A and B players. The people that will never leave are the C and D players. I suspect people who do all this trivia don't even know what an A or B player looks like.
It's really not though. Here's the bottom line: You want money from a company. The company doesn't owe you jack. shit. If they fucking whiteboard, and you want money from them, then do the whiteboard. Later, when you are employed by them, try to suggest they improve their process. If you have better options, take them.
> Maybe changing this prospective is the point of the "incessant whining."
Sure. But is that the companies #1 priority, or do they have other things to do, like make money and stay in business that take precedent? Anyways, the way you do this is from within or providing feedback and having conversations with recruiters -- you know, human interaction. This job board is the ultimate culmination of millennial passive-aggressive behavior.
I will admit, maybe I am reading too much into the convictions or intentions of the job boards -- but we all are human, so I can only assume this was created by someone who was tired of having to do whiteboards, and rather than confront the problem head on and potentially drive industry-wide change (channeling "one person can change the world"), goes behind the scenes. The job board further fragments and confuses things for everyone. The better option, of course in my opinion, is make things better for everyone by fighting the battle where the companies are.
I am frustrated at times just as much as any other engineer by playing "monkey-see-monkey-do" in front of an audience in order to receive employment and I have indeed passed up job offers because I was turned off by the interview process (but again, that was my choice) but if you take a step back, look at the overall job market, and what other workers have to go through to get a job, we really do have it made, and this seems like a minor nuisance at best.
> rather than confront the problem head on and potentially drive industry-wide change (channeling "one person can change the world"), goes behind the scenes.
No, this is how change is driven. How do you think change happens? Getting a big committee together and getting buy in from all interested parties? That's not how it works. But maybe this is how it works, maybe this job board attracts a bunch of candidates who are tired of the status quo, and other candidates start telling the companies on other job boards that, sorry, but they're more interested in the companies that list on this particular job board, and those companies then see that the talent pool they're drawing from is smaller than it needs to be, and they decide they want to draw from the larger pool, so they change their practices, and then that snowballs, well maybe now you have industry-wide change.
I don't personally see this having much of an impact, but I think the people who started this are doing exactly what you're saying they should be doing, except that you're pillorying them for it because they aren't doing it through some impossible broad consensus approach.
> what other workers have to go through to get a job, we really do have it made, and this seems like a minor nuisance at best
It is true that we have it made, but I do not think it is true that we have it made in this sense. We have it made because our skills are very highly in demand and because of that, we are treated well and paid handsomely once we get a job. It is true that we should never ignore, down-play, or fail to appreciate this privilege, but that doesn't imply that we should not discuss or advocate for improvements where needed.
Where we don't have it made is in the predictability of employment once competence has been demonstrated. Other professions and trades usually have long-and-tedious up-front competence proving phases, but then they have a credential that will be respected by future employers when they have open positions. We are fairly unique in forcing people with long and distinguished careers to continually re-prove themselves. Our employers have open positions, but it takes a lot of pointless and duplicated busy-work for a competent person to slot into them.
I think what it comes down to is that our process is relatively mediocre, good, or even great for inexperienced unproven new entrants to the job market, but rather sub-par for experienced and proven folks. And that's why you see people looking for a better way.
I think there's two different complaints at play in this thread. Surely you're not suggesting that candidates be exempt from proving themselves. The number of developers who become incompetent over time is high. I think the question is whether they should prove themselves through algorithmic questions. I'll never higher anyone just because they have credentials. A Computer Science degree is a credential, yet so many with that credential cannot write the simplest of programs.
It's probably too late to come back to this thread, but no, I'm not talking about the narrower but more common complaint about algorithmic questions. I think the entire approach of constant proving is misguided. There are lots of other ways to do this with lots of prior art in other industries. I believe we have landed on a poor but self-perpetuating solution. What we do to hire is akin to what they do in the performing arts, but our work is entirely dissimilar.
Do mechanical engineers draw up a design for a valve or something at every job they apply for?
This might sound silly -- especially to the HN audience -- but it's akin to the baptist church problem: one group doesn't like their senior pastor, so they take about half the congregation, go down the street, and say "we will do it right this time!" and now you end up with two split churches. This is basically why there are thousands of baptist churches in the south.
Another example it's related to is the XKCD standards comic. Rather than improve existing standards, the committee breaks off with dissenters, forms a new committee, and now you get "Situation: There are now 16 competing standards"
edit: Better Solution? Talk to recruiters? Let them know you won't consider places that force you to play "dance monkey". The letting them know part is key. More broadly: maybe unionize?
Here's the other bottom line: A company wants to use your industry and creativity to make more money than it will give to you. You don't owe the company jack. shit.
I agree with your bottom line as well. Both are true! It's a negotiation, and it isn't zero-sum. Working is good for both the employee and the company. Neither is in a universally stronger negotiating position.
I'm not annoyed by bad interview processes and strong preference for false-negatives, I'm annoyed by that in conjunction with the claim that there is a shortage of competent workers. There is some lower-hanging fruit to take care of before that claim makes sense, and improving recruiting processes is among the lowest hanging (along with raising wages, obviously).
> Here's the other bottom line: A company wants to use your industry and creativity to make more money than it will give to you. You don't owe the company jack. shit.
Unfortunately, unless the sides are favored to the labor market (in our cases it is not, and even if it was, there is always outsourcing), this equation is not equal.
Both are true, but it is an extremely unbalanced equation. At the end of the day, the company has the money and you have the skills. Unfortunately only one of those helps you pay the bills -- unless you can figure out a way to pay your rent in exchange for your skills.
This is not true for the industry we're talking about (or at least not as true as you seem to think). It really is in companies' best interest to be attractive to skilled workers in this industry and there really is a chance they will find themselves struggling if they get the wrong reputation. It seems (to me) like this is a major undercurrent in IBM's struggles, for instance (and outsourcing has not been a silver bullet). Thinking the balance is more skewed than it actually is is one of the things that skews the balance.
It's really not though. Here's the bottom line: You want money from a company
And the company wants to make money from me. In my market, there are a lot more open positions for senior devs than senior devs that are actively looking for jobs. I
And if you have all the time in the world to play that out --great. If you have limited savings like the vast majority of Americans -- time is your enemy, and eventually rent will come due. The company can survive for months, years without your labor and if they have to, they will simply purchase it or outsource it if need be.
You need that money more than they need you. There really are few exceptions to this rule -- AI being one of them.
Again I wish it wasn't like this, but it's the reality for the overwhelmingly majority of software developers in this country.
1. That you are in an area of the country with a lot of opportunities
2. That you kept your eye on the market and made sure that your skill set in demand
3. That you kept your resume updated
4. That you kept your network of recruiters, former coworkers, and references fresh.
If you have limited savings like the vast majority of Americans -- time is your enemy
With the unemployment rate of software developers being extremely low, the chances are that someone looking for a job that you are interviewing, already has a job. When I said my turn around from looking for a job to getting a job is about three weeks, I didn't mean to imply that I was a special snowflake.
A company I was working for went through a few rounds of layoffs before everyone was let go -- this was in 2011. Without fail, every developer and even L2 support person had another comparable job within a month.
If a company makes the hiring process too long, more than likely if you are in the right market and you are just a regular old "Full Stack Developer", by the time you go through the process, you've already received a couple of offers
Besides, if I'm looking for a job and I am unemployed, the time I am taking to do homework, I can be meeting with recruiters, preparing for interviews, brushing up on my skillset, etc...
And I need to know what the work exactly entails, and what is expected of me. Many interview questions are disjoint with what the job actually requires.
>Prove to me you can
I can show you my past experience, and I can do technical exercises. What I can't do is devote a ridiculous amount of time and effort to poor questions.
As someone who has hired a lot of devs over the years (almost exclusively for our offshore team in India, but sometimes in the EU), I can tell you that the number of candidates who embellish and down right lie about their capabilities and past experience is shocking.
Truth is, I hate both sides of the interview divide, as interviewer and interviewee - it's a horrible, inefficient, flawed process regardless which side you're on, and nobody has the answers.
If Indian offshoring teams constantly lie about their credentials way more than local, I would think having different interview processes for different sources of candidates would be a better option than a process for the lowest common denominator.
People outside of India often embellish or exaggerate too though, even if not close to the degree that I've experienced in India (disclaimer: this is my own opinion based on my own experiences over 10 years or so. Obviously India has a lot of great, honest Engineers, our organisation never sees them though, largely because we don't pay well enough).
A good reputation with solid references that are checked from real engineers and managers that you actually delivered a good product seems like it would suffice to override the straight up lying, to me. Is that not the case?
References are an excellent way to confirm someone that someone did actually work at a particular place in a particular role and that they are not a total asshole. Beyond that, unless you know the reference well, I think they can be unreliably.
The reference knows the candidate and likely feels a much closer connection with them than they do with you. Assuming the candidate isn't an asshole, they will want to help them out by giving them a good recommendation. If the candidate was let go due to downsizing or such, the reference may even feel pressure to help the candidate find a new job.
So it's a great data point to have and as you say, it can help weed out the straight up liars.
But any 2 given candidates with 5 years at Acme Inc are not interchangeable. Some candidates are just better at programming (or some subset of it) than others, and I think employers try to find ways to predict that at interviews.
One technique I have found works is to do incorporate your own open source code into your work. Then when they want to see samples you have commercial quality code that isn't company property.
This whole thing misses the point. We need WhiteboardFreeAndAlsoTakeHomeFree. In other industries, my resume and a quick discussion verifying that I actually did the work I said I did is suffficient
I really don't buy that a resume alone can sufficiently put across your actual level of ability as a Software Engineer. And there are plenty of people who are better talkers than doers. One way or another I think it's entirely reasonable to want to see actual code.
If you want to do that by way of an open source portfolio, sure. But not everyone has open source contributions, so then I would need some other process for acquiring a work sample.
I have seen many people here say you should hire people on a contract basis for a few days/a week. I don't know what it's like doing that in the US, but for the UK market that sounds like a ton of administrative overhead for both parties to take on in order to establish if they are even a good fit.
This style of interview works in plenty of other professions that are much more rigorous than software development. You'll be hard pressed to find an aerospace engineering company that is going to ask candidates to evaluate integrals on the whiteboard that they'd normally look up in the CRC or implement a numerical solution for (probably using a prepackaged library), for example. Yet you're proposing an analog of this very thing here.
So say you are at a job. fairly happy. Maybe not your dream job, but you decide to look around and interview with me.
I could present you two options:
1) I just hire you after a 30 minute chat. 50% you don't work out, and we fire you after 30 days.
2) We have a longer interview. We whiteboard. We take home test. We whiteboard some more. 90% chance that you don't get fired after 30 days.
Which would you prefer? As a business owner, I am happy to just try people I don't know well - IFF they are willing to accept that there is a very good chance they are fired within the first 30 days.
There is such a huge range in developers. The haves vs the have-nots can be a 100x different productivity difference. I really want to try to tease that difference out. It is really really hard.
No way! The lamers you end up firing (after 30 days' pay) will easily make a living out of it.
They could even be PARALLEL lamers, pulling 30 days pay off multiple sucker companies.
It seems like they could easily drop half of those jobs off of their resume. That's usually the advice given for people who leave jobs after a short period.
At my current company, we fired a guy after 3 days because he misrepresented his skills. I didn't interview or hire him, but I suspect his buddy did the interview.
Right, then maybe it would self select out those that can't do the job.
Interesting idea. If you fire fast enough it may not actually cost that much more money to a business to hire a bit more as long as you fire the bad ones fast.
Same here. I feel I have vastly more control of my work performance over the course of 30 days than I have control of the assessment of 6 interviewers after seeing me for 30 minutes.
In other words, I think there is far more than 50% chance that things work out after 30 days and far less than 50% chance that I impress 6 interviewers.
> 2) We have a longer interview. We whiteboard. We take home test. We whiteboard some more. 90% chance that you don't get fired after 30 days.
But a 400% increase in that you find some sort of excuse not to hire me and I won't even get hired in the first place. Your percentages only make #2 more attractive if there's a more-or-less equal chance of being hired both ways.
Well, #2 makes more sense if you value stability and not suprises.
I suspect many people would rather do 10 interviews and then get 1 job they keep for a year+ compared to 2 interviews and a 50% chance the job that hire them, fires them in 30 days. But I could be wrong, mostly basing on what I would want.
#1. I'm totally fine with firing after 30 days if I don't work out. I'm positive it won't, so I'd prefer to prove myself doing real work.
That's the way it used to be done and I think we should go back to doing that. Read the resume, ask some questions about the resume, 30 minutes to an hour full interview, done.
You get hired on, put on a probationary period, if they don't work out, fire them.
Actually I would greatly prefer option 1. I am very confident that given nearly any situation I will prove my worth and have never had an employer disappointed with my work. I am not as confident I would complete a contrived coding skill challenge on the spot on a whiteboard because I never work like that in reality. My job is to sit here and solve unique problems by any means available to me in a maintainable and scalable way. I do that very well and that is hard to test via whiteboard implementations of contrived examples.
That is how it works in other fields. One of our managers asked his friend that owns a body shop how he finds good employees. He basically has a chat with them, feels them out, then hires them. If they don't work out he hires someone else. Perhaps it shouldn't be as stigmatic as "firing" after 30 days but you have instead hired someone on a 30 day contract with option to hire permanently. If they don't work out, that option is not exercised and that person is free to go try somewhere else. I can tell pretty quickly from chatting with a developer if they are a total fraud. I can't tell really quickly who will become a great dev, I just know when someone has the chops to have potential.
I've done it many times. It's attractive if the offer is attractive. Last one I took was a $20k raise over the prior job. The one before that was a $30k raise. It's only risky if you're not confident in your skills.
That's (among other things) what the walkthrough / debrief is for.
I like the format, but it obviously has other downsides, such as a higher up-front investment from the candidate.
That being said I found the format enjoyable last time I went through it. It was less stressful during the interview itself, and I felt more confident walking in. I would recommend it to companies who are considering it.
That would show you they have a strong network of good coders and can communicate specs and get quality code done in a timely manner. You should hire them for management!
too many programmers cant program and hurt their fee-fees so a company was made to accept fucking 300$ per ad. Anyone who cant whiteboard or pseudo is fucking retarded.
Whiteboard problems work great as a general intelligence test if administered correctly. A well designed whiteboard problem will filter out people of lesser intelligence. This means the people you would be working with would generally be more intelligent. This is not a bad thing.
Furthermore, whiteboards are great communication tools. I spend some time on VRChat's whiteboard room teaching people various algorithms, and other abstract things to help me learn. Someone who knows how to use a whiteboard and communicate correctly would be a better hire than someone who doesn't.
If the company you work at uses whiteboard problems to vet interviewees, just drill them. With a little practice, you'll have a better chance.
This is so wrong that it actually hurts my brain. Albert Einstein, a certifiable genius probably could not tell you how to invert a binary tree, this has nothing to do with intelligence and everything to do with how many HackerRank problems you have memorized.
Obviously, but I was specifically referring to the typical algorithm oriented whiteboard questions found at major tech company interviews. Working a real world problem on a whiteboard I see no issue with.
True, but there are also brain-teaser type problems that don't require memorization of obscure algorithms, and those could actually be disguised intelligence tests. (But I suppose if you really wanted to you could memorize most of the brain-teaser problems in existence.)
I had to write a JavaScript program on graph paper (with no computer on hand) as a college test. Then the professor would type them out afterwards with you and try to run it. Whenever I hear about this whiteboarding issue I think of that. It was actually kind of fun in a weird way though. I drew nice curly braces.
Heh, I code pretty often on paper when I'm working through a design and my style has evolved to just using < and > as proxies for curly braces which saves me time, since trying to draw a nice curly brace takes me so long.
Some proportion of perfectly good engineers couldn't pass a whiteboard interview to save their lives, for much the same reason I couldn't pass a job interview that measured communication skills by karaoke performance and emoji literacy.
The company needs to evaluate your problem-solving skills though. I mean, I'll admit that writing code on a literal whiteboard is more physically arduous than on a keyboard or even a piece of paper, but if the root issue is live coding challenges themselves, I don't see a way around it.
Some companies look at your GitHub profile instead, which imo is much more unfair, because it presumes you've had the free time and the desire to work on side projects, which shouldn't be a requirement for a job.
Maybe companies should adopt an either-or policy? Give the interviewer the option to demonstrate their skills in the form that works best for them.
360 comments
[ 2.7 ms ] story [ 293 ms ] threadI don't have any solutions only complaints and bitterness, sorry.
We only do them when we are pretty excited about a candidate but need more information to make a hiring decision.
It's cheap, really, considering the cost of sourcing candidates and the cost of making a bad hiring decision.
It still seems strange to me to pay for throwaway work but I can also see how that’s really just my personal sentiment / bias and this is probably a pretty good and balanced approach.
This type of interview self-selects for people with fewer family/non-work obligations, who are willing and able to spend their free time still programming.
Are you also job hunting at work, doing interviews on your employers time, etc?
That guy already has a good job. Another company is trying to poach him. Why would he, or any other qualified and gainfully employed candidate go through that unnecessary homework bullshit for a company that's trying to recruit them? The company has its priorities misplaced. They should be trying to convince the candidate to join them, not putting up barriers to their most qualified candidates.
I mean this isn’t a lottery, and hopefully you’ve reasoned there will be a high probability of getting hired; say 50%. So then the expected value of your time is $6.25k/hr.
Go, take the moral high ground, and don’t do the homework. That helps rational minded folk achieve an even higher hit rate.
There are much better and less humiliating ways to get top dollar. Work your ass off and build reputation is the biggest one.
If you are a company and you have to call a recruiter, you're already behind. Putting people through that stuff just makes it worse.
I mean, even "discount" recruiting platforms like Hired and Vettery will cost 5-figures when we make a hire through them, and traditional recruiters often charge 20% or more of the new-hire's first year salary. A few hundred bucks to get some more information about a prospective coworker is cheap.
There's a number of people with CS or SW engineering degrees who can't actually code. Those can often quote you Gang of Four patterns, discuss broad slices of tech and draw architecture diagrams on the board. But still can't code.
Is there a person who claims to be a coder that has configured and launched a multi-environment microservice with several attached artifacts like DBs and queues, that knows in depth what each is doing, that can't code? At that point you're just testing whether someone has memorized syntax details that they might usually get from an IDE or a 3 second google search in regular development. I have been writing production JS for years but still have to occasionally look up Array.slice vs Array.splice parameters, especially if I haven't done a lot of data munging in a while. That may indicate to a person giving an interview that somehow I'm "faking" it, when in reality its just a momentary stall-out in my brain's lookup tables.
Funny that you mention it. I know a person who can't shut up about microservices, Kubernetes and CI and can't code their way out of paper bag. They had no problem passing one of those interviews.
And sure rote API memorization isn't the point. But if a candidate can't code say bubblesort (or any kind of sort) in 30 minutes they are not very good at coding - and it doesn't matter if they can quote their architecture patterns by heart.
Thats bullshit. Sorry. Most developers will NEVER implement a generic sorting algorithm except in a code interview. You say you don't want rote API memorization, but you do want rote sort method implementation memorization. Yes you can be a system or tools developer and maybe have a higher chance of doing it, but its 99% likely even then that you just use a library for it for the language you're using, or copypastaing it from someone who's studied the specific implementation for your lang.
Why would I go through that trouble? I have 20+ years of experience that I can explain how I architected and developed from the website, to the middle tier, to the database to multiple VPCs on AWS and dev ops. I'm not going to do homework.
When I was first starting out I might, but living in a major metro area that's not on the west coast, there are more openings for senior devs/architects than people to fill them.
If a company wants to try me out, I'm more than willing to do a contract to perm, but my hourly rate is going to be enough to cover self employment taxes, make up for not getting paid for time off and at least two or three weeks between employment.
What does that number look like? 10k a week?
2080 - hours in a work year
-80 Paid Holidays
-120 Paid Time off
-120 Gap between employment (based on my history)
= 1760 work hours per year
FTE Salary * .028 (Employer Medicare Contribution) + $7967 (maximum social security amount - 128500*.062) = minimum salary
minimum salary/1720 hours = pay rate.
Take a reasonable salary for my market as $140,000, that is about $152000/1720 = $88.37/hour minimum.
Adjust the number based on market, skill set, and the amount of time you estimate between jobs. I'm also not taking into account health benefits that you would need to pay yourself because I'm covered under my wife, or 401K matching. I would add 4% to the hourly rate to cover 401K matching.
We have a take home test. It is an obviously fake problem, but we review it to the grade we would for our production code.
We don't find that candidates turn down taking the test - it's capped at 3 hours so that it can't take up lots of time. We do find that we have a low pass rate, and even among candidates with 10+ years experience, we still find candidates who write code that is just not good, and who haven't read the spec.
I'm not at all suggesting that you might be in this category, and if you can find jobs you want that don't require tests that's great.
However, there are people with plenty of experience, who can architect things brilliantly, and who can't write a ~300 line program in Python in a way that satisfies a spec or in a way that anyone would be able to maintain. That's important for many companies, and so I think tests can be one useful part of an interviewing process.
I said no thanks and moved on to other companies. Felt good. I just avoided working in a culture where there will be high pressure to always perform. :)
They can afford it, but still, it's far to say that the wasted effort isn't entirely one-sided. Hiring is an expensive and inefficient transaction.
Figuring out how to make this both more fair and more efficient is a really tough problem.
If you want to get that first house downpayment for the Bay Area, I'd say it's almost essential at this point.
We use a whiteboard in our interviews for sketching UI, and sometimes drawing a database table. Generally candidates find this much easier than talking through their design, and we think that interview very closely represents what we do on a day to day basis.
If you're asking candidates to balance a binary search tree when no one in the history of your company has ever had to do that, you're asking the wrong questions.
[1] http://prog21.dadgum.com/177.html
We do a mock technical meeting with multiple members of our tech team and the candidate presenting options, talking through pros and cons, etc. Much of the interview is about assessing communication rather than technical skills.
The interview is basically a standard tech meeting that we hold regularly in the team to discuss designs of new projects.
Obscure “I had to google it before asking you” problems are the problem not the whiteboard. I think whiteboards are good visual aides.
Sometimes I just ask people to draw a frog though.
In my opinion it is all about aligning your questions with the day to day task you expect from people. If the work is very algorithm heavy, by all means probe for that in the interview.
I base my interviews around one main question: assume the tech challenge you written beforehand is a prototype for a complete product/service. what are the steps necessary to get us there and beyond?
I do not care about the candidates tech preferences or the exact solution as long as the argument for it is coherent and not just based on heresay. Then I probe for a couple of things within their solution where I see potential weaknesses based on their argument, experience or code in relation what we look for. It is more about problem solving, decision making and communication than computer science.
Candidates are free to just talk trought it or use whiteboard/paper to draw it out. But if you choose the former you better not forgett what you said five minutes ago.
That said, I don't think whiteboard programming is always bad but it is a skill that I don't exercise and it showed.
My advice, talk through the problem with the interviewer and don't start writing code on the whiteboard until the interviewer has ok'd your proposed solution.
I was the same but I do a lot better now after having done some 200+ technical interviews and a lot of practice on my own.
Question: How do you validate that the posted company or job position doesn't need whiteboard? Is it after the fact, as in a disgruntled candidate complaining? I couldn't find any information about this on the site.
Yet a lot of people are never really taught to do it. Perhaps they pick up this fundamental skill just fine after a couple whiteboarding sessions in the company.
If a company is rejecting candidates for not having a skill that is really easy and quick to obtain, they'd better not be one of these companies that keep complaining about shortage of talent.
Even better, I would love a site that classifies job offers/companies by:
Anyway, I hoped you could search only for jobs where this box was checked by the company, but apparently not...
EDIT: It does allow searching for minimal salary and remote jobs, among the wishes listed in a sibling comment.
EDIT: Ok, my mistake, my memory is failing me. "Doors that close" is used in a whole bunch of Joel blog posts, and "walls and doors" is used in the original Joel Test description.
But WaybackMachine seems to confirm that the official label from the "Joel Test" has always been "quiet working conditions" and does not appear to have been changed.
So unless Joel went back and rewrote the past, it might be our memories. I am fairly sure that he did have another blog post that stated explicitly that every developer at FogCreek had a door.
Unfortunately we haven't yet expanded much out of the Midwest, so it MAY not be of use to you yet. But check it if your interested.
I went there, typed in "developer" in the search box, and got dropped on a map zoomed in on the Kansas/Oklahoma border and a message saying my search didn't match anything. Took me a while to notice the "zoom out on the map" part. Not sure why I landed in the middle of nowhere in the US, I'm located in Europe. In any case, super unintuitive.
Also, this might be an American thing I'm missing, but which (if any) option of "Pod Office Layout" or "Closed (Cubicle) Office Layout" corresponds to "proper walls and a proper door"?
I'd also suggest adding a filter for minimum salary.
Hope this helps.
On Jobiki, we don't have job postings. Just companies and data about them. So the "minimum salary" and "developer" searches are more job related, while we are more company related. Either way, helpful feedback.
-----------------
As for the "proper walls and a proper door" aspect, are there developer/traditional employee jobs in Europe that can have a real office? In the US, unless you are a manager, executive, very experienced employee, you don't usually get an actual office. Maybe its more common in Europe?
I have a real, quiet office with lots of daylight. That's actually one of the reasons I'm staying at this job. That, and the fact that I'm not subjected to low-status micromanagement techniques like Scrum. In short, I have working conditions befitting a qualified adult.
Yes. Maybe not every single developer; there might be two or three or four to an office, but it's still an office with walls and a door. There are companies with more open spaces and twenty developers to a room, but the (much) smaller ones are the usual case from what I've seen. ("Europe" is a big place, of course.)
"Pod" seems to mean completely different things to different people.
"Pet friendly" workplaces tend to be noisy and discriminate against people with allergies, so some users will want to filter them out.
Even if you don't want to track current openings, what kind of jobs a company has is important information.
And good note on the "pet friendly" environment.
We in the processes of adding that information to outline what positions a company hires for. (Whether or not they are currently open or not) Well, more what departments that a company hires for. Going all the way down to job title seems a bit too granular, maybe I am wrong? But by department seems a happy medium?
I'm just looking for the candidate's thought process and some pseudocode. I could do the same thing in an empty text file but the substance of the interview wouldn't change.
My feeling right now is that being anti whiteboard is focusing on trivialities like complaining that the office style guide uses Allman vs K&R bracketing or something. But I'm open to having my mind changed if there's something more to it.
Actually hand-writing code with a pen has always seemed weird to me. As a programmer, I compose code with a keyboard. So I give candidates a laptop and use an interactive screensharing tool (I like https://codepad.remoteinterview.io) where they can run code in the language of their choice in a browser, and I can watch and talk through the process.
Most problems in practice that require non-trivial application of algorithms, dynamic programming and the like have two characteristics that make them differ considerably from whiteboard style quizzes. For one, they're going to be much less contrived (pick a random leetcode question for an example of this, odds are it's contrived). Secondly, they're going to be resolved when developers talk to each other about them and there is recognition of the solution, which most of the time is an application of algorithms and data structures with library implementations.
The ability to whiteboard things like "given an array of integers and a target find the indices of the pair of integers in the array that sum to the target" and "find the first missing positive integer in an unsorted array in O(n) time and O(1) space" provides almost no useful information about a candidate's ability to solve an actual problem the company faces in most instances. There are exceptions, but interviewing everyone for the standard of that one exception is asinine.
Asking someone to solve an obscure mathematical problem (the Two Egg problem seems to be in fashion) doesn't do much except test whether the candidate has memorized the answer.
But since we’ve gone there, many high power companies also have a lot of chuckleheads running around.
As an employer I don't care how great your skills are, if you can't walk me through your thought process for 45 minutes you're not going to be overly successful. If you can't incorporate feed back or engage when pressed to change your design you're probably not going to be successful.
Do your recruiting right and you shouldn't need the white board to simulate whether the candidate can code at all (I think white-boarding with the intent of looking for named algorithms is a waste of everyone's time), instead you want to see if they can synthesize information, engage with other people, and otherwise display the soft skills that tend to be much more useful metrics for employee success than coding aptitude.
Granted, my industry is known for not having deep coding problems to solve, this strategy might not be as useful in verticals that require more technology chops.
The post you're responding to makes a great point that this isn't the normal working environment for 99% of actually-writing-code developers. I discuss and iterate designs with my coworkers/leads/managers/architects just fine, but a surprise algorithmic problem you have to simultaneously solve, draw on a whiteboard, and constantly present to an audience while being timed isn't something I have been great at. I bet many others aren't either. I got good at it after a few interviews last time I was looking for a job; but if I hit the interview trail again today, I'm confident that I would flounder in that setting for a while.
Imagine if, instead, the candidate worked out a project -- maybe at home, or maybe in an interview room for some time -- then you take time to review and understand their work and then go through this back-and-forth process of discussing their work. This would also benefit the candidate's understanding of how you collaborate to problem solve in your work environment.
The problem with this approach is that it requires the interviewer to actually invest time to understand the candidate's work.
Anyway, I hope you see why many see it as a problem that the process for a candidate to succeed at a job interview is to practice interviewing skills rather than demonstrating their engineer skills.
As an investor, I don't care how great your skills are, if you can't come up with your new business idea on the spot and walk me through your thought process as you're doing it, you probably suck.. right?
Nah.
Unless you already have the answer, the first step is to come up with the solution. This could involve time spent alone just thinking, or brainstorming with coworkers, or researching the problem on the net, etcetra. What the right steps are depend on the problem, available resources, your background, even your preferred way of working.
The second step is to present and dissect the solution. I dare say this is the point at which the majority of engineers have no problem whatsoever talking about their thought process.
Do you work in an industry where engineers genuinely have to walk somebody through their thought process while they're trying to think up a solution?
If a problem comes up at a meeting and you don't have a solution on the spot, you take note and discuss it later or add it on the agenda for the next meeting. I think that's how people work.
I don't care about where, when, and how you came up with the idea. I care that you can present and discuss it once it's ready for that.
I think this is why many prefer the take-home test. They can focus on the solution. Then, at the interview, they can focus on the talk about the solution. It's also a great equalizer as e.g. people coming to work in a domain they have less experience with can take more time to research the solution space.
The complaints about homework taking up too much time may be valid, but I'd be most happy to trade 2 hours of interviews for about 75 minutes of homework and 45 minutes of interview.
Is there any scientific evidence to support that, or is that just industry hokum?
And communism probably redistributes wealth if it is administered correctly.
If companies want to hire based on general intelligence (not personality, team work, communication and so on) then they should administer IQ tests, which are based on a century of rigorous research. That would at least give you a fighting chance of measuring G.
Why do you think white boarding can measure general intelligence?
When not in an an interview I like playing with these kinds of problems, but if I look it up I'll probably find interview prep where it shows the answer as well.
Could you summarize just the problem please?
If an egg breaks when dropped from floor n, then it would also have broken from any floor above that. If an egg survives a fall, then it will survive any fall shorter than that.
The question is: What strategy should you adopt to minimize the number egg drops it takes to find the solution?. (And what is the worst case for the number of drops it will take?)"
http://datagenetics.com/blog/july22012/index.html
Hmmm, that's an interesting question. It's the Price is Right closest without going over solver...
Practical answer, drop from the first floor and then the second. You're probably not going to make it to the third.
I don't want to put my actual answer in case others want to solve it. But I will say there's an obvious solution, but if you apply one of the hard problems of computer science you might eke out a bit of an edge.
EDIT: Actually I don't think that's right. I think the answer varies based on your expectations, and should be tuned after each run if you run the same test multiple times. I do have a good starting point in mind though.
That's The Price Is Right, not Wheel of Fortune ;-)
I was definitely picturing The Price is Right at least.
After thinking about it on the ride home today, I was not quite on the right track before. Again don't want to post my solution because the entire point in asking was so that people could see the question and work it through themselves.
The answer should be a form of binary search, but since you only have two eggs, you'd have to do a sequential search from the bottom floor. You have one chance at a mistake, so I would almost say start with the 2nd floor, but I know it will break on the first floor.
I don't see how that in any way gauges programming what so ever.
yeah, sorta. essentially you partition the 100 floors into some number of groups (i forget what partition length is optimal) and drop the first egg at each segment until it breaks, then go linearly from the previous one
Since you have 2 eggs you can start on the 33rd floor. It breaks you can use the 2nd egg from 1st to 32nd floor.
If it doesn't break, use the first egg on the 66th floor. If it does break, the answer is between 33 and 65, if it doesn't the answer is between 66 and 100. That cuts the maximal testing time time from splitting at 1/2 (1st egg at flr 50), to 1/3rd.
To optimize further, since in the bad case we'd have to search up to 34/35 floors, you can mathmatically find a number where you split the drops at an interval (IIRC the "real" optimal answer is 14, then 13, then 12, etc), which means you're doing less explicit checking.
At 14 - i, you have 10 drops to find a range of 13 - i floors in which the optimal path is found. So instead of a worst case of 35, you have a worst case of around 17.
I find the best way to approach this sort of problem is to first find one optimization, and then use the same process to find if there are further optimizations.
It does relate to programmer's ability to amortize worst case running time.
Once you realize that 1 egg requires linear search you just have to realize that with 2 eggs you have to decrease the level increase by 1 on each success.
Of course those must be some crazy genetically modified eggs.
I would guess the interviewer probably rates people who have memorized the solution far higher than people who have never encountered it and solved it with their brains.
I can fully understand dislike for puzzles and being asked to implement irrelevant algorithms in pseudo code. The interview should reflect the job being interviewed for.
I've found whiteboarding to be mutually helpful in questions about system architecture. Plus, it's something that we actually do on-the-job.
I mean ask yourself this: do you ever use the whiteboard to write code to the extent you expect some poor kid trying to get his first job to do? Hell no, you screen share an IDE or paste code in an email.
People used to have to write code on paper (I did this a few times in college ages ago) and that comes from the cost of compiling stuff way back when. Computing time is friggin cheap, that's why no one does it. To expect some new guy to be adept at that ancient practice is silly.
[1]: https://en.wikipedia.org/wiki/Encoding_specificity_principle
I think few frontend developers would consider the work they do to be "UI design".
A UI tree component is not an AVL tree, plus most shops just stick with whatever comes with the framework, or buy some stuff like DevExpress toolbox.
Also UI knowledge requires design skills and knowing what the stack is capable of, not CS bingo about stuff I haven't used in 20 years.
I can dust off my data structures and algorithms CS book if I ever need to implement one.
What a cluster it's all becoming on the software engineering side.
Wow, what an incredibly tone deaf response.
>Some companies simply do not understand how to properly engage in employee selection.
Maybe changing this prospective is the point of the "incessant whining."
>I need to know you can do the work, prove to me you can, I will then hire you and pay you to work.
I'd have to know how you are testing, but I'd bet dollars to doughnuts your method has no way of predicting output in any meaningful way.
>What a cluster it's all becoming on the software engineering side.
Absolutely. I would say it's endangering the overall quality of the industry. The saying goes, if you are a bad manager or a bad company the first people to leave are the A and B players. The people that will never leave are the C and D players. I suspect people who do all this trivia don't even know what an A or B player looks like.
It's really not though. Here's the bottom line: You want money from a company. The company doesn't owe you jack. shit. If they fucking whiteboard, and you want money from them, then do the whiteboard. Later, when you are employed by them, try to suggest they improve their process. If you have better options, take them.
> Maybe changing this prospective is the point of the "incessant whining."
Sure. But is that the companies #1 priority, or do they have other things to do, like make money and stay in business that take precedent? Anyways, the way you do this is from within or providing feedback and having conversations with recruiters -- you know, human interaction. This job board is the ultimate culmination of millennial passive-aggressive behavior.
> This job board is the ultimate culmination of millennial passive-aggressive behavior.
This job board just enables more people to pursue a course of action that you're already suggesting they do!
I am frustrated at times just as much as any other engineer by playing "monkey-see-monkey-do" in front of an audience in order to receive employment and I have indeed passed up job offers because I was turned off by the interview process (but again, that was my choice) but if you take a step back, look at the overall job market, and what other workers have to go through to get a job, we really do have it made, and this seems like a minor nuisance at best.
No, this is how change is driven. How do you think change happens? Getting a big committee together and getting buy in from all interested parties? That's not how it works. But maybe this is how it works, maybe this job board attracts a bunch of candidates who are tired of the status quo, and other candidates start telling the companies on other job boards that, sorry, but they're more interested in the companies that list on this particular job board, and those companies then see that the talent pool they're drawing from is smaller than it needs to be, and they decide they want to draw from the larger pool, so they change their practices, and then that snowballs, well maybe now you have industry-wide change.
I don't personally see this having much of an impact, but I think the people who started this are doing exactly what you're saying they should be doing, except that you're pillorying them for it because they aren't doing it through some impossible broad consensus approach.
> what other workers have to go through to get a job, we really do have it made, and this seems like a minor nuisance at best
It is true that we have it made, but I do not think it is true that we have it made in this sense. We have it made because our skills are very highly in demand and because of that, we are treated well and paid handsomely once we get a job. It is true that we should never ignore, down-play, or fail to appreciate this privilege, but that doesn't imply that we should not discuss or advocate for improvements where needed.
Where we don't have it made is in the predictability of employment once competence has been demonstrated. Other professions and trades usually have long-and-tedious up-front competence proving phases, but then they have a credential that will be respected by future employers when they have open positions. We are fairly unique in forcing people with long and distinguished careers to continually re-prove themselves. Our employers have open positions, but it takes a lot of pointless and duplicated busy-work for a competent person to slot into them.
I think what it comes down to is that our process is relatively mediocre, good, or even great for inexperienced unproven new entrants to the job market, but rather sub-par for experienced and proven folks. And that's why you see people looking for a better way.
Do mechanical engineers draw up a design for a valve or something at every job they apply for?
Another example it's related to is the XKCD standards comic. Rather than improve existing standards, the committee breaks off with dissenters, forms a new committee, and now you get "Situation: There are now 16 competing standards"
edit: Better Solution? Talk to recruiters? Let them know you won't consider places that force you to play "dance monkey". The letting them know part is key. More broadly: maybe unionize?
I agree with your bottom line as well. Both are true! It's a negotiation, and it isn't zero-sum. Working is good for both the employee and the company. Neither is in a universally stronger negotiating position.
I'm not annoyed by bad interview processes and strong preference for false-negatives, I'm annoyed by that in conjunction with the claim that there is a shortage of competent workers. There is some lower-hanging fruit to take care of before that claim makes sense, and improving recruiting processes is among the lowest hanging (along with raising wages, obviously).
Unfortunately, unless the sides are favored to the labor market (in our cases it is not, and even if it was, there is always outsourcing), this equation is not equal.
Both are true, but it is an extremely unbalanced equation. At the end of the day, the company has the money and you have the skills. Unfortunately only one of those helps you pay the bills -- unless you can figure out a way to pay your rent in exchange for your skills.
And the company wants to make money from me. In my market, there are a lot more open positions for senior devs than senior devs that are actively looking for jobs. I
You need that money more than they need you. There really are few exceptions to this rule -- AI being one of them.
Again I wish it wasn't like this, but it's the reality for the overwhelmingly majority of software developers in this country.
1. That you are in an area of the country with a lot of opportunities
2. That you kept your eye on the market and made sure that your skill set in demand
3. That you kept your resume updated
4. That you kept your network of recruiters, former coworkers, and references fresh.
If you have limited savings like the vast majority of Americans -- time is your enemy
With the unemployment rate of software developers being extremely low, the chances are that someone looking for a job that you are interviewing, already has a job. When I said my turn around from looking for a job to getting a job is about three weeks, I didn't mean to imply that I was a special snowflake.
A company I was working for went through a few rounds of layoffs before everyone was let go -- this was in 2011. Without fail, every developer and even L2 support person had another comparable job within a month.
If a company makes the hiring process too long, more than likely if you are in the right market and you are just a regular old "Full Stack Developer", by the time you go through the process, you've already received a couple of offers
Besides, if I'm looking for a job and I am unemployed, the time I am taking to do homework, I can be meeting with recruiters, preparing for interviews, brushing up on my skillset, etc...
And I need to know what the work exactly entails, and what is expected of me. Many interview questions are disjoint with what the job actually requires.
>Prove to me you can
I can show you my past experience, and I can do technical exercises. What I can't do is devote a ridiculous amount of time and effort to poor questions.
As someone who has hired a lot of devs over the years (almost exclusively for our offshore team in India, but sometimes in the EU), I can tell you that the number of candidates who embellish and down right lie about their capabilities and past experience is shocking.
Truth is, I hate both sides of the interview divide, as interviewer and interviewee - it's a horrible, inefficient, flawed process regardless which side you're on, and nobody has the answers.
People outside of India often embellish or exaggerate too though, even if not close to the degree that I've experienced in India (disclaimer: this is my own opinion based on my own experiences over 10 years or so. Obviously India has a lot of great, honest Engineers, our organisation never sees them though, largely because we don't pay well enough).
The reference knows the candidate and likely feels a much closer connection with them than they do with you. Assuming the candidate isn't an asshole, they will want to help them out by giving them a good recommendation. If the candidate was let go due to downsizing or such, the reference may even feel pressure to help the candidate find a new job.
So it's a great data point to have and as you say, it can help weed out the straight up liars.
But any 2 given candidates with 5 years at Acme Inc are not interchangeable. Some candidates are just better at programming (or some subset of it) than others, and I think employers try to find ways to predict that at interviews.
> prove to me you can (do the work)
A take home exercise only proves they can get the work done elsewhere. It doesn't prove that they actually did it.
If you want to do that by way of an open source portfolio, sure. But not everyone has open source contributions, so then I would need some other process for acquiring a work sample.
I have seen many people here say you should hire people on a contract basis for a few days/a week. I don't know what it's like doing that in the US, but for the UK market that sounds like a ton of administrative overhead for both parties to take on in order to establish if they are even a good fit.
In my experience, anyone we've hired WITH open source contributions has been 10x better than those without.
I could present you two options:
1) I just hire you after a 30 minute chat. 50% you don't work out, and we fire you after 30 days.
2) We have a longer interview. We whiteboard. We take home test. We whiteboard some more. 90% chance that you don't get fired after 30 days.
Which would you prefer? As a business owner, I am happy to just try people I don't know well - IFF they are willing to accept that there is a very good chance they are fired within the first 30 days.
There is such a huge range in developers. The haves vs the have-nots can be a 100x different productivity difference. I really want to try to tease that difference out. It is really really hard.
Wow, 8 jobs last year? Busy life?
Personally, that's my preference. If I don't think I can do the job I'll know after a 30 minute chat.
Interesting idea. If you fire fast enough it may not actually cost that much more money to a business to hire a bit more as long as you fire the bad ones fast.
In other words, I think there is far more than 50% chance that things work out after 30 days and far less than 50% chance that I impress 6 interviewers.
But a 400% increase in that you find some sort of excuse not to hire me and I won't even get hired in the first place. Your percentages only make #2 more attractive if there's a more-or-less equal chance of being hired both ways.
I suspect many people would rather do 10 interviews and then get 1 job they keep for a year+ compared to 2 interviews and a 50% chance the job that hire them, fires them in 30 days. But I could be wrong, mostly basing on what I would want.
That's the way it used to be done and I think we should go back to doing that. Read the resume, ask some questions about the resume, 30 minutes to an hour full interview, done.
You get hired on, put on a probationary period, if they don't work out, fire them.
That is how it works in other fields. One of our managers asked his friend that owns a body shop how he finds good employees. He basically has a chat with them, feels them out, then hires them. If they don't work out he hires someone else. Perhaps it shouldn't be as stigmatic as "firing" after 30 days but you have instead hired someone on a 30 day contract with option to hire permanently. If they don't work out, that option is not exercised and that person is free to go try somewhere else. I can tell pretty quickly from chatting with a developer if they are a total fraud. I can't tell really quickly who will become a great dev, I just know when someone has the chops to have potential.
Why did the industry seem to forget this?
I would not leave a w2 job for a contract job. Nor would any good developer I know.
This is why the industry "forgets" it. It's not that attractive to a good candidate.
I like the format, but it obviously has other downsides, such as a higher up-front investment from the candidate.
That being said I found the format enjoyable last time I went through it. It was less stressful during the interview itself, and I felt more confident walking in. I would recommend it to companies who are considering it.
Furthermore, whiteboards are great communication tools. I spend some time on VRChat's whiteboard room teaching people various algorithms, and other abstract things to help me learn. Someone who knows how to use a whiteboard and communicate correctly would be a better hire than someone who doesn't.
If the company you work at uses whiteboard problems to vet interviewees, just drill them. With a little practice, you'll have a better chance.
Maybe I’m missing the point though.
Heh, I code pretty often on paper when I'm working through a design and my style has evolved to just using < and > as proxies for curly braces which saves me time, since trying to draw a nice curly brace takes me so long.
Some companies look at your GitHub profile instead, which imo is much more unfair, because it presumes you've had the free time and the desire to work on side projects, which shouldn't be a requirement for a job.
Maybe companies should adopt an either-or policy? Give the interviewer the option to demonstrate their skills in the form that works best for them.