Think about time invested in the purchase of an automobile or a house, relative to the cash outlay. Consider how one can get information and predictability around that purchase, as well as the known knowns and unknown unknowns.
For a new job from the individual's point of view, think of the life-event risk they're taking on by betting on this new firm.
From the firm point of view, particularly for smaller firms (1 - 50), think of the return on equity and opportunity cost.
Finally, think about the time spent dating before people move in together, not even get married.
On a time per commitment cost / risk-adjusted basis, extensive job interviews may still be underinvesting.
All that said, a majority of candidates can be filtered out within 15 minutes. As could, if you care, a majority of workplaces.
See also “information asymmetry” and “adverse selection” resulting in disproportionate number of lemons on the market as discussed in “The Market for Lemons: Quality Uncertainty and the Market Mechanism”: https://en.wikipedia.org/wiki/The_Market_for_Lemons
It doesn’t matter how many hundreds of rounds of interviews and checks you have, you will always run into Bayes Error.
You will never be able to filter out assholes who can hold it together for an interview. Or lazy people who get hired and rest and vest.
The solution is not to create a hellish interview pipeline that actually competent people will just say no to. The answer is to accept firing people if they’re a bad fit early, with appropriate severance.
And going further, it would also be nice to normalize "dating around" where a candidate and firms could learn a bit about each other while if it's not a fit, the candidate can continue where they are.
If we can do parental leave, we should be able to manage life-change leave.
Granted, the logistics, IP, confidentiality, and many other things feel incredibly complicated to sort out. And yet firms work with consultants running around talking to all their competitors, and the world doesn't end.
At the same time, keeping people in roles that aren't satisfying for either party makes little pragmatic or personal fulfillment sense, yet most of employment law seems oriented for that.
Given the asymmetric stakes, seems worth figuring out ways we could prioritize humans over firms.
> And going further, it would also be nice to normalize "dating around" where a candidate and firms could learn a bit about each other while if it's not a fit, the candidate can continue where they are.
Job fairs, mate. That's the idea. Chat to a manager and an HR person, learn about the org, and maybe slip them a resume. 5 min of face time with a candidate or an org can be enough to tell you what you need to know.
Though heavily centralized around schools, there are definitely non-school related ones out there, too.
> All that said, a majority of candidates can be filtered out within 15 minutes
If I interviewed six candidates, usually one would obviously be head and shoulders above the other five. If I interviewed twelve, two would be. I saw this across various companies over the years. About 15% clearly know more than the other 85%.
Also I found I usually could tell this within three questions. If I asked three questions, and the person being interviewed either stumbled over some of the first three, or had a shallow understanding of the topics, I never saw them recover afterward - if they had no or a shallow understanding on the first three questions, so it would be on subsequent questions. I could have wrapped it up after the third question for most people. Once I became aware of this, I still gave them a chance (which never bore fruit), but I began thinking how fast could I wrap up an interview where they had come in without seeming impolite.
>Think about time invested in the purchase of an automobile or a house, relative to the cash outlay.
That's the time invested by ther party paying the money. They can spend all the time in the world on that (and they are usually the ones that do).
Where the owners spend their time is making the property attractive to the buyer.
The owners aren't doing labor for customers.
And you surely don't get to borrow a car for the weekend from the dealership, or live in a house that you want to buy for a bit.
>For a new job from the individual's point of view, think of the life-event risk they're taking on by betting on this new firm.
The life-event risk of being able to pay rent/mortgage/bills? Oh my.
Employment contracts aren't binding either way. Employees can quit at any time and can be fired at any time.
Lateral promotion is a more likely scenario than in-company promotion. Think about how that factors into opportunity cost.
>Finally, think about the time spent dating before people move in together, not even get married.
That's called having a relationship, something that's a two sided thing.
The game isn't one side doing labor for the other, and so the comparison is unjustified.
(If yours does, you're not having a relationship, you're being used. Run.)
>On a time per commitment cost / risk-adjusted basis, extensive job interviews may still be underinvesting.
On the employer's side, perhaps. Many of them aren't doing due diligence.
You'd think that spending multiple days on an interview process would involve someone at a FAANG-level company asking a question like Do we actually have any projects that utilize the skills that make this candidate attractive to us?, but in my experience, this is not always the case, by far.
>All that said, a majority of candidates can be filtered out within 15 minutes. As could, if you care, a majority of workplaces.
Applicants usually have no problem filtering out the workplaces. Selecting between multiple job offers is a good problem to have.
Without an offer, there's nothing to filter.
>See also “information asymmetry” and “adverse selection” resulting in disproportionate number of lemons on the market as discussed in “The Market for Lemons: Quality Uncertainty and the Market Mechanism”: https://en.wikipedia.org/wiki/The_Market_for_Lemons
The whole thing is premised on buyers (employers, in our case) being uninformed and having no clue about what they're paying money for.
Which is exactly the problem here.
And tech interviews getting out of control is a symptom of the problem, not a solution.
> The whole thing is premised on buyers (employers, in our case) being uninformed and having no clue about what they're paying money for. Which is exactly the problem here.
> And tech interviews getting out of control is a symptom of the problem, not a solution.
Agree with both of these. "Contentless management" is the worst.
I see I expressed myself poorly when making comparisons to other events either side or both sides invest time to learn information, since both my statements and your responses seem correct to me.
Indeed, your statements aren't inherently incorrect. That's the danger with analogies: without additional structure, they make it easy to get different readings out of the same text.
Safe use of an analogy "A is like B" would have the following:
* Specifying exactly which parts of concept A are matched to which parts of concept B;
* Specifying the limits of the analogy;
* Having some examples of how A and B manifest or behave in the same way;
* Justify the analogy with an argument showing why you can expect A and B to behave in the same manner.
If you skip a step here, you're counting on that step being blatantly clear to the reader — but that's often far from being the case when we are talking about complex concepts that prompt the use of analogies in the first place.
(For a nostalgic moment, recall the infamous car analogies on Slashdot, where they became a running gag).
I've also seen many cases of using analogies to justify awful opinions with bad faith arguments, e.g. A key that opens many locks is a master key....
Which isn't to say that analogies are bad, but that using them without extra scaffolding (in the context of making a point) is like skipping steps in writing a proof: justified when the skipped parts can be unambiguously inferred by the reader and routinely done for conciseness, but is also a trait of mistake-ridden proofs produced either by cheats, or people who simply didn't think the whole thing through.
I'm not talking about the poetic use of analogies here, where the goal of using them is to evoke an emotion or feeling. And like in the case of false proofs, the conclusion of an argument made with an unclear analogy isn't necessarily incorrect; it's the argument itself that has an issue.
Using an analogy without going into details means that the author expects the reader to make a leap of faith (and swallow that analogy without thinking much, trusting that the author has done the thinking that analogy is truly fitting) — or the author is making a leap of faith themselves, expecting the reader to do due diligence and think through the steps. There's a level of trust and delegation of thinking in both cases that's too high for my taste.
After all, the entire point of using an analogy is saying "you can understand A by understanding B". But to truly understand why that's the case, one needs to understand both A and B, as well as the connection between them.
This is good when one is giving an in-depth exposition, or introduce a new concept to the reader (giving them an idea about what to anticipate or what to look for), but defies the point when you're trying to simplify or make a case that A is like B in a certain way.
The argument then becomes circular: A is like B in a certain way because A is like B.
(For another nostalgic moment, recall that the Internet is just a series of tubes, and not a truck you can just dump something on).
That's why I generally try to avoid using analogies to make a point (..and, of course, fail, as you can see here).
In our case, I felt that the extent (if any) to which your analogies apply to job-seekers is far smaller than the extent to which they apply to employers in this situation, but the expression didn't make it apparent.
> “After years of tech workers being pampered, of ‘bring your whole selves to work’ and ‘work from anywhere,’ executives are now overcompensating in the other direction,” he says.
> “Tech industry job interviews have, of late, reached a new level of absurdity.”
This is funny. I wonder if with lay offs a whole bunch of people are finally realizing how abusive the tech interview is. Ive done 3 job searches and each one has been horrible, leaving me multiple times considering switching careers.
The one I just finished at the end of last year didnt feel any different process or expectation wise as the one I did 6 years ago. The only difference was it felt like there were less openings and more competition. But the actual interview it self was the same, just as horrible as it has been.
I used to give interviews for a team I got promoted multiple times with, I couldn't pass the interview they were having me give. They didn't change it though.
> Another worker complained on Blind that preparing for LeetCode questions requires “hundreds of hours” of preparation: “Why are we expected to do the coding Olympics for every company that wants to interview you?”
Cracking the coding interview came out in 2008. 14 years ago, none of this is new.
For perspective, applying for a coding job 30 years ago used to involve ONE phone interview that lasted no more than an hour, followed within a week by an in-person visit at the site. In contrast today's insanely laborious interview process sounds like undergoing the Spanish Inquisition.
Before the rise of FAANGs, the interview visit consumed between 1-2 hours (if it was a car drive away) and no more than one day (if a plane ride) with absolutely no homework. In-person, you talked to between 3 and 8 people. At most onerous, the discussion might involve a little pseudocode or drawing diagrams on a white board to show you possessed the skills most prized back then -- fluency in design concepts, the ability to focus and reason well, to communicate ably, and to think on your feet. Syntax skills were presumed given that you had a degree in CS and a history of not being fired from previous jobs. References were checked which also filtered out the boobs, so testing your your code fluency was overkill. Multiple rounds of phone interviews were rare; multiple visits happened NEVER.
Apparently these days, your academic and professional track record and references count for zero. Instead, you must show you can generate code at high speed -- as if you were a newb grad who likely might turn out to be able only to pass true/false tests in the classroom.
Do degrees and references now count for so little? Must the number of interviewers exceed double digits? If so, THAT's a broken system.
Most schools still teach CS, but most the industry needs SWE. So the degree isn't an indicator you know how to build products as much as it is you can't stick out a 4yr program and do Big O notation.
For perspective, thirty years ago programming was a career for motivated dorks and weirdos and didn't interest normal people, computers were so underpowered that simply getting it to do something implied much more competence than it does today, and software industry salaries weren't insanely overinflated so there were fewer unqualified applicants. The hiring situation thirty years ago doesn't seem that relevant to today.
oh yes. i ask one advanced question when i interview. something like "what's the difference between git rebase and git pull" -- if they know you're good to go. the other route I take is to have a candidate walk me through some code they have, if they don't have any code then i don't hire them. period.
Cuz, I use git gui and I switch to cli like a once a month at best, so I dont really remember the commands nor see the value in putting effort into it
It feels like people fixated on git details think everyone has the same work flow as they do, so for them it feels like git cli proficiency is really needed.
It is like asking about vsCode shortcuts (it'd probably be even more useful, since you spend more time in your editor)
Id really prefer being asked about algos, compilers, web dev, system design, whatever heavily software related (even religious topics like SOLID) than boring tools which can be used in various ways
> so I dont really remember the commands nor see the value in putting effort into it
curiosity? knowing everything you can about the world around you? having used what is possibly the most critical piece of software for working with other people that you encountered some rare exception to common workflows that required you to learn more about the plumbing?
> It is like asking about vsCode shortcuts (it'd probably be even more useful, since you spend more time in your editor)
My editor isn't vscode, so vscode shortcuts wouldn't be helpful to me, the interviever. But again, it's about ability to work with others, the demonstration that you understand systems that you could get away without knowing. You're right, you can be productive while understanding nothing about git, that doesn't mean you're good, or competent, just productive. I don't want to hire people who can write thousands of lines of code, I want to hire people who can do the same in just 100 lines.
> than boring tools which can be used in various ways
that's really what it comes down to isn't it. It's not interesting to you so you don't want to invest the time in learning it because it's boring. I doubt anyone would agree knowing fewer things is better, so I cant help but read this as sharpening my ax is boring, so I just don't do it.
> > so I dont really remember the commands nor see the value in putting effort into it
> curiosity? knowing everything you can about the world around you?
There is far more out there to learn than I have time and energy to learn. "Here's something you can learn" does not even begin to reach the bar of "I should learn this".
> having used what is possibly the most critical piece of software for working with other people that you encountered some rare exception to common workflows that required you to learn more about the plumbing?
With one exception, everywhere I have worked has not used git. The one exception used it for one or two years. I know more about four other version control systems than I do about git.
And, since you're talking about learning to use the most critical piece of software for working with other people, and chewing out the GP for not wanting to invest the time... why don't you begin your sentences with capital letters? Written English is one of the most critical pieces of, not software exactly, but at least "tech", for working with other people.
You're right not starting with capital letters really detracted from my point and made it much harder for you to understand my meaning and intent. I'm sorry you had to endure that struggle.
But I'll disagree that English is that important to working with others. I believe that you're confusing English, with being able to communicate ideas and intent.
that's a fair point but i valud people who value the cli over guis. not that you can't use a gui but its much better to know what its doing under the hood.
>its much better to know what its doing under the hood.
I agree when it comes to programming langs, libs, compilers and in general computers. Because knowledge of those things significantly affects your output (code)
But git? I treat it the same way I treat email client, power point or chat app used at work.
Hell, I could probably benefit more from high power point skills than high git skills.
I believe his point is you're part of the issue with interviewing as well. People design arbitrary trivia for people to answer and won't hire unless their workflow overlaps yours.
For example, someone is hiring a chef for their restaurant:
Q: "What is the difference between X local priduce supplier and Y local produce supplier?"
A:"Where I work we had an exclusive relationship with X supplier so we never used Y supplier."
Q: "Hmm ok, tell me the last fancy meal you cooked at home."
A:"I spend all day cooking for my job. At home my spouse does the cooking because they really enjoy it."
Q:"Ok thanks no hire."
A:"In an executive chef with great credentials and experience. Do you want to ask me about and evaluate me on my actual job?"
Q:" No thanks. I want someone who has the exact same experiences as I do. And I once spent a long time evaluating suppliers and found a better one. And I'm single so do all the cooking at home."
And overall I don't mean to isolate you, but every time I see someone say they don't have extreme coding questions, they instead fall back to using the most non-representative arbitrary signals for decision making.
I have a busy life. I don't really code outside of work any more. I do woodworking or something else. The newest code you'll see from me is probably when I tried to make a game using Roblox just for fun for the kids. That's been a while. I don't have a github account and that's on purpose. I don't do open source work any longer and the most recent you'll find is probably 20 years old.
Code from work? Not gonna show that to you or you're not gonna hire me because I break NDAs ;)
Personally I do like the git one tho. Even if you use a GUI (unless it renames things it really shouldn't) would allow someone to answer what the conceptual differences are between pulling and rebasing!
FWIW: pull is a combination of fetch+merge, so not a rebase at all. They can be similar, in case your pull and rebase both happen to result in a simple fast-forward operation, which is literally just "moving a label" (or in 'real' terms, changing a commit hash inside one file in the .git directory).
If someone has never used git, they probably used <somethingElse>. I would hope they're witty enough to ask the interviewer back: "I dunno, never used git, we use Rational ClearCase. Can you tell me what the difference is between a reserved and unreserved checkout and when would you use each?"
Probably not in an interview situation, especially if they need the job, but would be fun!
Just coz I don't code for fun any longer, what tells you I don't solve problems on my own (both at work or at home)? Getting into woodworking required a lot of figuring out new stuff, including the part of actually doing something with my hands. It was particularly fun because it was new and needed figuring out. Figuring out why the heck the last distro upgrade decided to not be able to find my LVM volumes on software RAID and I thought I had lost all my data was also a fun problem to solve. It required zero code. But it required a lot of debugging and interpreting things I don't know the actual implemtation details of. Something I see a lot of devs being bad at. Fixing bugs. I.e. investigating unknowns.
> "I dunno, never used git, we use Rational ClearCase. Can you tell me what the difference is between a reserved and unreserved checkout and when would you use each?"
No, because having "grown up" using git, I can't even imagine using something as insane as the model that ClearCase has decided to go with :D
> Probably not in an interview situation, especially if they need the job, but would be fun!
I'd hope you'd be able to, maybe not quite the way you asked it, but having a conversation where you can demonstrate expertise, even if it's not my expertise or favorite is the goal of the original question. (if asked by me)
> Just coz I don't code for fun any longer, what tells you I don't solve problems on my own (both at work or at home)?
Your answer obviously. Saying "I don't write code for fun" would instantly drop you into the do not hire category for me. But saying "I don't really write code in my spare time anymore like I did when I was younger, I can't really talk it too much detail about [work project], but I can discuss this personal project from years ago. But these days I'm using all my spare personal time getting good at wood working, that's now accounting for my debugging time"
Knowing a bit about wood working, I'd ask so many questions about that. Because for me, wanting to build things, and being interested in getting better at the stuff your building is the signal I'm looking for. Which, as you've hinted to is a big part of what woodworking is. Giving that answer, is also likely put you higher into the clear hire category for me, because it would show that you're able to get good at anything you want to.
You don't understand the rational behind that. If you'd kept reading, you'd have learned that talking about woodworking would easily put you into the hire category.
No, because having "grown up" using git, I can't even imagine using something as insane as the model that ClearCase has decided to go with :D
Let's reverse things: If I was interviewing you and you gave me that answer when I asked about ClearCase, that would squarely put you in the no-hire bucket ;) "Young guy that just refuses to even try to think for himself, instead of making some guesses based on non-perfect information and assumptions, which he will clearly label as such." That's a really big one I look for. Labelling assumptions.
having a conversation where you can demonstrate expertise, even if it's not my expertise or favorite is the goal of the original question
Ah, so then, without Googling :D, what's the answer to the ClearCase question? And yes I'd love to have a conversation (in an interview situation) about what's good and bad about how ClearCase does it after I tell you vs. what git does.
Also FWIW, the original commenter made it seem like he asks these questions in the way we've heard many interviewers ask them. You either know the exact answer, almost word for word, that they expect to their trivia question or you're out.
Saying "I don't write code for fun" would instantly drop you into the do not hire category for me
If I really needed the job I'd probably try to be less 'feisty' in my answer but if I was just casually looking and you asked me that question, the paragraph about woodworking and the almost data loss might have been exactly what I would say as a "reverse interview question" so to speak, to see if you are stuck on your one exact way of thinking or if you can appreciate that everyone's situation is not the exact same and you adjust.
E.g. if you insist that coding for fun after work is the only correct answer, I know we'll not get along and even if I get hired after all, it won't be fun. You'll probably have/come up with your one way of how things have to be (done) but I have my own. I can't stand micro-management, I can't stand having to rush something because someone else screwed up and sat on something that was known for months and then they come to you and basically say "I need this, I need this done this way and I need it 'yesterday'", I can't stand being judged by just a bunch of numbers like "how many hours of coding do you get done outside of work" (interview) or "how many PRs per day do you merge" (work) by someone that literally knows nothing about me except these numbers.
I also like to do this, and I think it's absolutely wonderful for having a conversation. I've never seen a downside to this and I've never had anyone who didn't have something they wanted to share.
I think it's a fair question. I would never not hire someone over not knowing that particular flow though.
Also, I've never had any developers I've hired not be able to learn it quickly. The fact that they don't know it does tell you that they're either not rebasing or not using the cli. The discussion around those process topics are more interesting to me than them not knowing it to begin with. For example, "well what is your process around git usage in general?" etc, "how well do you know the cli?" etc. Interviews are all about conversations.
I would tell them they'll learn the cli git if they join my team. Maybe that's not something they're into? I guess that's part of the "fit" of a team.
At one point there was lots of discussion regarding rebasing in general on our team and another shop. This blog post came out of that. I know many people who feel differently of course. I do expect seniors to have an opinion on the matter either way I guess.
In general, trivia questions are not great, and this is trivia. A candidate may come from an environment where the policy was to merge instead of rebase, and so they might not even be aware of what rebase does.
Thats so strange to me. I work with git every day and don’t use rebase. If you asked me in the interview I’d fail that. But if you asked me that question in real life I’d give you the answer in 30 seconds after looking at the documentation, and everything would carry on without a hitch.
I get what you are saying about this being easily available information. However, an interviewer might still view this simple test as demonstrating a character flaw.
Rebase is a very basic and common command available in a tool you use every day. That you both don't ever use it and don't know how it works might signal to the interviewer a lack of curiosity. They may think you tend to dismiss options without really considering them in favour of what is familiar.
> Rebase is a very basic and common command available in a tool you use every day.
That says a lot about you, not the people you are interviewing. Not everyone uses or trusts rebase workflows. I think --first-parent is a far better "basic and common command argument" and better makes use of the power of git's DAG. I have it in some of my default gitconfig files. Can you tell me without looking it up what is --first-parent and when and how you would use it? Some of the teams I've been on could. Others are happy with their (in my considered opinion, hideous) rebase or squash workflows. It's an aesthetic choice as much as a "right" choice to know one workflow over the others. [0] We all have our own workflows and most of us can learn new ones when we join a new team.
[0] Barring of course that rebase/squash hides merge conflict resolutions under the rug and trying to reverse engineer mistakes in them is a nightmare, and there's a deep dark rabbit hole from there into darker nightmares like rerere caches. I'm happy to claim that learning DAG traversal tools is not just aesthetically better but objectively safer, especially with junior developers around, but you don't have to take my word for it so let's call it just an "aesthetic choice" to stay on good terms.
I work with too many tools to sit there and memorize the implementation of each of their functions should I be questioned. Either way, its a wasted effort memorizing that considering its all documented should I need to use it. I’ve probably read what was written on rebase at least once by now but I don’t work in shared repos and keep things pretty organized so I don’t need to use it.
Documentation is easy to read after you’ve read enough of it like any other technical writing. It only takes a moment to consult it and know the ground truth.
No one said anything about the implementation of the function. Not understanding what rebase is and does would imply not understanding how git actually works.
For example you mentioned that you know what git pull does. Are you aware that depending on the settings it is either doing a merge or a rebase? I also suspect that is the answer the OP was angling at.
To me we are getting a bit away from the point and going into semantics. My point is and was that being tested on easily reference-able knowledge you are able to look up on the job to no penalty is a waste of everyone’s time, in contrast to the gp who stated failing such test in hiring would lead to perhaps not getting the job on account of it.
But shouldn’t you use rebase? E.g. if you’re developing a new feature on a central repository, and a bunch of commits happen to the repository in the meantime, wouldn’t it be best practice to do a rebase before you push your own commits to the repository?
If there's no merge conflicts, then the end result is the same whether or not a rebase is done before merging. If there's unit tests involved, though, then CI should perform a rebase before running the test suite though.
Yes. Say you git clone a repository, and over the course of some months add a new feature. If you do a rebase then push, then it will appear in the history as if you had done a clone of the most recent version of the repository, done all your commits, and then pushed your changes to the main repository. Otherwise, the history will have merge commits in it where your commits to your local repository are merged with commits that were pushed to the public repository after you cloned your local repository.
Its probably more complex then I'm ready to explain in a comment section. But its useful when you are working on your own branch (IDK why you wouldn't be?) and need to integrate recent merges from the master branch on to your own branch.
> I don't really use it but from what I remember... also here's a lot of details about the steps that go into the porcelain command git pull.
I don't use VS code but I know the difference between the command palette and the sidebar file explorer and could answer a bunch of questions about it.
I think the point of the question is to filter out people who aren't curious. Which isn't perfect for the ability of a job candidate to be successful, but does happen to have an incredibly strong correlation.
>>I think the point of the question is to filter out people who aren't curious.
I think you're actually filtering on people that are curious about the same things you are. Learning things because you're curious is pretty much a 'free-time' activity. Tech is huge, and with all the stuff to learn - I guarantee I'd learn algorithms and data structures over most other stuff...
That doesn't mean I don't like learn, just that I like to learn different stuff from you... As others have pointed out, its easy enough to check the docs for command line tools
> I think you're actually filtering on people that are curious about the same things you are. Learning things because you're curious is pretty much a 'free-time' activity. Tech is huge, and with all the stuff to learn - I guarantee I'd learn algorithms and data structures over most other stuff...
You're right, by the very nature of asking questions that I can think up, I am filtering for a shared knowledge set... But that's kinda the point. There needs to be some shared knowledge set. The person I want to hire needs to be able to talk about more than just data structures. And, unless you've invented one of your own, to me, that seems nothing but rote memorization?
How many data structures have you memorized? 1 a week for the past 2 years? and in those last two years, you never used git enough to figure out how to rewrite a commit, nor have an opinion about if you should or shouldn't?
> That doesn't mean I don't like learn, just that I like to learn different stuff from you... As others have pointed out, its easy enough to check the docs for command line tools
again, for the same reason above, I can look up documentation myself, I don't want to hire someone really good at reading documentation, I need someone who can think, and solve new novel problems... Another of my favorite questions to ask is "what's the first thing you'd do once you found out you were living in a zombie apocalypse?" Nothing to do about tech, but it's a great question to dig into how someone thinks, and if they're able to solve problems they weren't expecting. Just like any interview question worth asking, there's no one right answer. Sure it's great you've memorized every single data structure that exists, and the list of uses that are approved in some text book. But I can read too, that's not impressive, and not a sign of someone who I'd enjoy working with.
Do you want me to be curious about git or what we are actually doing on the job though? Maybe its different for software engineers where the job is to build tools over use tools. I analyze data, a tool user mainly, and thats where my curiosity is more focused perhaps, also what I am paid for ultimately.
> Do you want me to be curious about git or what we are actually doing on the job though?
I want you to be curious about everything. I have no expectation that you'll know everything, but the desire to know everything in the order in which you choose is a critical quality of engineers that I'm able to respect.
> I analyze data, a tool user mainly, and thats where my curiosity is more focused perhaps, also what I am paid for ultimately.
Sure, but then why argue about curiosity of a tool you're not likely to encounter, but every single software engineer worth working with has? I don't know enough about data analysis to know what the corresponding tool would be. The closest I could come up with is excel, and I know enough to know that's definitely not it :D
I'm a technical lead on a project that uses git and frankly I have no idea off the top of my head. And yeah same I could just look it up if I needed to.
It is a simple matter of having current and relevant knowledge for the role. Would I hire a junior developer who didn't know much or even anything about using git? Probably. Would I question the seniority of a so-called senior developer who didn't know the basic usages of the most dominant source control tool for the past 15 years? Absolutely.
If they had a good explanation for that gap in knowledge, like working for the past 20 years somewhere that was stuck in legacy code and running on SVN, I'd definitely take that into consideration. I might still want to be certain this candidate is smart enough to quickly pivot into a new codebase and new tools. I've met many people who struggle with exactly that kind of change which is exactly why they don't keep their knowledge current.
I'll admit that asking people how git works isn't a question I would ask in an interview. Playing devil's advocate though, I would probably not hire someone claiming to be a senior developer who doesn't know how git works.
Maybe I think that the user experience of Git sucks balls and have no desire to learn it at any level beyond the bare minimum. Maybe I use better systems like Mercurial or Perforce or anything designed more recently than the last 20 years. Maybe I think that Github is a pox upon the planet and their promulgation of the One True Workflow(tm) (pull requests) is an abomination brought about by technical architecture limitations of Github.
I use Git only because other people force me to use Git. Otherwise, I use something better.
I mean that's certainly an opinion, but I'm not sure I'd be confident hiring someone into a company that uses a tool that the candidate hates so passionately.
Also Git and Mercurial are about the same age and less than 20 years old. Perforce is far older than both of them.
The tech you use to get code to production is so broad, asking these kinds of questions is at best a random chance of successfully hiring a good engineer. You may as well flip a coin.
A better approach is to ask a candidate something specific about their experience. Even if someone mentions “git expert” on their resume, the question is not what you proposed but instead asking about their experience and digging in from where they go. An engineer you’re interviewing may have fixed a bug in “git push” but not know anything about how “pull” or “rebase” works.
> Now interviewees are regularly given projects described as requiring just two to three hours that instead take days of work.
Not to disparage the subjects, but it sounds like these applicants failed the interview. If a qualified candidate is meant to complete the project in 2-3 hours and it's taking over a day, then that candidate isn't passing this test of productivity.
However, companies absolutely should be time-limiting their problems. Precisely because people could use more time than others and generate false positives.
It feels like another variation of the Halting Problem. If it is easy to objectively determine how long completing a test project is then it probably isn't Turing Complete or a good test of programming skill, is it?
Time limits encourage quick and dirty solutions, often with much emphasis on the dirty, and discourage candidates with carefully thought out solutions or other "senior engineer" habits like TDD or i18n or a11y or documentation or… The list goes on and if the whole point of the exercise is to gauge someone's experience level the more experience they've accumulated the harder they have to "paint within the lines" of your arbitrary time limit.
The point of making something a habit is that you do it every time whether "it needs it or not" because you never know when that documentation will be useful and if you document everything you are more likely to document the things you really need.
If your interview processes aren't interested in me at my most habitual then you are also directly sending me a signal that your culture doesn't care about i18n/a11y/documentation/tests/…. You are only as good as your sloppiest code and you are interviewing for sloppy code.
Ah, to have unlimited time and or options. "Screen the company" is pretty sad advice for most people who have no choices. I must have misunderstood your point.
It's always a two-way process whether we like it or not. Some of the companies I've hit time limits on or got ghosted in feedback processes after a greatly asymmetric amount of labor in interview processes (I've never yet met a company putting a commensurate amount of labor into their interview responses than what they've asked for from candidates) could greatly use my skills. They aren't actually interviewing for my skills. I can't help but see that as a failure on their part. Not because I'm particularly great (I've got plenty of imposter syndrome to deal with, sorry), but because their interviews are particularly shit and they are absolutely saying in their choices of interview that they aren't hiring for skilled labor, they are hiring for bottom of the barrel, quick/dirty/disgusting talent and they don't care who knows it.
Technical interviews aren't about finding skills, they are about finding people with too much labor on their hands skilled or not. They are about finding people willing to do bad solutions quickly just to pass a test, not about if they have any actual skills at writing good production code.
We don't have a standardized test for "good production code" so we keep using a bunch of terrible half-assed semi-problems to approximate it, then adding timers on top because arbitrary deadlines are the only thing we know as an industry for how to get work "done".
We aren't testing for what we actually want and we don't know how (and we can't afford to actually pay for the labor involved so that the answers aren't just half-assed AI solutions), so let's keep testing half-assed shit and maybe we'll get "good" candidates, maybe.~
I think the tests select exactly what the c suite wants - people with credentials. The more, and fancier, the better. Some of the bias is conscious, but most probably isn't.
How do I schedule 2-3 hours right away after you send me a task?
I tell people to do it over the weekend and don’t really count the time.
Code solution can be bad and if someone returns bad code after he was able to pick his time. Well.
Some people refuse to do 1-2hr take home task, I also thank them for the time. Some people take 2 weeks and then I usually have someone who did task last weekend so I pick one that did it earlier.
Some people do it right away after getting task I schedule 2nd round also asap for them.
You see I don’t have to limit time just pick candidates that are interested enough to do the task.
Also sometimes most productive employees are worst. We had a guy that was so productive refactoring BS in code that he took down month or two months of work of the team.
The timer starts when the problem is revealed. That's how it worked at a company I previously interviewed at. They sent me a link to a page that explained the 3 hour time limit once the prompt is revealed. I had I think two weeks to choose when to start the problem. It was a totally automated interview
Companies are notoriously bad at determining how long software development will take, hence the entirety of Jira et al. How accurate do you think their "2-3 hours" estimate really is?
These take homes are also only one of the many ridiculous asks made of candidates. I've seen "Talk for an hour about a project you've worked on," as one step in the process.
[Edit]
Let me tell you, their estimates are not accurate. Just like the job descriptions, they throw a bunch of stuff in and see what they like.
If the actually set a time limit, they would notice the vast majority of candidates failing. I took a test like this for a job application once, I had 180 minutes for a task that took an hour to actually implement, and I spent another 30 minutes testing.
Of course, but this is take home with a completely unenforceable time limit. Well, you can enforce it to some extent as someone mentioned. If you give the test friday and say two days, and they turn it in a week later, they've obviously blown the limit.
No, the time limit is enforced. The way it worked when I took this kind of problem is that the company sent me a link to a web page that explained how the 3 hour timer would start when I viewed the prompt. I could choose to view the prompt whenever I wanted, within the next two weeks.
I entered my solution in a leet code sort of editor. Presumably it would lock me out if I didn't submit within 3 hours of viewing the prompt.
We're starting to go in circles, but here's your quote with the preceding sentence, emphasis mine. You're discussing an online test, not really a take home as described in the article.
> Take-home coding tests used to be rare, deployed only if an employer needed to be further convinced. Now interviewees are regularly given projects described as requiring just two to three hours that instead take days of work.
[Edit]
They should probably call it a "take home project" to be more accurate. It can include front and back end code, tests, documentation, design, styling, etc. etc. "2-3 hours," yea right.
What's the difference between a "take home coding test" and an "online test"? As far as I can tell, these are functionally identical perhaps save for the submission mechanism.
Explain to the candidate that there will be a 3 hour time limit enforced once the prompt is revealed. Close submission 3 hours after the candidate chooses to reveal the prompt. This could easily be done in GitHub, if the submission mechanism is pushing updates to the company's repo. Voila, you have enforced a 3 hour time limit on your "take home coding test".
For a new job from the individual's point of view, think of the life-event risk they're taking on by betting on this new firm.
From the firm point of view, particularly for smaller firms (1 - 50), think of the return on equity and opportunity cost.
Finally, think about the time spent dating before people move in together, not even get married.
On a time per commitment cost / risk-adjusted basis, extensive job interviews may still be underinvesting.
All that said, a majority of candidates can be filtered out within 15 minutes. As could, if you care, a majority of workplaces.
See also “information asymmetry” and “adverse selection” resulting in disproportionate number of lemons on the market as discussed in “The Market for Lemons: Quality Uncertainty and the Market Mechanism”: https://en.wikipedia.org/wiki/The_Market_for_Lemons