The sad reality of programming interviews is that it's absolutely necessary to ask several near-trivial questions in order to flush out the candidates with awesome resumes and impressive degrees who simply have no idea how to analyze a simple problem and solve it using a computer.
Lately, I've been asking "given the starting and ending times of two calendar appointments, determine whether or not they conflict." No loops, no fancy algorithms, no tricks... and asking it has not been a waste of time. I get people writing doubly-nested loops over all of the seconds in the two intervals, comparing for equality; I get multi-line predicates full of redundancy that still yield false positives and negatives; it's depressing as hell.
It's all fun and games until one of your appointmets is specified in rfc2550 format, and the meeting room is on a big ship crossing the international date line on the same day daylight savings time changes for the ship's country while a new timezone is voted into effect. Meanwhile the other meeting room is a videoconfrerence between the international space station and a ship travelling at close to the speed of light, but the real twist is the two meetings don't actually have anyone in common!
I used to disbelieve hiring managers regularly encountered candidates who actually couldn't code, or whatever other basic technical thing was reported on their resumes. Such a possibility - even the audacity of it on a conceptual level - simply seemed beyond the pale for me. I had interviewed before and not done well, and that I could absolutely understand. But I had no way of relating to the idea of someone entering an interview without the fundamental mental schema requisite for doing the job.
Then I started interviewing people for engineering and security engineering roles. That's when I realized that unless you put a lot of effort into curating your candidate pipeline, you interview engineers who literally (without exaggeration!) cannot complete anagram toy programming questions in their "favorite languages." That was a sobering moment for me.
I'm in agreement that a lot of tech hiring is suboptimal, selects for noisy heuristics and is even (sometimes) sadistic. But I've also met engineers - typically people who have not done interviewing or hiring much - who think that reports of fizzbuzz failures have been greatly exaggerated. They have not been exaggerated.
I haven't interviewed anyone in over a year, but back when I was doing it weekly I used to mentally sigh with relief when the candidate I was talking to could actually approach technical questions, even if they ultimately didn't give winning answers. It is a sad reality indeed; the bar is low enough that you have an edge by merely engaging with the problem and reasoning about it with technical competence in an interview.
Let me ask: what company do you work for and how much effort does it put into finding, attracting and most important! retaining! people who are any good?
How much say do the people working on a team have, in who gets hired? I mean people who'll actually be working with the person day to day, not some manager.
If the answer is 'we tell recruiting agencies we're hiring for vague role X, Y and Z', then why are you surprised?
Is the work any interesting? No? Generic corporate codebase perhaps? And you're getting generic people applying? How strange :)
ps. This is not directed at you in particular. I just find it strange when people don't do an inch beyond 'we pay money', and then expect a mile beyond 'i do just enough to get paid'
Attracting more good people won't reduce the number of bad applicants (it will increase it).
Retaining staff doesn't mean that you aren't hiring at .2 headcount per annum.
Assuming that there's a basic process of CV review (by team members who would work with) followed by non technical phone interview. You will still have people who fail fizzbuzz. I'm not talking about small errors reading the problem - but the inability to even put a for loop in pseudo code onto the page.
The fact that the test is required is somewhat silly - but it's hardly limited to dull corporate roles.
I can think of half a dozen ways to attract applicants in a way that'd significantly increase the quality of the applicants while at the same time significantly decreasing the number of the applicants.
See, you are assuming a basic process of a job board and anyone applying for the position.
I am saying you are so entrenched in mediocrity that you can't fathom there are much better ways.
I will say this though - they all require a fundamental shift from 'fill seats with people for minimum amount of pay, to do uninteresting work, with least amount of complaining' to actually giving a shit about people you work with, yourself, and your life :)
> I can think of half a dozen ways to attract applicants in a way that'd significantly increase the quality of the applicants while at the same time significantly decreasing the number of the applicants.
I have conducted literally hundreds of technical interviews. To me, too, it was a jaw-dropping realization that some candidates can arrive who literally have no idea how to program a computer. I don't know how they get through school (with high GPAs, even), held their last job, or impressed their phone screener. I don't even want to speculate. The sad fact is that trivial, two-minute, easy-peasy exercises can and will expose some candidates as being unable to work through them, even with the most friendly and patient coaching.
So I always ask at least one trivial question that can be solved in a minute or two with a couple of basic relations and a Boolean connective.
I experienced the exact same feelings as you. Until I started interviewing candidates in quantity, I had no clue how many candidates cannot complete FizzBuzz. The reported failure rates of this simple test are completely legitimate. In my own interviewing, it comes out at about 50/50. The 50% who do pass often make some significant conceptual mistake, for which I'm generally pretty forgiving since interviews can be a stressful experience. This question comes at the end of a hiring pipeline that does 2 phone screens before the on-site happens.
I think the best part of this is how many people are getting it wrong in the comments here or not fully thinking it through. Perhaps it's not as easy a question as you think it is in the heat of the moment during a stressful interview?
Perhaps it's not as easy a question as you think it is in the heat of the moment during a stressful interview?
This point cannot be underemphasized. "Thinking aloud", not just in front of another person but under a very stressful situation (for most people) that also basically almost never occurs otherwise in daily life -- is a specific metacognitive skill that for many people can only be (even adequately) learned by either (1) careful training or (2) surviving many repeated failures, and finally getting at least partially acclimated to these kinds of confrontations.
Yeah sure, perhaps some of the people who "bombed" that calendar test really were the walking fraudsters the interviewer (who knows they'll get to stay in their well-paying job regardless of the outcome of said interview) makes them out to be. But most are probably simply nervous, and due to a variety of psychological factors (imposter syndrome, among others) are simply momentarily blanking out, and having suffering from a very common form of mild anxiety attack which makes the problem seem much more complex to them (at that moment) than it otherwise would, under more natural circumstances.
This is why it's important to start the interview with culture/work history questions to probe how they're feeling, watching their body language, before moving on to simple questions of increasing complexity.
I've literally started nervous people with "naively print the string 'hello'"... After warming up, the best one eventually completed my max-difficulty questions.
I would add that it takes significant experience and preparation to interview people effectively. This is a difficult-to-learn soft-skill that not everyone has.
Too often folks just get dragged into an interviewer situations with no planning or coordination.
>> "Thinking aloud" ... is a specific metacognitive skill
Is there evidence for this claim? I'm inclined to believe it but that's experiential. It's also something I've never had to work to acquire, but that could be a cultural thing (my family and friends talk a lot about thinking) or a personal history thing (I have a minor learning disability, and it has forced me to develop strong, conscious meta-cognition).
It's not a given, tho, that being able to talk about thinking is distinct from being able to think and being able to talk.
I think psychology has a lot of models of cognition without a clear winner, so there's probably no conclusive answer at the moment.
But talking through a problem forces you to use verbal reasoning. A lot of programming can be done well with non-verbal reasoning skills.
Personally, quickly sketching some timelines on a piece of paper would be the fastest way to get the correct checks. Talking it through would force me to convert my mental visualizations into words, and that'd make me stumble.
people who "talk to themselves" are labelled idiots. mental dialogue is supposed to be mental.
call it social conditioning if you will. spelling out your thoughts for someone else to hear them just so they can take note of them for evaluation is the polar opposite of normal human interaction.
Let's just say that it's at best a corner case in the the toolbox of approaches our brain has for tackling problems. Yes, it's something we make use of once in a while. But more like a "caught you in the hall, here's my idea" approach. Never in a "solve this now in 5 minutes or yer OUT!" sense.
The problem with the modern interview process is that not only elevates the later approach way out of proportion to its actual significance -- but basically makes in the centerpiece of your interactions with the company and potential team members, on that fateful day.
Being a professional programmer is not an entirely stress-free job. Often, time matters and you have to think on your feet. That's why I think rejecting a programmer for losing their core competencies like problem solving, i.e. freezing, under a medium amount of pressure is valid.
I've been a developer for years and worked for multiple companies: the most stressful professional situations I've ever have been in have been maybe a 4 out of 10 stress-wise, whereas interviews range from 7 to 9 out of 10.
Interviews aren't ordinary job situations: they are contrived situations where people are making life-changing decisions based on a very short interaction.
Same here, and have worked on some extremely high-profile, complex things. Never _ever_ have I been as stressed as when asked to perform interview whiteboard questions. It simply doesn't compare.
The most stressful professional situations I've ever have been in have been maybe a 4 out of 10 stress-wise, whereas interviews range from 7 to 9 out of 10.
Agree mostly -- just that I guess I've fallen into more abusive environments than I should have allowed myself to over the years, where the stress levels have hit will into the 7-10 range.
But in healthy environments -- even when I really did screw something up (sometimes quite significantly) -- it's never above the 4-5 range.
Interviews aren't ordinary job situations: they are contrived situations where people are making life-changing decisions based on a very short interaction.
And pretending that they can read the tea leaves, and make that kind of assessment as to "whether this guy can handle a medium amount of pressure", to boot.
This is far too much of a simplification of (grand)Parent.
you don't know the circumstances that 30 year old programmer with a 2 year old child at home is facing. You could also be like certain firms and immediately nix him on the "merits" of ageism.
A female programmer might have travelled 2000 miles to just receive an abstraction question out of left-field over an irrelevant concept to the job. She flew out on this uncertainty, and she's in a rather discriminatory field.
26 year old dev has probably built CRUD apps all his short career. and, you're asking him to implement (isBinarySearchTree Boolean) on a whiteboard on the spot.
> 30 year old programmer with a 2 year old child at home ... nix him on the "merits" of ageism
A choice, conscious or not, to dedicate time to raising a child at the opportunity cost of myriad other ways to spend time is not related to ageism at all.
Most programming jobs do not actually demand one make this form of Sophie's Choice. Perhaps the Valley is so diseased, but it's not the only game in town.
> Perhaps the Valley is so diseased, but it's not the only game in town.
Hear! Hear!
One of the things that bothers me a lot about HN is the near assumption that if you're a software engineer and not in SV (or have never been in an SE job in SV) - you don't count as much.
I'm biased, I will admit: I've never held a software engineering job in the Valley. That opportunity has never occurred, nor have I tried to pursue it. I live and work in Phoenix, Arizona; at my age and position in life, even if the opportunity did present itself, I'd have to think long and hard about it. It would likely be a situation of me leaving my family to go work there, as relocation would likely not be a realistic option unless the pay was over the top (I am not going to move back to an apartment; my next house better be at least as large as my current one, and include a larger yard and/or shop space before anything else).
Here, in my current position, I am not only the oldest developer on the entire team (and I am only a few years younger than the owner of the company), but I also am one of the few who doesn't have any children. My wife and I made the conscious choice not to have kids a long time ago, and we are constantly glad for it. In fact, she thanks me on a monthly basis for not "knocking her up".
Honestly, we'd probably make terrible parents, and we're pretty selfish as a couple. We know this, so why bring children into the mix, right?
That said - here in Phoenix (where it's actually difficult to find competent software engineers for any position), I've never seen or experienced there being an issue if you have kids; every employer I've worked for has been extremely flexible.
In fact, both at my current employer, and my previous one, they encouraged you to leave when your day was up. If the end of your day was at 5pm, they didn't want you stay a minute more if there wasn't a really good reason for it. Like things would have to be well and good on fire for that to happen; anything less was "go home, get some rest - it'll be here to fix tomorrow".
And now imagine you have 4 little kids like me and how that affects the equation! You want me to move out to Seattle, Amazon? Do you have any idea how much you'd have to pay me to have anything like the lifestyle we have in the Chicago suburbs?!
The attitude out west is "You want to earn enough to raise a family? You should have thought about that before you had kids".
It also seems to me that the people who have the most trouble with work/life balance in development jobs, at least out here, is that they are too afraid of saying "no".
> the people who have the most trouble with work/life balance in development jobs, at least out here, is that they are too afraid of saying "no"
absolutely true (at least in my case). I'd rather do that than end up on the other end, though. Without stronger protections for employees, I'll hold out for a stronger financial position on my own before I start negotiating hard about "work/life balance".
What I've noticed often with coworkers, and even myself at times, is that management often won't do anything to discourage your workaholic tendencies - but it was never actually an expectation in the first place - just a belief in the employee's head that it's what's required of them.
When I've been through such phases, once I realized that I could set reasonable expectations, it was never actually a big deal. Eventually I even started taking my vacation days, nervous that my job wouldn't be waiting for me when I got back, but that was really all in my head.
I once had to diagnose and fix a bug in a financial system that went belly up under extremely heavy load -- causing the company lose tens millions of $'s per hour (literally). Turned out to be a timing problem caused by satellite comms latency. The solution required us to modify how a couple different algorithmic worked. That situation was highly time sensitive and over-the-top stressful (for me anyway).
I'm sure you would acknowledge that's a very exceptional situation, right? That's the point of this whole subthread: that this kind of stress is exceptional in a work situation.
I would agree that it was exceptional. But I would also argue that how your people perform during exceptional situations is what makes or breaks teams and companies.
No one doubts that performing under pressure is important.
It's the idea that this kind of pressure can in any meaningful way be simulated (and the candidate's response adequately gauged) using the shticks and routines that people try to do in the current standard interview process that people take issue with.
I once spent 2 days troubleshooting a machine vision system at bolt factory. Physically in the factory. On my feet. Standing behind an active vibratory hopper filled with bolts, while stake-holders were losing money hand-over-fist, and angry machinists who looked like a motorcycle gang stood next to me. And it was a Windows NT machine.
Not quite all about algorithms, but that was part of it :-)
Yes, and I've set up a demo of an interactive TV system in a cupboard at a large London hotel (standing room only!)...
Also found that the probability of someone finding the porn in the demo by randomly pressing remote buttons pretty much approaches 1 as number of button presses approaches infinity...
The kinds of pressure are different - unless if at your organization you do your time-critical coding in front of a panel with varying mixes of what looks like disappointment, boredom, impatience and eagerness to "give you a hint" on how they would solve it while thoroughly confusing you. If not, you are measuring the wrong metric to gauge potential candidate success.
>Being a professional programmer is not an entirely stress-free job. Often, time matters and you have to think on your feet
Not once in my career had I had to fix a problem in an hour, let alone 10 minutes.
I have had senior people get mad at me when I couldn't give an answer during a meeting - that's the closest to an interview type scenario where you need the answer now. But even then, I did not stress that I'd lose my job, which is similar to the stress the candidate is facing.
Do you work on services that are expected to be working 24/7? It's not exactly uncommon for a production service to have problems and need to be fixed ASAP.
It's not exactly uncommon for a production service to have problems and need to be fixed ASAP.
Yeah, but if so it's usually of the form of "oh shit, forgot to chmod this little bash wrapper".
To the extent that it's of the form of "Solve this cute little dynamic programming problem I heard about from some company where everyone is like, gosh, oh so smart! In like, the next 5 minutes, k?" -- well, basically never.
Do most programming jobs expect that? I think not.
It's like interviewing a doctor who will be someone's primary care physician. Give him/her a set of symptoms, and fail him if he doesn't diagnose it inside of 10 minutes. And then justify it with the expectations in surgery or ER.
The stressful situations tend to be things like "We just broke the production database, we need to figure out how to recover the data ASAP"... not "We need a new algorithm in FIVE MINUTES!"
The interview question I was referring to is the appointment overlapping one. It's a middle school math question and it's a lot easier than failing over a database without data loss.
I've been doing this for 20 years and I'm not even sure where I'd start on your middle school math question. I hate working with calendars and dates and I don't think I know anyone who enjoys it and can write totally bug free code that takes care of all edge cases.
I'm sure good at fighting database fires though.
This probably is at the heart of the answer to the question "how could this programmer with such a long resume have botched this interview so badly?" It would be insane to believe they've never added value to any organization and have just been coasting along all this time. Maybe your interview sucks and isn't good at finding value.
>We just broke the production database, we need to figure out how to recover the data ASAP
I know you did not mean it this way, but in some ways that's even worse. If that type of thing were routine enough to merit asking every interviewee that question, I would seriously reconsider working there.
Armies train people by having them run obstacle courses with guns being fired all around them. Do a "realistic" interview, then, to really test how someone does "under pressure". Have them sitting alone in the room, and a screaming angry manager runs in yelling obscenities at them about how the production system is down, it's costing the company millions of dollars, and if they want to have a job they'd better get it fixed ASAP!
And have that same manager stand over their shoulder the whole time, yelling yet more obscenities. If the candidate doesn't get it fixed in, say, five minutes, then obviously they lack even the most basic qualifications to work as a programmer and you can reject them. Heck, save money and don't even do it on-site -- get their phone number and do it 3AM on a weekend, just like a real on-call situation!
Or... maybe the whole "under pressure" thing is just an excuse people use to cover for the fact that they like making people squirm, enjoy the feeling of power they have from knowing someone else's future is in their hands and that person knows it, and want to savor by making the trained monkey stand up and dance on command... or else.
Unfortunately, people who like the "under pressure" idea of interviewing seldom realize that sooner or later they're going to be the monkey and someone else will be the organ grinder.
It really depends on the job. stress in general is one thing but stress on a pedestal is another. some types of people(programmers fall into this category often) are not good at embarrassment so they shut down and can't think. it's not bad because they can be brilliant without the social pressure but with that they are not ideal. if the job doesn't have that requirement it's silly to drop them for it.
Being a professional programmer is not an entirely stress-free job.
Sure -- it's just the tenor (and for some people, sheer intensity) of the psychological stress experienced during interviews is, for many people, basically orthogonal to the stress of real-life work situations -- or even genuinely dangerous (even physically threatening) situations in life, otherwise.
With the latter, it's like "Oh shit - the client's gonna get real pissed if I don't figure something out real quick".† Or even: "That guy looks like he's about to lunge at me - I better think of something!" For which your brain and your glands have benefitted from millions of years of evolution in support of mechanisms for pumping just the right kind and amount of juice into your system to "figure something out".
But with interviews it's more like: "This person's evaluating me, using some hidden criteria. Given that the problem is slightly tricky, I literally don't know if they're expecting to power on at all costs, or, secretly, that I simply admit that I don't know where to start just yet. Not only that, something tells me he's not stating the problem quite correctly -- they do that, no all the time, but way too often in these kinds of interviews. And on top of that he's just being plain overbearing... and now he's starting to fiddle with his phone. On top of starting 15 minutes late. Like he never really wanted to talk to me in the first place. If I ask too many questions -- or even just one instance of the wrong kind of question -- I'm screwed, and gonna have to hit my inbox for leads again. Oh great, now he's starting to offer 'hints', completely derailing my flow of thought and whatever self confidence I thought I had. Fuck it -- I just should bail and go work on my personal projects. No one will be paying me $150k but at least I'll be learning something."
† Where "the client is gonna get real pissed" is roughly equivalent to "if I can't get these rocks to flake in just the right way, we aren't gonna have any more arrowheads and were' all gonna starve!", to a first order approximation.
Such kind of situations are very common where you are relatively new, handling software for a safety critical system and entire production line is shut down due to some exception occurring in large complex hard-real time multithreaded s/w module developed by some past ghost employee who has forgot to comment the code with no documentation available and the plant manager is banging your head for downtime loss!
Some developers are expected to work on the systems that processes a bajillion dollars of whatever per day and when it screws up they are often on the line for it.
I am not saying it is right, I am just saying at some shitty places it is.
Right or wrong, in some systems when something goes wrong, somebody dies. At some point, there's somebody on the line for that, whose responsibility it is to say "This code is good enough".
That's a high-pressure situation, so if you're hiring for that, it might make sense to interview under pressure.
> Right or wrong, in some systems when something goes wrong, somebody dies.
I have worked on systems that could cause operator death or disfigurement or damage... they are tested quite thoroughly in general and have reasonable failsafes and redundancy. It's not like they are coded on a whiteboard.
being on site at a customer facility while there is a ton of noise does stress you out a bit but most of the coding and testing is done in the office.
> That's a high-pressure situation, so if you're hiring for that, it might make sense to interview under pressure.
I think the jobs that have that kind of pressure are rare and interviewing like that should be the exception not the norm.
I agree. Most companies screw themselves with the technical interview by giving it. I give something simple like FizzBuzz and that's it. My big questions is: "What was one of your favorite projects and what did you do?" That will tell you everything I need to know.
The problem with giving technical interviews is you are testing for someone who is an extrovert that can bullshit under pressure. That's not what you want. You want someone who is smart and can solve problems with a compiler.
I have not interviewed many people yet, but already during one lunch (!) interview (where I don't ask any questions), a guy was so proudly talking about his achievements at his previous job in quite generic terms, that I've got an impression he was teached the whole story, rather than actually lived it.
Later he was not hired. According to (trusted) others in the interview loop he did not know how to do any basic shit.
But you could tell something was fishy by listening to him. You said you got the impression he taught the whole story rather than lived it. That's exactly what you are looking for; that's why it's so valuable. A real developer can tell when someone is bullshitting him in about 3 sentences.
Having said that, let me be clear. This isn't a good tool if all you have to do interviews is a manager. They probably won't be able to tell the difference, especially if they are just generic managers with little to no technical experience. They aren't the type you want giving technical interviews.
It's also much easier for introverts. They can talk about something that is
not themselves and something they know very well. They can now expose many
interesting and subtle details of their craft.
Do you think introverts don't like to talk and to brag?
Yes, this. Most introverts I've known will talk endlessly about stuff they like. Ask an introverted Star Wars geek about Star Wars. It's the meaningless smalltalk they have trouble with.
Ask an extrovert bullshitter who couldn't care less about Star Wars about Star Wars and you can easily tell the difference. (as long as you yourself aren't an extrovert bullshitter who couldn't care less about Star Wars)
I wonder how all those people unable to answer interview question passed school.
I don't think they are fraudsters, they are simply not too good programmers who can't solve simple problems by themselves. Many dudes believe themselves to have technical talent just for memorising done basis. That does bit imply problem solving ability.
I've had it happen - just in my past job search the past few weeks, I had a total blankout in my last Google interview session in person on a dynamic programming question, and I'm pretty sure that ended up being the reason why I got rejected as I felt pretty good about all 4 of my prior sessions.
I am about to start work as a senior engineer for Apple with 4 1/2 years of experience, after passing two back-to-back onsite interviews with them, and I hardly have studied specifically for technical interviews. I possess an MS in mathematics.
Don't presume anything about an individual just because the person happened to not answer a particular question - the person could be actually much smarter than you. It could have just been a bad day, or a number of factors.
I know it happens, but I don't think it happens to majority of people. Bad days are caled that way because they happen once in a while, not constantly. You had good three interviews and one bad at Google. You passed well at apple. That really sounds like bad day.
But then there are people for who practicaly any question beyond "lets talk in general about what you like and how passionate for technology you are" is unfair and causes black out entry single time. Thay is entirely different.
I disagree - different people could have dufferent triggers for a fight or flight response. For one of my best friends, anxiety is her trigger.
It is super important to try to ease a candidate into being comfortable to get the important information you need as an interviewer, as interviews are inherently stressful for candidates, and you almost never want to be testing a candidate's stress coping abilities.
I agree, but here the topic is simple question being considered unfair, because someone might be too stressed. I would argue that asking questions is not unfair level of stressing people.
It's not simply a matter of "asking questions". It's about getting asked (often gratuitously difficult)† in an intrinsically awkward and confrontational situation -- quite often by someone who not only might not have adequate social skills for the task; there's a good change they may not really know why they're asking that question of you in the first place.
"I dunno - they put me through this stuff, or some variant, on my way in. So now I guess it's my turn to dish it out on the people trying to climb in after me" seems to be about the order of reasoning in place behind these "methods".
† As in, was an open problem in the literature and/or folklore for years before some (now) highly respected came up with the first reasonably adequate (but like as not, overcomplicated and/out outright flawed, at the outset) solution. We know the "usual suspects" that get asked -- I don't need to list them here. But ff you genuinely think that any candidate you can (reasonably) expect to find in response to your muddled job postings will genuinely be able to solve these problems for you at the whiteboard for you -- from the void, as it were -- as opposed to regurgitate carefully practiced solutions they found from cobbling together lists of "problems Google and FB like to ask" -- you're seriously kidding yourself.
This thread is about calendar question - figure out whether two appointments overlap. That was not open problem for years and you should not need to memorize solution to solve it.
There is nothing to suggest that parent poster has bad social skills or that his job posting was muddled.
Observation after seeing countless schoolmates answer questions for grade. There were only few people that would be blacked out regularly no matter what age.
Yes, I have faced questions I could not answer. I did my best and that was it. That is however not blackout - that is me not knowing the answer. Blackout is when you temporary can't recall.
But then there are people for who practicaly any question beyond "lets talk in general about what you like and how passionate for technology you are" is unfair and causes black out entry single time. Thay is entirely different.
But that's the thing -- it literally takes just one person out of 5 or 6 to say "I don't know about this guy" to get the rest of the team to pass. No matter if he didn't seem all that well prepared or interested in you, you guys just didn't click, or you were exhausted because no one thought to let you get coffee or use the restroom.
When people are actively watching me to judge me, my brain just goes blank. It's happened to me almost every time in technical interviews where I was asked to solve a problem in front of the interviewers, and it's happened to me at school too in oral examinations. Written exams were not a problem.
This never happens in normal work, even when working under pressure with a deadline that has to be met and not enough time to make it.
It's just a completely different setting and purpose. In one case I'm solving a problem for the sake of being judged and that judgement may impact my whole life for the coming years. In the other case I'm solving a problem because there is a practical need for it and I'm just doing my job.
It has nothing to do with being a good programmer or not, it has nothing to do with my actual ability to solve a problem either.
Suffering from the same problem, though it happens to me even in written exams - doing something for the sole purpose of being judged makes me incredibly uncomfortable, and I'm happy to be out of school/university and just have a job. It's all just infinitely easier and less stressful, even at the worst of times and with the worst of people.
As you can see, roughly 25% of interviewees are consistent in their performance, but the rest are all over the place. And over a third of people with a high mean (>=3) technical performance bombed at least one interview.
Sounds like an effective filter to me. Where I work, this would be the first part of one of the interviews, with the second part being something more like "Given a list of calendar appointments, what is the maximum number which can be attended without conflicts?"
What I like about pklausler's example is that it allows for people to find edge cases without too much technical knowledge. If I have a candidate who doesn't ask about the inputs (e.g. "are the appointment sorted?"), I'd be wary. Engineers are often given vague specifications they need to clarify or account for.
If you want to test for the ability to gather requirements and clarifications from vague requests, then test for it directly, don't bake it in as a hidden test you expect people to account for when the overt problem is just implementing a comparatively crystal clear toy question even if you say things like "number" instead of "positive integer". Assuming they can implement anything that seems to work at all (which is your main goal, right? or why ask it?) you could turn your prior vagueness into an opportunity to see if they can formulate test cases and refactor their approach to account for different inputs, if needed, or if you see them accounting for them as they go you can ask e.g. "why are you taking the absolute value?" and see if they're thinking about the input order or if they're just doing it because that's what they saw somewhere.
Yeah, I think the important thing is that the candidate should not have to "read the interviewer's mind" when it comes to what style of question is being asked.
Unfortunately, this can also occur because the interviewer isn't clear on their own goals in the first place. They asked the question before really knowing what data points they want to come away with.
I don't think it's a bad question to ask... just not the filter that the op thinks it is. all these people who are sitting in the comfort of not being in an interview and they are still getting it wrong. this filter should be easy enough to get the question right if you know any programming at all. something like the fizzbuzz question.
I highly doubt I would ask if the inputs are sorted. I wouldn't expect them to be (why would they be, after all?), and I'd probably just give a solution that works regardless.
I agree. Also, since we're talking about two entries here, there really isn't much work to do...
One could even argue that relying on the order of the items in this case is going to result in a worse design overall (it's one additional thing the caller can get wrong).
It's actually a tricky problem to think clearly about unless you start enumerating the cases, or get pen and paper out to draw some boxes. I don't think it's completely trivial to verbalise. But I also don't think a competent programmer should fail to work it out.
I like the problem, and I'll probably use it in future :) It'll be a low bar for those times where you're getting the impression that a bigger task will be beyond the candidate, and you want to cut your losses early.
FWIW, I've seen similar complete failures to reason when applied to the even simpler problem of testing to see if a point is inside a rectangle. Some people seem to have a very underdeveloped one dimensional measure function in their brains.
It may be easier to verbalize than we think. I just realized that for me the trick might be to not be too abstract and formal when first thinking it out, but look at it more like an everyday problem.
Instead of this:
"Given two appointments, one that starts at time A and ends at time B and another that starts at time C and ends at time D, how can I tell if they conflict?"
More like this:
"I need to run another errand while I'm in town for the interview. I can either do it after the interview, or if I do it first, I'd better be done before the interview."
That gives me something concrete to think about so I can make sure I am on the right track and won't miss my interview! And from there it's a pretty easy path to working out the detailed formula. If I jump into the abstract description right away I'm a lot more likely to confuse myself.
I have similarly asked "write a function, minimum(), that takes a list of integers and returns the smallest integer in the given list" for quite some time. It's disturbingly effective.
I've always asked something that involved a loop, to ensure that candidates understood how to write a for loop.
(I have a variant of the above, a "more complicated" question, that involves maintaining two pointers/iterators; that removes another huge chuck of candidates…)
A decently clever candidate could sneak out of that first one without a loop. Something like
numbers.reduce((a,b) => Math.min(a,b))
would do it in JavaScript. In general, if a candidate realizes they can use reduce for that purpose, in my experience interviewing candidates they probably wouldn't have much trouble doing it with a loop, and it would usually be a signal they're going to have a pretty good interview.
Then again, you might run into a joker who has just memorized how to use reduce for finding the maximum or minimum element in a list of numbers.
I find that's a telling way to determine the experience of the interviewer. I'm saddened by the number of times an interviewer has asked me, "What is a reduce? How does it work?" Of course, that information isn't very helpful in the flow of an interview, it's mostly just upsetting.
As of yet, nobody has used reduce(). If they did, and especially if they followed it with a coherent explanation of what reduce does & how it worked (and convinced me they've not memorized reduce for a singular purpose, but understand it well enough to apply it generally), I'd definitely accept it.
If they can also write, or at least quickly approximate, the for-loop solution too, then I'd say I've gotten an excellent signal: not only can the candidate write a for loop, but he or she might also have some experience with a functional paradigm from somewhere.
Funny, I remember being blown away when somebody asked me this question on my first internship interview. Only later I read about FizzBuzz and became enlightened ;)
We used to ask people to right a function in C that converts an array of doubles from degrees to radians. It was amazing how many people had no idea and who had sailed through CV/resume screening, telephone interview, and 'technical discussion' part of the interview with ease.
If those people really "sailed" through your phone interview and technical discussion there is something very wrong with your phone interview format and technical discussion methods.
That's a good point, and I don't really understand what we were doing wrong.
I guess the candidates could 'talk the talk' when we were asking them questions on their CV, or general high-level questions on, say, threading or design patterns; but when it came to the crunch they couldn't write code.
Maybe the candidates were just good at generating CRUD applications and binding data to forms, and have rarely needed to process data. Not denigrating that aspect of software developement at all - it's just not what we need in our department.
Depending on what you're hiring for, it's really not all that depressing.
If someone has been doing maintenance programming in a company without excellent culture that values code quality - their brains start to rot pretty quickly.
Five years later, they know how to debug, estimate, work on a team, just not really develop anything from scratch or think critically.
If you want people to do real development, those are hard to come by. If what you really need is someone to maintain some bloated codebase and make it worse, but not too fast, then most people will do just fine.
Another thing is: what do you really want from a candidate? What led you to start asking them trivia questions in the first place?
The really good ones will be put off by trivia because it brings them zero value. If you ask questions that actually pertain to the field you're hiring for, it'll go over much better.
For example I applied to work at a major bank, and got asked a bunch of security questions, which exposed me not understanding how main in the middle attacks worked. The interviewee had requested that I go home, do a bit of research and email them the answer.
This brought them value because they found out that's an area I have little knowledge in, and it provided me with value because it pointed me in the right place to go research.
Trivia puzzles don't add value to anyone. Frankly if you're doing trivia and are upset by the response you're getting, a part of that is your fault :)
Making sense of his codebase is harder then writing from scratch. Maintenance programmIng requires a lot of puzzle solving. What it does not require is modern technology. E.g. maintenance programmer should answer this question easily and have problem it you ask about react.
You don't want to work with people who can't solve trivia like this. Something like man in the middle can be learned, basic problem solving takes time to develop.
TIL building products that make money (as opposed to pre-revenue VC-funded CRUD apps) with a team that enjoys their job and can be home by 4 every day is not "real development."
Not all teams that do what you suggest write garbage code as the GP implied. I have worked a places with large garbage and excellent code bases.
The places that have garbage and years of technical expect far less from their devs because they can get far less. These are also the places that prevent tickets for refactoring and never let devs pay down technical debt, then they get mad when development is slow. They value the next piece of "functionality", even if it as simple as new entry in a menu more than they value their future. When there is so much technical debt that adding that menu entry takes a skilled developer 60 hours this becomes the norm instead of a problem to solve as a business.
I would rather not hire a developer familiar with such situations and failing to fix them. Whether the failure was their ability to recognize or communicate the problem doesn't matter the problem existed and they were near it and it wasn't fixed. If I start having those problems I want people who aggressively deal with technical problems in my technical positions.
I can of course be persuaded to hire such a person if they explain what they did and they seem highly competent. Perhaps, they did do all the right things, did go above and beyond and the culture was still so toxic as to prevent progress, I have been there before. But the interviewer would need to convince me and I think that is the point of an interview.
Determining if two intervals overlap is not a trivia question but a trivial question for a programmer and hiring people who can't do better than O(n²) probably is good only for really boring maintenance projects where the workload lags far behind Moore's law.
I'm not necessarily saying that such things don't exist, but not my cup of tea.
> given the starting and ending times of two calendar appointments, determine whether or not they conflict.
Say the first appointment goes from a to b and the second goes from c to d. What does it look like if the appointments _don't_ conflict? This happens just when one appointment ends no later than the other begins; in other words, when b ≤ c or d ≤ a. So, the appointments conflict just when not(b ≤ c or d ≤ a). We can then distribute the negation using [De Morgan's laws](https://en.wikipedia.org/wiki/Negation#Distributivity) to arrive at this: the appointments conflict just when b > c and a > d.
Usually after a mathematical simplification like this, you can find a direct explanation for it. In this case you can reason:
If two appointments conflict, that means that there is a time when they are both active. Thus each of their end times are after both of their start times. Of course, each appointment ends after it started, so that just leaves that each appointment ends after the other started. So if the appointments are a to b and c to d, then they conflict iff b > c and d > a.
(I've corrected bumbledraven's mistake of a > d vs. d > a.)
I would say, if the transformation makes the code and the reasoning behind it simpler then do it. Otherwise, know that any decent optimizing compiler can do this trick by itself so what you write only influences readability.
This mistake could be made more "eyesoreous" and possibly avoided by naming the begin/end times b1, b2, e1, e2 instead of opaque letters. I would fire the OP for that alone :p
It's difficult to tell if GP miswrote, or you misunderstood, but it doesn't sound like they've made the mistake you're alluding to (I would expect them to be explicitly wrong).
Yeah, you have it right. I had a nagging feeling that two comparisons ought to be enough, and something was just reversed in bumbledraven's formula. My first thought was that the 'and' should have been an 'or', but that was wrong. It was the comparisons that were reversed, as you demonstrate.
Just to compare with the previous comments, if we put your notation back into the a-b c-d format, then it would be:
conflict = c < b and a < d
It's interesting to note how the choice of names makes such a difference. With the arbitrary names a, b, c, d for the four times, it's harder to think about whether the expression is right. Which was 'c' again?
Your names xb, xe, yb, ye are still terse, but once you know that x means one appointment and y means the other, and be and e mean beginning and end, it makes it much easier to think about it.
Your code has two comparisons; one to figure out which one starts first, and another to figure out whether the first one ends before the second one starts. This isn't getting your data correct; knowing which one comes first isn't part of the problem description :)
It appears what they're alluding to is this part:
> the appointments conflict just when b > c and a > d.
which I first understood to be a conversational statement rather than a statement of logic (which I assume GP is referring to), in which case it should be (b > c or a > d).
The most logical and clear answer for me (assuming I didn't already screw up by making assumptions about the data format, problem definition, etc.) is:
1. Figure out which appointment starts first
2. Check if first_appointment.end > second_appointment.start
So:
boolean AreAppointmentsConflicting(int start1, int start2, int end1, int end2) {
// first and second refer to the start time of the appointments.
// The first appointment is the one with the earlier start time.
int first_appointment_end, second_appointment_start;
if (start1 > start2) {
first_appointment_end = end2;
second_appointment_start = start1;
} else if (start1 < start2) {
first_appointment_end = end1;
second_appointment_start = start2;
} else { // same start time
return true;
}
return first_appointment_end > second_appointment_start;
}
Personally I find the first version a bit hard to follow, and the second one makes my head spin.
But I can understand the objection to the third version too. I don't think the problem is that the expression is too simple - simplicity is generally a good thing! - but that it's easier to reason about non-conflicting times instead of conflicting times:
If my other meeting ends by the time this one starts, we're good.
Or if this meeting ends by the time the other one starts, we're good.
Otherwise we have a conflict.
So now if you like the step-by-step approach, we can write a function that seems pretty straightforward and easy to understand:
boolean AreTimesCompatible( TimeRange thisRange, TimeRange thatRange ) {
if( thatRange.end <= thisRange.start ) {
return true; // that one ends by the time this one starts
}
if( thisRange.end <= thatRange.start ) {
return true; // this one ends by the time that one starts
}
return false; // they overlap
}
I think it reads fine as a single expression too, given an appropriate comment explaining the idea (which you'd want anyway):
// Time ranges are compatible if that one ends by the time this one
// starts, or if this one ends by the time that one starts.
// Otherwise they overlap.
boolean AreTimesCompatible( TimeRange thisRange, TimeRange thatRange ) {
return
thatRange.end <= thisRange.start ||
thisRange.end <= thatRange.start;
}
And here is the matching function to go with either of those:
The problem with interviews is that there is no time for false starts. When approaching a coding problem in real life, I pick a solution that seems to be right.
Half the time I pick a good solution and half the time I've rushed in and picked the wrong one.
If I have picked the wrong one, I know within 30 mins that it is a flawed approach, but have usually explored the problem sufficiently to pick a good solution. The interview unfortunately ends after 30 mins.
I should also add that I'm not much better at this after 13 years of professional development than I was when I left uni, when it comes to manipulating linked lists and arrays. My systems design is a lot better though.
But if you can't do the calendar question and realize within (lets be generous) 3 minutes that double nested loops are the wrong approach... I think it'd be fair to question your abilities.
Having had the chance to do some interviewing over the last few years I think the most important thing on my side is to know what I'm trying to test for with any particular line of questioning. I don't always see that level of self-awareness in fellow interviewers. (The worst is the sort who say "if they don't do X when I'm asking for Y, I'm going to score them down." Do they really care about Y then?) What exactly is gained by letting the candidate go off into the deep end for several minutes before they realize on their own, if they ever realize at all, that their initial approach was bad when it should be a simple question? If the purpose of a calendar question or fizzbuzz question (or my own initial coding question, "implement is_even") is to answer "can you code?" why does it matter if the solution isn't that great? If you have an answer to the question you can follow up with things like "can you code a better solution?" to distinguish passes, but interviewers should keep everything time boxed, there's other stuff to cover with such short time slots as 30-60 minutes. I like to test some sort of presence for knowledge about regexes and recognizing an application, so I borrowed Yegge's phone number regex question from his phone screen tips, and I'm happy enough if the person realizes that "there's some sort of pattern thing to do this" because that's a google away, happier if they can write a script that uses regexes correctly, happiest if they know or get close to the grep incantation, but if they start trying to write their own parser I'm going to stop them because that's going to take a lot longer than 10 minutes, especially if I say "oh yeah there's another number format we need to extract". But that person still might be a good hire, just not knowing about regexes at all. By keeping things time boxed I can make sure all the other areas I care about are covered and can judge if certain strengths can compensate for certain weaknesses.
Yeah, instead it's like: "Here's an interesting question that I like because I feel I already understand it well. Let's see what they do with it, and then I'll go with whatever gut feeling I end up with. This is easy, I'm a good interviewer."
Here's a tip: most live programming interview questions should be answerable within a few minutes. Any approach that you think will take a half hour is the wrong approach.
"Any approach that you think will take a half hour is the wrong approach."
Unless the interviewers haven't given much thought themselves. "Hey Joe, we have to interview a guy in 20 min. and I can't remember where are those damn interview questions. Gather up a few for me, will ya?"
My thoughts exactly. Defining the problem space and all possible cases is the key that so many people miss. Once you do that, the solution is just Boolean logic.
To have a good chat I would hope they drew a coordinate system, mapped both appointments in Euclidian space, and then did an intersect between vector A (first appointment) and vector B (second appointment) to see if there are any data points in common.
For a good discussion, instead of looking at the problem strictly programmatically, you could look at it as something you could map in vector space.
The dimensions of appointments are [startTime, endTime, location]. If you have points in one appointment that intersect with other appointments, then you have a collision.
This problem is solved with a couple of simple if statements. Finding a "solution" that is more complex than necessary or introduces knowledge that really isn't needed is the sign of a programmer who... over-engineers and is likely to be a detriment.
I assume that the question is meant to give insight into how they solve a problem that on the face of it looks straight forward?
It isn't though. First assume that all datetime stamps are in UTC, otherwise we have opened a can of worms that still trip experienced developers. Now draw a "timeline" and start enumerating the different cases. Then you can make a reasonable solution. But I would only expect this from experienced developers or people with a higher degree.
This is close but you need to ensure the start time is before the other ends, and test for the second one starting before the first also. There's four cases:
[appointment 1 start] [1 end] <-- some time --> [appointment 2 start] [2 end] (case 1 - no overlap, appointment 1 first)
[appointment 2 start] [2 end] <-- some time --> [appointment 1 start] [1 end] (case 4 - no overlap, appointment 2 first)
So you need to do:
if (appointment1.end > appointment2.start AND appointment1.start < appointment2.end) OR (appointment2.end > appointment1.start AND appointment2.start < appointment1.end) // conflict
a = Appointment 1 start
A = Appointment 1 end
b = Appointment 2 start
B = Appointment 2 end
The only predicates are: a < A, b < B
The complete set of orderings are thus:
aAbB - no overlap
bBaA - no overlap
abAB - partial overlap
baBA - partial overlap
abBA - complete overlap of one appointment inside the other
baAB - complete overlap of one appointment inside the other
> if appointment1.end > appointment2.start OR appointment2.end > appointment1.start // conflict
This actually isn't correct. Consider the events (0, 3) and (4, 6). The end of the second (6) comes after the beginning of the first (0), but they don't conflict. You want `and`, not `or`.
> Your cases don't consider [1 start][2 start][2 end][1 end] or the opposite [...]
Your notation there, where instead of a pair of start/end pairs you have a list of tagged times, reminds me of a good approach if one is doing a generalized version of the problem: given a list of N appointments, find conflicts.
Make a list of tagged times, where a tagged time is a triplet (time, 1, name) if appointment named "name" starts at time "time", and is (time, -1, name) if appointment named "name" ends at "time".
Sort the tagged time list with time ascending as the primary sort key, and the start/stop tag ascending as the secondary key.
Now to find conflicts you simply scan through the tagged times list, keeping a running total of the start/end tag values. If the running total is greater than 0 when you begin to process a given entry, that entry has a conflict with an earlier appointment, and the running total is how many earlier appointments it conflicts with.
As described above, this lets you print a list of what appointments have conflicts with earlier appointments, but it doesn't give an easy way to say which earlier appointments conflict. If you want to do that, it is straightforward. Just add a set data structure, and during the scan of tagged times add "name" to the set when you encounter an appointment's start, and remove "name" when you encounter an appointment's end. When you find a conflict, the set contains the names of all of the earlier appointments the present appointment conflicts with.
The above assumed that two appointments do not conflict if the ending time of the first is the same as the starting time of the second. If that should be counted as a conflict, just change the sort so that the secondary key is sorted descending instead of ascending.
True, I didn't include those cases as they are not unique in terms of why there is / isn't a conflict. But you're right, worth including for completion.
Does anyone really test for specifics like this? I thought the goal was to ensure the candidate understood that dates and times are abstract numbers, anyone that applies a mathematical operator should pass it. Yes this would still filter out a lot of people.
I'd say so. The "assuming time encoded"-bit is important though - I rather think starting with the data is valuable:
Can I assume the times are in a sane date format/datatype? If not, start with e1 = toSaneDateFormat(endtime1), s2 = toSaneDateFormat(startime2) (Fill in if interviewer is interested).
Then, as you say, a check for overlap is easy - but maybe one wants to be more fancy, like: if (timeDelta(e1, t2) < timeToWalkFromAtoB, or < 5 minutes -- they should be considered an overlap? If they are on different continents, maybe < 24 hours should be an overlap?
At any rate, I'm guessing (hoping) this leads to discussions about representing dates, and what the business logic is (eg: physical meetings - you can't teleport from one location to another).
[ed: And as others have touched on, if you deal with timestamps/raw number types - be careful that you don't end up with appointments in "wrong" order - I'd say a sort() aware of date-objects might be your friend here.
ed2: In fact, if you can assume a sane date-type, and timeDelta, you could probably assume an "interval" type, and simply ask for overlap?(appointment1, appointment2) ...
]
This is a great example of why the OPs question could be a good or terrible interview question -- it's not clear if they want the obvious technical solution (comparing datetimes) or a wider discussion about "what is a date time and how is the data represented", "what are the real world / business implications", "here is existing technology using intervals that will solve it" etc as you mentioned.
In my experience interviewers are usually looking for the technical solution despite the business oriented solution usually being much more applicable (and thus relevant) in the day to day role.
Key thing to remember here as an interview candidate is to clarify with the interviewer the scope of the question and the nature of the answer they're looking for. If for instance the interviewer starts with the simple technical solution and then probes the business aspects this might be a nicely rounded question.
My company asks a question during engineering interviews that is overly simple, but a bit vaguely defined on purpose. The main objective is to see if they can ask clarification questions to determine precise requirements, which is something that every engineer does daily on the job.
It works if you assume that appointment 1 starts before appointment 2 starts (or if you explicitly sort them by start time).
e.g. in J:
'a b c' =: 50 60 3 4;3 50 49 99;2 10 10 12 NB. 3 different sets of appointments
3 :'ok`nope{~0>*./-~//./:~_2]\ y' every a;b;c
┌──┬────┬──┐
│ok│nope│ok│
└──┴────┴──┘
I think many companies hire with the number one goal of reducing false positives. By definition this approach is going to unfairly reject a number of candidates. I would argue that it also dehumanizes a number of candidates, forcing them in aggregate to play a numbers game until they are in the top 20%-40% of the pool (if they ever get there) where companies then begin vying for them.
It is as you put: depressing as hell. And this is among white collared, educated, demographics. Imagine how it must feel to be an uneducated demographic in most other parts of the world...
> By definition this approach is going to unfairly reject a number of candidates.
This is only a problem if the interview/hiring/capitalism process is meant to be fair.
> Imagine how it must feel to be an uneducated demographic in most other parts of the world
The less privileged here certainly had jobs in HS and college where you just filled out an application, the manager made sure you weren't a convict or on drugs, and you got the job. The "uneducated demographic in most other parts of the world" is probably not solving algorithm quiz questions on a whiteboard.
> It's also a problem when those same companies want to bitch and whine about a "talent shortage" or a lack of diverse candidates
so much this. Why do companies get to receive all sorts of incentives to hire when candidates they reject walk into other great tech firms, make bank, and generate boatloads of value?
Maybe some should just pay more, too. There are plenty of firms just being too cheap to hire great talent, including some large, well-known ones.
How many operations can a modern CPU perform per second: A) Thousands, B) Millions, C) Billions
We'll accept C, and B with explanation. I'd say roughly 75% of the people I've asked (who have gotten through a phone interview) cannot answer it with any ability.
People whine about the difficulty of interviews, but honestly, almost everyone we've ever hired have said the interview was pretty straight forward, and nervousness is the biggest issue. Sucky people whine about reversing a linked list or finding a cycle or whatever.
I feel like that's a bad question to ask. An algorithm question at least lets you attempt it and you can see if they know things.
But this question isn't something that people normally talk about or think about. I think older engineers would think this is a normal question to ask since they/you have seen the evolution of computers over time, and have actually seen the number of operations changing to get into the billions.
But this kind of thing may only be mentioned in one sentence in an intro computer systems course, and most young people wouldn't care about how many operations a CPU can do.
They might not care, but in that case this question essentially tests if a person understands what 'GHz' means and can think logically, which is not that much to ask.
Why would web programmer think about processors and GHz is beyond me. There are jobs where it might matter, but for most of them it is completely irrelevant.
I know we can treat a lot of the technology we use as a black box, but not knowing even the basics of that technology indicates a lack of curiosity. I'd be shocked to find a competent programmer who couldn't answer the question.
A similar question: approximately how many IPv4 addresses are there?
See also: "Latency Numbers Every Programmer Should Know"
They might have been curious about different things then you. Or more interested in knowledge that helps build stuff ( still constantly learning, but choices are different).
When youre writing a complex SPA app and your performance is dragging on that cheap Android, it's nice to be able to reason about things like clock speed, memory usage, etc.
If they work in high level language that hides all that behind "number", who cares. How floating point numbers are represented is interesting trivia, but hardly useful in most situations. In general, I would expect people to remember things that are used often and be able to learn the rest fast (e.g. understand concepts and have enough knowledge to make further learning easy).
The rest is fluff and hidden cultural test: "Do you have the same history as I do?"
> But this kind of thing may only be mentioned in one sentence in an intro computer systems course, and most young people wouldn't care about how many operations a CPU can do.
TBH, I'm slightly disturbed by these "young people" who have completely no idea how machines actually work.
But the question is silly because there are better ways to ask people if they know in case you require that they know and you probably shouldn't be asking anything at all if you don't care if they know.
> TBH, I'm slightly disturbed by these "young people" who have completely no idea how machines actually work.
I agree with you here, but I would like to think if I were interviewing someone and they told me such, I would then ask something like "How would you go about finding this information out?", and continue down that line (I wouldn't just accept "I'd google it", I'd want something more in depth, even though that would technically be correct).
So you would be completely comfortable interviewing someone that claimed to have done 10 years of systems programming, including optimization, and yet when asked that question, just shrugged their shoulders and said, "I dunno"? Even if you asked them how fast a modern processor was and they still said, "I dunno"?
Personally, the question reads like "have you ever pieced-together a computer?" and one could argue that the question could weed out better candidates for certain positions. A growing number of younger engineers have only used machines that come glued-together, and never had to compare performance vs. price as they chose a CPU.`
When the hell would you ever need to know that? Do you ask carpenters how many times their screwdrivers spin per minute? It just seems like useless trivia.
Whether this is a good interview question I don't know, but:
> When the hell would you ever need to know that?
I find this such a strange perspective. You're writing code for a computer. Sometimes you need to estimate how quickly it should run, or else estimate how quickly it could run with optimal code. Surely it's obvious that knowing how fast your computer does stuff, at least within 3 orders of magnitude, is a necessary ingredient to make that estimate.
And yet in your mind that fundamental fact is "useless trivia." Very odd.
I see your point, but hardly anyone counts "operations" anymore. Besides, what even is an "operation" on a modern CPU? You could say, an operation is an entire CPU instruction, but the truth is that the instructions you see in assembly files are not really that atomic. So then do you count each microcode instruction as an "operation"?
But even then the question is impossible to answer, because depending on the type of workload your execution time will vary significantly. For example, straight up doing math with some registers will always be faster than reading/writing memory, and reading memory in a cache-friendly way will be faster than jumping all over the place, etc.
Anyway, my answer to the question would be, "a lot". You need to know the specifics of workload and cpu to be more precise.
The reason is that things today are "fast enough." These days most slowdowns aren't the result of the CPU not executing instructions fast enough. Other factors dominate, such as memory access patterns, network delays, and interfacing with other complex software such as databases.
Unless you are doing compute-heavy code, the speed of the CPU isn't much of a factor in estimating how fast the program will run.
I'm not infrequently surprised how people don't spot that something is orders of magnitude slower than it should be or pick the wrong architecture because they can't or won't do simple mental math to work out very roughly how long it should take to move some data around in memory, ssd or over the network or perform some simple computation on it.
I'm having trouble believing that people who think a CPU can do thousands of instructions per second will do well at this (or reasoning about the memory hierarchy).
I don't think there's much predictive power there. The people who are answering thousands clearly just haven't though about it before and are on the spot. Humans are just terrible with big numbers, and thousands sounds like a lot already.
You may as well ask any other sort of technical trivia question and figure the people that happen to carry around more random facts about tech are more likely to understand the bigger things that do matter. It isn't necessarily wrong it's a pretty obtuse way to make a judgment. Why not just ask them about the memory hierarchy or network delays or whatever directly?
Unless you are writing assembler, speed of your code is very distant of instructions. You don't count instructions when estimating speed. Not in higher level languages, not when working with database and definitely not in something like javascript that runs in browser.
My phone, and your phone too (possibly) is something like 1.2 GHz per core, with 4 cores; most phones have a similar spec (and those numbers are going up, too); basically figure 1-2 GHz per core, with 2-4 cores generally.
That said, when I started using computers, my first machine ran at 897 Khz on an 8-bit CPU, and had 16k of RAM. I was 11 years old, and this was a pretty standard machine for the time, unless you had real money (and even there, on the top end - not counting minicomputers or mainframes - you'd be lucky to break 8 MHz and a meg of RAM).
But I know I am of a different era. And honestly, I've stopped caring about CPU speeds too, because lately they don't change much (top end is about 4-5 GHz per core; servers can have around 32 cores - though that is increasing too).
What should be cared about is memory usage per process, and how the software you are using (or which multiple people are using) delegates that out. For instance, with PHP (not sure with PHP 7) you have one process per user, and depending on how much memory those processes take, will ultimately lead to an upper limit on the number of users that can be served at one time. In that case, knowing your memory usage and constraints of the server could be very important (there are a ton of other factors to consider as well, I know).
Well does it take about a second or about an hour to make one turn of the screw? If a carpenter doesn't know the answer to that in his bones, he won't be fastening many things together.
It takes significantly less than a second to turn a screw once. A couple orders of magnitude less actually, to give it some relation to the computer question.
Which really just demonstrates the point, I think. At some point things are "fast enough" that it just doesn't matter. We've reached that point with computers. Unless you are working in a niche field that needs serious compute, the sources of performance problems are almost never going to arise from issues like trying to execute too many add instructions in a given period. The delays will come from things that are significantly harder to see - network, database, or program architecture + runtime.
The carpenter may simply know that turning the screw is imperceptibly instant in his experience, and that if the bookshelf isn't getting built quickly, the bottleneck is virtually never because he's waiting on screws to be turned. He's going to have to make a trip to the store anyway so he isn't concerned with whether turning the screw requires a tenth or a thousandth of a second.
He's more focused on the design and craftsmanship of the bookshelf, because he's built many excellent bookshelves to industry standard effectiveness in the past and measuring the number of screws he can turn in a second hasn't been relevant to the work.
If he is good, he can reason about it on the spot. If he can't, I very much doubt that he can design anything excellent. That requires critical thinking to understand what it is being used for, what is good, and importantly what solutions are unsuitable for the problem he is trying to solve.
Number of nails as analogy for CPU operations? That's not hiring a programmer, that's hiring a computer.
What I mean is that -- thanks to all the programmers of yesteryear -- most programmers operate at a much higher level of abstraction when building anything that big.
Carpentry is far different than programming. But even so, and equivalent question I would ask a carpenter I wanted to hire would be, "How much hardwood flooring would I need to cover the rooms in my house?" If they answer, "I dunno" and then stare at me blankly, I'm certainly not going to hire them.
Apparently some people take whatever warm body shows up.
> Carpentry is far different than programming. But even so, and equivalent question I would ask a carpenter I wanted to hire would be, "How much hardwood flooring would I need to cover the rooms in my house?" If they answer, "I dunno" and then stare at me blankly, I'm certainly not going to hire them.
It would only be valid not to hire them if they have already taken measurements and noted them down. If they can't do the calculation to convert their measurements to square footage and then to linear feet of board (with margins to allow for different board widths) - that'd be something different.
Even there I would argue one could still say "I don't know", simply because you haven't specified how you want the flooring oriented per room/area (and if it goes on the bias, it gets tricky quick), or if there is any kind of special patterns or inlays you want, etc.
Until you have the full specification at hand, you can't really give more than a ballpark answer, which in the case of flooring calcs could be wildly off (agile doesn't really work for real-world engineering like it can for software).
And because of that the kinds of answer we would expect from such a carpenter in that situation is, "Hmm ... how big is the room and what size of board are you using? 2 inch, 3 inch, 5 inch, or so mix? That's pretty popular these days. How much extra do you want - I usually recommend 15% so you have some in case you need to repair."
Likewise, for the original question, I'd expect some sort of discussion or nuanced answer. Something like, "Well, most modern CPUs are rated at the GHz, so on the basic level, we can say on the order of billions of operations - but we're getting a lot more cores, and given SIMD and such, you could actually go an order of magnitude or two over that, in theory. But if you are doing something that takes lots of clock cycles, it could drop down into 100s of millions, I suppose."
What you don't want to hear is a deranged ranting, like some people are doing in this very thread, or "I dunno" and a blank stare.
> Likewise, for the original question, I'd expect some sort of discussion or nuanced answer. Something like, "Well, most modern CPUs are rated at the GHz, so on the basic level, we can say on the order of billions of operations - but we're getting a lot more cores, and given SIMD and such, you could actually go an order of magnitude or two over that, in theory. But if you are doing something that takes lots of clock cycles, it could drop down into 100s of millions, I suppose."
And again, none of that knowledge is relevant or required to be very competent at web development.
The equivalent question to a web developer would be how many lines of code would it take to make a bare bones site with a calculator in it? 1,000? 10,000?, 100,000? Options A and possibly B (with explanation would be acceptable).
Your question (although you don't seem to feel this way) is the equivalent of asking a carpenter: How many Watts of power will you consume while finishing this room? A carpenter who knows that may show lots of curiosity about their tools, but there are also plenty of skilled carpenters who don't know the answer to that.
Your interview question is more asking "How similar is this person to how I approach things?" than "How skilled is this person at doing their job?"
When carpenter will try to use toothed disc from circular saw on the handheld angle grinder(1) instead of abrasive disc and it will disintegrate at overspeed he'll know. Maybe it will be too late but he will, for sure.
(1) because "it is faster" and "my dad always did this" and "you don't pay for my saw, so shut up"
> When carpenter will try to use toothed disc from circular saw on the handheld angle grinder(1) instead of abrasive disc and it will disintegrate at overspeed he'll know. Maybe it will be too late but he will, for sure.
They do make such blades for angle grinders; they tend to be "universal" blades to cut wood, metal, and ceramic/brick. There are also "chain" blades, which are meant for high-speed carving of wood (they look like a chainsaw chain wrapped around a circular blade).
Likely, if you really wanted to do it and had nothing else handy, a cutoff blade would probably cut wood just fine (take care to watch for too much friction, though). Alternatively, a circle of file folder paper chucked in would work as well.
It's absolutely relevant. On more than one occations I've had performance issues land on my table with the developer that wrote the code saying "it's not that bad, it's going through 100.000 elements". They simply don't have a relation to how much a modern computer can do in a given timeframe.
Usually I can guide them to understand where the bottleneck is, but every so often I have to rewite it so performance is acceptable.
That's not the correct analogy, because the carpenter uses the screw driver as a tool, not as a platform. The screwdriver is analogous to code, not the CPU.
I would absolutely ask a carpenter how quickly he can complete a project, and I would hope he has a realistic first order approximation of how fast he can complete (process) screw driving tasks.
That said, I disagree with the question being discussed here, because I'd rather just ask him about his speed and performance; I wouldn't ask him how fast he can screw things in :) (that's a minute detail compared to the actual work).
You don't, but if you found that a candidate carpenter couldn't tell you whether they could fasten 10 or 10,000 or 10,000,000 screws in a one-hour period, you'd start to doubt their ability in general.
The question may be to asses tech-savvy-ness of the candidate (i.e. if he/she knows the SI prefixes, what the range of the modern CPU frequencies is and how do those values reflect on computing performance). There is one kind of programmers that learned their trade just to make a buck and don't care much about their working tools, and there is another kind that finds interest in computers in general. Interviewers may prefer the second kind.
Let's be real, if a roofer was asked anything comparable to a programming question it would be to provide an accurate approximation of the total number of roofing contracts completed globally within the last half-minute on the back of a coffee-stained napkin.
But that's not what's being asked by OP. Their question is rather simple, and software engineer should be able to answer it on autopilot, without even engaging her brain. As a hiring manager I would end the interview right there and then after the failure to answer something like this.
As an interviewee, I would roll my eyes at the ignorance of the interviewer.
This is the sort of question that reveals the ignorance of the person asking it. The correct answer is "yes". What is 'modern'? There are very modern embedded CPUs that operate in the low MHz range. How much power is being provided? A 'modern' CPU can be underclocked to ridiculous levels for power savings. What's an operation? Are we talking MOV AX, 1 or are we talking hashing a string?
It's the kind of question a dumb person asks thinking they're being quite clever.
Closely enough related to number of basic operations though I'd say. I'll agree with you if it really just is a multiple choice question without context, but the initial poster did not present it that way, but said that explanation/discussion matters. And then your objections are a good starting point for that.
The worst thing you realistically can do to stall your CPU is miss cache every time you read data from RAM. If you do this for every instruction (which would be quite a feat in itself), you divide your instruction throughput by about 200. But even then, and even on the shittiest modern CPU you'll be retiring millions of instructions per second.
Used that on college graduates. I was surprised how many couldn't answer or reason through it. Even the ones from top CS schools.
I also realized how different schools emphasized computer architecture differently for CS graduates. I remember having to design a simplified PDP-11 in Computer Architecture. We had to take assembly language and such. But that was one specific college and I shouldn't assume all of them do that.
Eventually I moved away from such questions and took a more collaborative approach such as "let's solve a problem together". So I'd stand beside them at a whiteboard and we think through problems. I think that puts candidates at ease and it reveals more of the skill and personality traits that were relevant for us.
Well...this questions seems to be OK for phone interview for entry level programmers who should know MIPS, CISC/ RISC architecture basics.
I would ask such questions to fresh graduate who is supposed to be working on firmware level stuff like writing custom co-operative multitasking schedulers, OS routines, device drivers etc.
Probably this type of question is not suitable for a web developers or Data analyst/ scientist
This question is trickier than it sounds. Sure 109 clock cycles per second, but estimating for actual human-perceived ops for an algorithmic problem one should use 106. (Source: USA Computing Olympiad problems.)
They mean 10^9 and 10^6, and that each "operation" in a complex algorithm is often something like a hash-table lookup, which may be constant time, but takes closer to 1000 clock cycles than 1.
We totally would interview someone that responded as you did. Thing is, I'd say roughly 50% of the people that applied for the position would respond with something like "I dunno" or "A" and be unable to have any sort of rational discussion about it.
It's telling that I can't even read a problem as ostensibly simple as this without wondering if there's some deceptive special case I haven't considered.
The funny part is I reckon you would struggle to answer the question yourself when put on the spot, if you had no prior experience of it. Just my opinion of course and I am speculating.
The solution is a simple predicate. Assuming both events are internally consistent (i.e. end time after beginning time) they won't overlap so long as the beginning of the first comes after the end of the second OR the beginning of the second comes after the end of the first.
Spending a week working beside an engineer (or seeing how they complete a substantial project) almost certainly provides a better measure of their abilities than watching them solve interview problems for 1 hour
Trial employment is expensive for the company.
[...]
Trial employment (and large take-home projects) are expensive for the candidate.
I can't help but think there's way to mitigate that expense among several (dozen) companies.
Triplebyte is already interviewing for other companies, why not set a low bar and hire everyone who passes it for a week? Charge your clients accordingly. If you have 25 clients hiring for overlapping skills, have them all pay to hire a person for a week.
40 hours of of labor / 25 clients = 1.6 hrs of labor per client, or about what it costs to do a single technical interview.
Meanwhile, the interviewee gets to do a single, focused project for a week, but effectively interviews with 25 companies!
I can get on Dice right now and find over 100 openings for python/java/golang/javascript/c++ engineers, certainly all of those companies would benefit from something like this.
More power to Triplebyte if they can figure out how to take those projects and turn it into a client deliverable on top of defraying interview costs.
If I'm already employed, it be weird to take a week off just to work for another company. Also ramp up time takes at least a day or two. This whole process seems troublesome for both the employee and employer
I recently went through a round of employment where I quit my job at the beginning.
Between updating my resume/social networks, brushing up on academic CS, finding leads, scheduling interviews and follow-up interviews and managing/negotiating offers, it was absolutely a full-time job.
I can't imagine finding a new programming job while still working at the old job.
I last switched jobs while working at Apple last October. Having the BATNA of your current employment is crucial to the negotiation process and I can't imagine forgoing that- if you have no current income that's an insane bargaining handicap.
Anyone with experience absolutely is not going to go for "quit your job, and maybe we'll give you a new one after a week, maybe it won't work out and you are boned"
I had a YC company that wanted me to do a trial week. They wanted me to quit my job when I said I couldn't take off a week of vacation.
When I said no, they wanted me to come out Friday through Monday and since the whole company works on the weekend, they would get 4 days to work with me.
Since it was in 2014 and I don't know if they still do this, I won't name them.
I guess the lesson learned is to ask what the interview process looks like before getting involved.
However for this company, I applied online, they sent me a InterviewStreet/HackerRank coding test, and only after I passed that did a recruiter call me, and tell me they wanted me onsite for a week.
>"However for this company, I applied online, they sent me a InterviewStreet/HackerRank coding test, and only after I passed that did a recruiter call me"
This is a huge red flag in my opinion and I would recommend people not agree to this. Why? Because it shows complete disregard for the candidate. "Pass a test and you can speak to an actual human being." Its demeaning. It also shows just how useless many recruiters have become. Part of the job of a recruiter's job and good ones do this, is to get a candidate excited about interviewing with the company and get the preliminary deal breaker questions out of the way to see if it even makes sense to proceed.
And for me that was a perfect interview. First quick question by email to see if I was interested, then some simple test to see if I can really program, then quick interview to see if I have required domain knowledge (all questions were about knowledge required to program effectively, not abstract "how to move mount fuji"). For an introvert programmer like me it's a perfect interview schedule. Also it helps when you are already working and want to check conditions in other company without risk of being thrown out from your current job.
I gave up on those the last time I wasted 4 hours of my life on one of those tests and never even got a rejection email. It wasn't a hard test and I didn't do badly.
Nowadays I just point them at my github. If a body of open source isn't enough to get an interview I'm not interested in working there.
Agreed. My experience is that recruiters are pretty flakey people(and I'm being charitable in that) - they regularly fail to keep scheduled calls, fail to follow up after asking you for some times to chat, take weeks or even months to respond resume submissions for jobs they are posting etc.
I have no problem with competency testing provided I have already spoken to someone on the team and established contact and registered interest with someone besides a recruiter.
I just finished working for a YC company that not only demanded a two week trial period, but after doing that trial period instead kept me on a contract billed for eight hour days but then insisted I must be in the office from 9 - 6:30 (their "engineering hours"). They wanted me to work close to 50 hours a week for no health insurance while underpaying hours and forcing me to attend all company events including weekend "hackathons" (haha so fun). It was a nightmare and I'm glad to be out of it.
The irony is that it was a company that prides itself on giving people stable jobs and healthcare.
Not only that, working for a company like Apple, you aren't allowed to write any code unless its been approved by the appropriate people...that just wouldn't work.
Why would it be a bargaining handicap unless you're running out of money (i.e. desperate)? If you're a strong enough candidate to land an offer at a top firm, it isn't worth it for them to low-ball you and risk spending more resources looking for strong candidates. Besides, if you can get an offer at Company X, you can probably get an offer at one of their competitors as well (which is your leverage).
Can probably get an offer is different from currently working at one of their competitors. It's a) a vote of confidence from another firm that this person is worth hiring b) an anchor point for your salary above where they would normally start the negotiations (yes even for "above average"). It removes all the guesswork of "can probable get an offer". You have one. Right now.
Additionally I've had negotiations stretch on for months. That isn't very comfortable with no income, and is an absolutely enourmous opportunity cost.
>Why would it be a bargaining handicap unless you're running out of money (i.e. desperate)? If you're a strong enough candidate to land an offer at a top firm
The more specialized you are the fewer jobs there are out there that match your skill set. Not every job market is as liquid as that of, say, junior java developers.
Rejecting this job might mean waiting another month or two for another to come along.
Avoiding months of unemployment also isn't just about the hit to your savings it's also about the hole on your CV.
This is silly. Your BATNA can be the amount a competing company is willing to pay you in another offer.
If you lack confidence that you'll be able to find at least another two job offers in a timeframe that makes you comfortable, then I agree don't quit your job.
Anyone with experience shouldn't lack that confidence though.
I'm not wealthy enough to wait for a better offer indefinitely, and the places I was applying to are for all intents and purposes. Negotiating with only X months of runway is very different.
Your argument also assumes that I have a competing offer already when negotiating, but how did I get that competing offer? If you have a job, that solves the chicken and egg problem. If you don't, you don't have the leverage to anchor that first offer, which anchors the second, etc.
Having done both at similar skill levels, I can tell you the outcomes are much better with a job in hand.
> When did you last switch jobs? I recently went through a round of employment where I quit my job at the beginning.
The tone of this implies that lining up a new job without first quitting is outdated and negative. From the other side, quitting before having a new position can look irresponsible.
I have never quit a job without another lined up and have done quite nicely, myself. Why ever invest in trashy projects when one can get good jobs quickly and easily?
I spent a year not working and had no trouble lining up dozens of interviews when I started looking. However, it did take several months before (a) my interview game was up to par, and (b) I found a company I actually wanted to work for.
What did you do for the year off? I've always believed that tech is one of the most generous industries for this sort of "resume gap" of a year+ but if the question comes up I don't think most people would think highly of answers like "sleep" or "video games", even though more socially acceptable answers like "travel" aren't all that different... I wonder how much it varies from tech company to company. Last time I did interviewing I had an older guy ask about my GPA, and a few wondered what I was up to in 2013 when I had a year off my resume (finishing off school but that doesn't answer what the summer was spent doing, which wasn't much of note).
Generally I told people that I had done a tiny bit of contract work (true) and had been working on my own project (somewhat true, although it never got past the conceptual stage). There were a couple other things, which I won't elaborate on for anonymity's sake, but they were not programming related at all. Even on the projects, interviewers never really dug deep into them.
I suppose sleep and videogames aren't great answers. Taking time off to travel or explore some other interest is almost certainly fine in SV.
Ultimately, I think most places are so hard up to find qualified candidates that as long as you pass the interview and don't come off as a total slacker, you're probably fine. But if you're career-minded and applying to a place that has their career tracks worked out (read, not most startups), you probably want to give that impression to your future engineering manager.
Theres no way I would quit my current job before having another job lined up, if I didn't need to. I do agree that looking for a new opportunity is like a full time job, but when you are already employed the necessity is not as great. I can take my time over months rather than try to treat it like a 9 - 5.
That seems like an enormous risk. I've in the past spent upwards of 6+ months looking for work, and plenty more people have spent much longer. Given Bay Area expenses, if I quit my income, the first thing I'd have to do is temporarily move somewhere cheaper until I found something. Contrary to all the "shortage of engineers" stories, tech jobs do not, in fact, grow on trees.
Doesn't work when you are on a visa, unfortunately. But even if you could, I still think you wouldn't need to quit before you interview, best case may be a couple of weeks off for preparing.
> Between updating my resume/social networks, brushing up on academic CS, finding leads, scheduling interviews and follow-up interviews and managing/negotiating offers, it was absolutely a full-time job.
That is ridiculous, you must have incredibly bad time management skills. Or do you actually think this is very common?
When I first got out of college in '08, it didn't take this kind of effort to get hired. At my previous job, it was also fairly easy - but hiring has changed quite a bit in the last 3-5 years.
I had a company demand I do two phone interviews, plus an onsite, 2 time zones away, for a $50/hr, temporary contract with no health insurance. Obviously, I politely declined to continue, but companies wouldn't be doing that if it wasn't working on some candidates.
>"Between updating my resume/social networks, brushing up on academic CS, finding leads, scheduling interviews and follow-up interviews and managing/negotiating offers, it was absolutely a full-time job."
Can you break down how much time you spent on each of those tasks that they took up the equivalent of an entire 8 or 9 hour work day 5 days a week?
I think you might be in the minority with your outlook. Most people opt to keep their paycheck and health insurance and vacation time until they find something new. Not least those with families. Also its much easier to negotiate a higher salary using your existing salary as a starting point.
Morning:
1-2 hours: Study a chapter of CLRS Algos book
1-2 hours: HackerRank
1-2 hours: Studying trivia of technology X
Afternoon was all about sales - updating social networks, filling out applications, talking to recruiters on the phone, scheduling interviews, etc. I probably applied to about 250-300 companies.
I made tweaks as I went - I found that recruiters preferred to talk in the morning, so I eventually inverted the whole thing. I started to sniff out which companies were serious about hiring and which perpetually advertise for talent
This is just a rough framework. Sometimes I'd spend the whole morning on CLRS, or a tricky Hacker Rank problem, other times I'd spend the whole day interviewing.
Before I spoke with anyone at a company, I always did research on them, the company, the company's market, and the technologies they were interviewing for.
>" I started to sniff out which companies were serious about hiring and which perpetually advertise for talent"
Would you be able to share how you sniffed them out or what techniques worked for you?
In my opinion this is one of the largest time sinks. Companies that aren't really hiring.
I see this repeatedly on the HN "Who's Hiring" thread. Companies just perpetually advertise the same roles and very often these are the same companies who seem to have no problem wasting other's people time with flakey recruiters or ghosting or just never responding to candidates. I would love to know if there is a commonality you found?
I also wish there were a better way to share experiences regarding these perpetual time wasters, something akin to hosts respond percentage on AirBnB. And I personally don't consider Glassdoor to be a very good experience or trustworthy outlet.
We often hear about the shortage of talent. And while I don't doubt there is an amount of shortage, I am often left wondering what percentage of this are companies completely broken hiring process. I also wonder whether these companies are even aware of how broken their process and their recruiters are.
I've done this for nearly every job in the past. However, since moving to the Bay Area, I would never consider quitting my job just to look for another. As one commenter below said, you put yourself at a disadvantage when you're bargaining for compensation.
I can agree that it's pretty difficult to find a new job while still working. However, most companies let you work from home nowadays. You can just interview during that time. Is it ethical? Who cares? It's business; the nature of the beast.
Experiences differ, I guess. I have twice looked for a job while I didn't have one, and I found it to be way, way less than a full-time activity. Updating my resume, posting it to a handful of job sites, monitoring a handful of job sites for new job postings, handling recruiter calls and screenings, just didn't take all that much time. It was maybe a couple of hours per day.
> it be weird to take a week off just to work for another company
It's not even weird, it's just downright insane. No person should be expected to essentially work for free for a week without any guarantees they will get anything out of it.
Actually, I'd really be interested in knowing if there's some list of employers like that so someone in a position to take such an offer can rotate through good prospects like that.
It also doesn't work for people who want to interview speculatively. Looking at what else is around once in a while is a pretty decent due-diligence that you can apply to your career. You can even be honest about this with recruiters. "I'm not sure that I want to change jobs right now, but I'm open to persuasion."
If trial weeks become commonplace, it starts looking like a form of structural lock-in.
This is why I heavily push to talk to nearly everyone on teams at the prospective company that I might be a good fit for. I spend 3-4 hours talking to various people over the course of 3-4 weeks. If the company doesn't allow me to talk to their employees, then I pass them up.
IMO, trial employment works because interviewer gets to spend a week with the candidate personally to get a feeling of how they approach and solve problems. Having Triplebyte do that without the interviewer being there to work with the interviewee on something, then it wouldn't be any different from an hour long interview
> Meanwhile, the interviewee gets to do a single, focused project for a week, but effectively interviews with 25 companies!
Isn't this basically what bootcamps are about? (at least from a job seeker's perspective)
In practice, only those without jobs have the time to attend one... and if one isn't actively working in the field, then 2-3 weeks might be better than 1 week.
That's an interesting idea! The hard part would be convincing companies to trust an external trial week fully (part of what's great about a trial week is the chance to actually see how an engineer will interact with your team / your problems). But I like the idea!
It's true that a company would not be able to gain a "feel" for working with a candidate, but those feelings probably help contribute to noise as much allowing interviewers to ask their pet questions.
Surely a company could objectively learn a great deal about a candidate by looking at a week's worth of git commits and evaluating the final product for correctness/maintainability/optimization.
But still, taking TOO much of the humanity out of hiring ignores the fact that ultimately, a person has to work with other people, so you're right that it's not perfect.
Lately, I've been asking "given the starting and ending times of two calendar appointments, determine whether or not they conflict." No loops, no fancy algorithms, no tricks... and asking it has not been a waste of time. I get people writing doubly-nested loops over all of the seconds in the two intervals, comparing for equality; I get multi-line predicates full of redundancy that still yield false positives and negatives; it's depressing as hell.