What I learned about interviewing
lanie.dev
lanie.dev
---------------------
Homework assignments and personality quizzes won’t give you excellence
This year I was once again hiring junior level developers, and the same dynamic was at work, but I got a surprising reaction from the person I spoke to. I’ll call her Zareen, who had just come through the Grace Hopper program.
Zareen had been interviewing at a few different places, but I assumed she was still open to hearing about the specific job that I was hiring for, so we arranged a phone call. We chatted for 15 minutes, and then I suggested she should come by the office and meet the whole team. She was just absolutely stunned.
"Wow, I didn't expect things to move this fast!" she exclaimed.
Let's think about that for a minute. She wants a job, I might want to hire her, I ask her to come by the office for an interview, and so she is stunned. It says a lot about how broken our hiring processes have become if what used to be the absolutely boring, dull, and standard process now provokes the response, "Wow, I didn't expect things to move this fast!"
Apparently other companies were giving her homework assignments and personality quizzes and phone interviews. “Please go to this website and take this test, we are trying to figure out what your skills are.”
At two other companies, she had already done 20 minute interviews, but never with anyone on the tech team. Instead she got a call from someone in the HR department, who read a checklist of words, which the HR person did not understand, but they were all requirements: “Have you ever heard of HTML? Do you know how to use that? What about CSS? Do you have that? How many years of skill do you have with CSS? And Java? I mean, Javascript? Are those different? Yes? Okay, I think we want Javascript. Do you have that? Yes? How many years?”
What an empty ritual; reading words that are not understood.
I can see how she'd be so excited because it implies she's getting hired or is very close to getting hired, while the invitation to interview is just a standard hiring event.
Did you hire her? If not, the meeting before the interview wasted everyone's time.
It helps dramatically in determining the level of the person (junior, intermediate, senior, etc.). The level is subjective to the company, that's why it's important: definition of senior at one company is very different from the other. Notice that a coding challenge without a technical chat first is kind of useless though. Various strong developers would just write the shortest code to complete the challenge, instead of trying to show off, so you have to read between the lines.
A cool thing about this is that you can have an idea of the level of interest of the candidate.
Finally, isn't everything just signal? The entire goal is just to have many conversations so that by the end of it, we have a rough idea if we like each other and can work together.
The last time I looked for a job I was presented with multiple "take-home" coding challenges. I had to spend hours on them each night after working my regular job. It was exhausting. I would send it off and either receive no feedback at all, a "thanks but no thanks" with no constructive feedback, or an invitation... to come in for a whiteboard algorithms red/black tree interview.
Ultimately I got a job that had a traditional (sucky) interview process.
These coding assignments are a disrespectful waste of time.
You can spend 4 hours on them and perhaps nobody will even take a single look at it, they just gave it to you because why not.
They’re also (IMO) pretty low signal because you could cheat on them easily.
Meanwhile a phone interview (even if algorithms) takes only 60m or less and shows the company is at least invested enough in you as a candidate to have somebody spend that time with you. Cheating is definitely still possible, but harder and more awkward. It just seems better overall.
And yes, when applying for a job it's the worst. I also have no solution. Removing it would mean making the "full day with the team" even longer and more stressful (I'd rather do less live coding than more).
Yes it can be cheated, but that would come up in the full day interview (it did happen), so it's irrelevant, there are multiple filters on purpose, however each filter is more expensive for the company or the candidate and balancing between the two is important.
That's also why I think a chat with a developer is important to have as early as possible.
That's the reason I advise against them.
Unless you are the top company in your bracket, your completion rate will also not be so great for a take-home (people have limited time: they'll sort by how good your company is). Sure they'll do Google's take-home but local business that does local comp/prevailing wages? It's at the bottom of the pile. By the time they get to it, the best candidates will already have an offer from a better company.
That's why I prefer to bring people on-site as soon as possible, and do a little whiteboard (the point being that the candidate must... know how to code!). It's an artificial challenge that's really a pretext to have a technical discussion.
Only time I advise to use take-homes is when you are dealing with a massive number of applicants from institutions that have a poor signal to noise ratio. Bootcamps come to mind. But then you end up with candidates that have the homework done by someone else and it ends up not being a good filter either.
I spent hours on the challenge. They never even bothered to call or email and tell me "Nope." After that... well, f*** them.
Sounds reasonable in general and especially if indeed the resulting code will be seen with constructive and qualified eyes, or better yet, a feedback on it will be given back to the candidate.
In contrast to that, too often there is too little meaning to creating such a hurdle, when it's just a gauge for discipline and compliance. This is especially true of junior devs, who still have tons of doubts and need direction and good examples to follow.
Wastefulness at interview stage may be an indicator of wastefulness of internal culture. Imagine a surprise of a new hire, who would readily jump into the new assignment ... just to later discover that it was shelved, or worse, was given just to keep him/her busy and "get used to the process".
I think you get the "coding challenge kind of code" with varying degrees of the subject's personal flavor on it. People can and will produce different kind of code in a different setting, or if you just ask them to do so. So it might not tell you as much as you think?
EDIT: Virtually every employer / project I've worked on has had completely different requirements for what the code should be like. And my own style(s) for my own projects is again completely different. There's no "here's the kind of code I produce", but "what kind of code would you like?". And it's ok not to get it right in the first sitting, these things are discussed and they evolve internally in reviews, style guidelines, meetings, etc.
> A cool thing about this is that you can have an idea of the level of interest of the candidate.
Towards what? The coding challenge? The long overdue neo-legacy project you're going to hand them? Just having a job?
How does that interest show?
> Finally, isn't everything just signal?
The signal doesn't necessarily say what you think it says. That's the biggest issue I find in all these hiring threads. If you do such and such, you suck. Good candidates do this and that. I wouldn't hire someone who X. The best candidates Y. Bla bla, yada yada, on and on. I feel like there's an immense amount of assumptions that hold.. in the interviewer's mental image of the ideal candidate / stereotypical poor candidate. In reality it smells like prejudice and "no true scotsman" all over, at least when taken with the limited context we're given.
And my anecdote is that the signal is very often wrong. This comes mainly from helping out newbies and/or joining educational groups. Many times the first impressions mislead: I can't help but think "this dude has no clue" and I'm almost ready to write them off as a hopeless case. But give them a few weeks and many of them turn out to be very competent, fast learners, good thinkers. It's easy to underappreciate how diverse people.
Good point. The hiring process I work on is definitely not objective though and I don't expect to be able to have an objective process. I expect to have a subjective process (yes, it's driven by people) but have people on the job we are happy to work with (not necessary excellent). Striving for the best candidate is great, but I have no idea what to do to achieve that, I'm working on it. Referrals are a great way, but that resource is used extensively already, there is a need for also the other funnel (lot of hiring needed), there aren't enough people in just referrals.
> How does that interest show?
In various ways, as I said, I think being subjective is the only way to manage a coding challenge, is not an objective measurement by any mean. Sometimes it's clearly a showcase (this part is too easy, I don't care, but you should really look at this small snippet), sometimes is "this is way too easy, here is an 80 lines script to do it efficiently, you don't need anything else", sometimes is a widely designed system for the purpose of showing design skill. Sometimes people have no time, but the question needed to answer is "can the person code and do I want to bring them to the next step". Sometimes I can't infer anything aside from the "can code", there are many variables at play.
Everything is signal, but I'm not looking for something specific aside from the "can code". Sorry, yes, there are people that can't code at all and do apply and we have to filter for them. Consider the challenge a captcha for developers.
The average candidate can code and something can be said based on their coding challenge, which is not necessary something measurable or comparable, but it is something useful to understand who that candidate is.
I'm struggling to express my thought because I'm the first one to say "I should be able to chat with a person for ~X hours to know if I want to hire them", however I'm faced with the reality that: - it's expensive (people hiring should be your strong people) - guts are not always right, occasionally they fail and that candidate is not good - the best experiences I had as an interviewee did involve some live coding, although that wasn't necessary the focus of the interview: getting to know the people on the other side and pair with them is what made it a good experience. I dread live coding, but in some form those interviews were great - met candidates which were amazing in all forms of chat, everyone hyped, until we faced them with technical stuff (very basic)
I don't think there is a saving grace for the process I'm currently using, however I can't find a solution either. A simple chat with the team has proven dangerous as well as expensive multiple times. An objective process has proven impossible and rigid. We are talking with humans, I'd rather tune every evaluation to the candidate itself, which in turn leads to making the process hard to evaluate.
Referrals work only up to a certain point, given the amount of people needed to hire, it's not a funnel big enough.
I wish I could solve the problem in some way, I read and study, but I still haven't found a way to solve it.
Almost forgot: The coding challenge keeps being a useful way to sprout conversation during the "full day with the team" interview, so it sets the ground for that too.
So giving me that test leads you to believe I don’t produce any code at all.
It's a good way to assess the level and filter out the kind of code you want or don't want to deal with. Or just help identify what you are looking for.
In the end every suggestion misses _some_ data points that could be useful in a form or another to hiring.
Either way, our process is flexible. The tech screening comes first, so depending on the candidate we might not ask about a coding challenge at all, it would be even embarassing to ask given the seniority of some people (masters).
The more qualified applicants for every job the more hiring criteria will become increasingly arbitrary and subject to the interviewers whims.
I reckon this is where racism, sexism and other idiosyncratic personal biases also have the most room to flourish.
Take home tests are popular when there is a glut because the time cost of assessing the candidate can be shifted to the interviewee.
But, the process doesn't materially change when companies are looking for senior or mid-level developers, except that they then start adding system design rounds.
Incidentally, I just had a thought: if there really is a glut of junior developers relative to demand, shouldn't that push down wages? It seems like there's some sort of market failure at work, but I'm not quite sure exactly what's causing it.
If you're really a senior developer, will you enjoy to work with C's?
Try to actively «fire» the interviewer at the first minutes of interview by showing the darkest points of your CV upfront. If you succeed, you will save 6 hours of hazing and a few months of your life after that.
I was in a team with inexperienced PM and few crooks, which negotiated 2x salary over mine, but had no skills. They hated programming, actually. I tried to help, but PM fired me instead. The project collapsed, so they started to blame me, damaging my reputation. It was an awful experience.
For me, it's easy to recognize the technical level of somebody else, because I will just ask a high-level question and then see how the discussion goes. If they say «Okey, now tell me about your experience», then they are definitely not A's.
If you are doing consultation and want satisfied clients only, or looking for an A level job only, then it's OK. If you are looking for any job (with high salary, of course), then it better to hide your weak points, to be accepted by a B, and then do the dull work.
[0]: https://www.amazon.com/Getting-Naked-Business-Shedding-Sabot...
Having PM manage devs is a red flag. PM and Devs should be in two different, parallels orgs.
IMHO It's symptomatic of the broader difference in leverage between senior/junior devs.
No, there are a huge number of unprepared applicants. Most are just a time waste, knowing just enough to get to the technical interviews without being able to pass them.
If you go asking me about bullshit you’ll get it.
I completely disagree with the current interview process as it existed for the last 20+ years. Last discussion I had I came to the conclusion that big tech companies created this process to not hire domestic workers so they can use H1-B visa workers, who are much easier to control under threat of deportation. H1-B was really big in the early 2000s which is when this process really started. There is a legal requirement to hire H1-B that a company must try to find a domestic worker but were unsuccessful. This style of interview process fits that requirement perfectly. The industry just happened to cargo cult it and here we are, massively employing an interview process designed not to hire people.
https://www.dol.gov/agencies/whd/fact-sheets/62-index-h1b
Additional requirements for H-1B-dependent or willful violator employers with LCAs filed prior to October 1, 2003 and after March 7, 2005.
No displacement of a similarly employed U.S. worker beginning 90 days before and ending 90 days after the filing of an H-1B visa petition;
Recruitment of U.S. workers before seeking an H-1B worker.
Offer employment to an equally or better qualified U.S. applicant for the job for which H-1B workers are sought (enforced by the Department of Justice).
First, they're an easy-for-me filter to pass. There are a lot of unqualified candidates just spamming their resumes, so I totally empathize with a company needing a low-effort filter on their side.
Second, if the company doesn't like my code, I don't want to waste any time. I've been in a few situations where an interviewer has a chip on their shoulder and rejected my perfectly fine solution that didn't have a microoptimization or other detail that I could only infer from mind reading.
Candidate get's a better portfolio of work, and I get to see their style. Seemed fair to me?
----------
Homework assignments and personality quizzes won’t give you excellence
This year I was once again hiring junior level developers, and the same dynamic was at work, but I got a surprising reaction from the person I spoke to. I’ll call her Zareen, who had just come through the Grace Hopper program.
Zareen had been interviewing at a few different places, but I assumed she was still open to hearing about the specific job that I was hiring for, so we arranged a phone call. We chatted for 15 minutes, and then I suggested she should come by the office and meet the whole team. She was just absolutely stunned.
"Wow, I didn't expect things to move this fast!" she exclaimed.
Let's think about that for a minute. She wants a job, I might want to hire her, I ask her to come by the office for an interview, and so she is stunned. It says a lot about how broken our hiring processes have become if what used to be the absolutely boring, dull, and standard process now provokes the response, "Wow, I didn't expect things to move this fast!"
Apparently other companies were giving her homework assignments and personality quizzes and phone interviews. “Please go to this website and take this test, we are trying to figure out what your skills are.”
At two other companies, she had already done 20 minute interviews, but never with anyone on the tech team. Instead she got a call from someone in the HR department, who read a checklist of words, which the HR person did not understand, but they were all requirements: “Have you ever heard of HTML? Do you know how to use that? What about CSS? Do you have that? How many years of skill do you have with CSS? And Java? I mean, Javascript? Are those different? Yes? Okay, I think we want Javascript. Do you have that? Yes? How many years?”
What an empty ritual; reading words that are not understood.
If you are lost at sea, don’t drink the brine
Stories abound of people lost at sea, perhaps because their ship engine died, or their ship sank and they escaped in a life raft. Once the clean drinking water runs out, the temptation to drink the sea water is strong. But of course, that is a fatal step: the sea has more salt than than the human body can tolerate; drinking makes you more thirsty, not less so. And yet the sea is vast. What a paradox, to die of thirst amid such an abundance. “Water, water, everywhere, and not a drop to drink,” as Coleridge said.
I’ve had this conversation with tech team leads:
Me: Where are you looking for candidates?
Them: I’ve put a job posting up at LinkedIn and Indeed and StackOverflow.
Me: Did you get any candidates that you like?
Them: Well, the problem is, I’ve gotten several thousand. The problem is trying to narrow down the pile. I cannot possibly look through all of them. I’ve decided to post the job a second time, but this time I created quiz that people have to take.
Me: What is the quiz about?
Them: It’s 100 questions about the technologies we use, plus some algorithm questions that should help cut down the number of applicants who get through.
Me: You created the questions yourself?
Them: No, I copy-and-pasted them from various online sources. Most of them are about standard stuff. I put in a few trick questions to help filter out the weak candidates.
Me: Are you sure you want the candidates who get your trick questions?
Them: Well, if they get the trick questions, then they must know some fairly obscure stuff.
Me: Is that what you need right now, people who happen to know some fairly obscure stuff?
Them: Well, not really, our work here is fairly standard, but I need some way to screen the applicants because the first time I posted the job we got way too many responses.
Me: Are you sure the people who get your most obscure questions are the candidates who will work out the best once you hire them?
Them: No, but I’m not sure what else to do. You never really know about a person until you’ve seen them actually work.
Me: How many people do you need to hire?
Them: I need 3 developers for the frontend, and 2 more for the backend.
Me: That seems like a manageable number. Have you tried to find some good candidates from friends of friends?
Them: Oh, I don’t have time for that. We need to move quickly with these hires.
Me: Is that any slower than making up quizzes for Indeed?
Them: Well, I’m not sure how I would even start.
Me: Something simple. You could go through your email contacts and make a special list with the email addresses of those who you know work in tech. Software developers, project managers, designers, anyone who might be able to give a meaningful recommendation. Send out an email explaining what you’re looking for.
Them: Hmm, well, some people might feel that I’m trying to poach talent from their team.
Me: They don’t have to respond. They can simply remain silent.
Them: I worry it would feel like I’m asking for a favor.
Me: That’s exactly what you are doing, you are asking for a favor. And then later on, when they are hiring, you could potentially pay them back by recommending someone, if at that later time you know of a good software developer who is looking for a job, when you yourself are not hiring.
Them: Yeah, but, if they don’t know of anyone, then it’s just a big waste of time.
Me: But it sounds like your original effort with Indeed was a waste of time.
Them: Sure, but now that I’ve got a quiz in place, I’m hoping to filter out more of the applicants, so I’ll get a smaller number.
Me: But the process does take time, right? No matter what you do, you have to invest some time in this?
Them: Yeah, it really sucks. I’ve got a lot of work to do, but instead I have to waste time hiring.
Me: But hiring is work. This is the work that you are doing right now. This is important.
Them: Sure, I guess that’s true, but I’ve also got a lot of software that I’m supposed to write.
Me: But as your team grows, you’ll need to spend less time writing code and more time focused on management tasks, such as hiring people.
Them: I’m afraid so.
Me: Is that something to be afraid of? Your team is growing, it sounds like things are going well.
Them: Yes, I guess that’s true, but I’m worried, once I’m no longer writing code every day, and reading everyone else’s code, how can I be sure the quality of the work will still be strong?
Me: You could hire excellent people and then expect excellent results from them.
Them: Yeah, but that’s a lot easier said than done. You should see some of the resumes that I got from the applicants. Full of typos, obvious exaggerations, mistakes about dates, or dates that overlap, stuff that makes no sense. Some of these resumes are so bad it’s funny. I’ve started sharing them with the team so we can all have a laugh about it.
Me: It sounds like Indeed isn’t really giving you what you want.
Them: That’s true, Indeed sucks. The applicants we’re getting from these online sites, most of them are really awful.
Me: Are you sure you don’t want to reach out to your acquaintances and ask them for recommendations?
Them: Oh, gosh, no. Like I said, that would take too much time.
For many categories of job applicants, job sites like Monster or LinkedIn or Indeed or StackOverflow are basically like drinking the brine: they offer such a abundance of material that you are tricked into thinking “Surely we can drink an endless amount from this source.” And yet, they waste so much of your time that they are effectively a kind of poison.
---------------
Recommendations from friends or friends of friends should count for a lot
When hiring, I rely heavily on recommendations from people I know. To use some Silicon Valley jargon, I rely on "social proof." If a good engineer, who I've worked with, recommends some other engineer, that counts for a lot with me.
I wrote this on Twitter and James Youngman responded, “It seems to me that this kind of approach is what perpetuates the domination of the industry by an in-group (who know each other, directly or indirectly) at the expense of outsiders, to the detriment of both diversity and fairness.”
To be clear, this approach very much works when you are hiring novices who are straight out of school. Back in 2018, when I need some junior level frontend software developers, I hired several women from the Grace Hopper program for women that is run by Fullstack Academy. In that case I spoke with some experienced friends of mine who had either taught at the schools or volunteered as mentors at the schools. As such, they could point me to who were the best of the graduating class. As it was, I ended up with an unusually excellent team of novices.
We all have a professional and ethical obligation to be sure we hire a diverse workforce – the workforce must be open to anyone who has real talent. There is no contradiction between that obligation and a requirement that a candidate be recommended by someone we trust. Assuming you have friends who understand their professional and ethical obligations the same way you do, they should be able to give recommendations on people they know, or put you in touch with friends of theirs who can offer such recommendations. Within your extended social penumbra of friends, friends of friends, and friends of friends of friends, you should be able to find someone who can vouch for most of the candidates that you need to hire. You just need to put in the effort, chasing down those recommendations through extended chains of friendship.
You know, you're not convincing me that your process doesn't just select for people like you here.
---------------
Beware of fake, dishonest attempts at establishing an "objective" hiring process
In the tech industry, I've seen good people, full of good intentions, invest serious time in developing what they felt was an unbiased, fact-based system of hiring, but they were blind to extent their own preferences were being treated as facts.
A specific example of this: there was a CTO, a man I've worked with and who I largely respect, who put serious time into developing a code base, and then deliberately adding some errors and redundancy to it. This code base would then be given to job candidates, as a homework assignment. Could they find all the mistakes, fix them, and remove all of the redundancy?
Many people in the tech industry now rely on tests like this, which are seen as being more objective than older job interview techniques. But this overlooks how much of the assignment is actually subjective in nature. In particular, what does it mean to reduce redundancy in a code base? Anyone who's done much programming is aware that one can refactor a code base almost to infinity. One can create more and more abstractions. At the extreme, one can create a new programming language where the program is represented by just a single character, perhaps the letter "w"":
w
There it is, the whole entire program that runs a major website. Of course, you also need to create a compiler that knows how to parse that letter into a lower level language that would do the real work of running the website. But if you ask a software developer to remove the redundancy in your code base and they come back to you with code that has more than 1 letter in it, then they've clearly failed the assignment.
Am I being ridiculous? Yes, absolutely, because I'm ignoring nuance, subtlety, reasonableness and proportionality ALL OF WHICH ARE SUBJECTIVE. If you want a truly objective standard, one needs to accept absurd, surreal, and almost psychotic behavior, because that's what human behavior becomes when you try to remove all subjective factors.
Does this mean the hiring process can never be truly objective? Yes.
Does this mean the hiring process must be unfair, unjust, corrupt and cruel? No.
We at UpSkillie, help companies hire engineers by certifying with a round of interviews. Candidates win because now they get someone vouching for them past the gatekeepers.
For a 1yr experience developer, one of our client just took a single round of interview after our recommendation and made an offer the same day, the exact amount the candidate wanted.
The candidate didn't join this company this company because he felt the HR process wasn't streamlined as he got an offer in just one interview. He settled for a 20% lower offer.
We asked him that if he wishes we can set a meeting with leadership if he wanted. But he just didn't feel it right because the process was fast.
There was proper introduction before the technical interview, so there is no chance of lack of familiarisation.
After all I'm trying to find, do they have initiative? do they care? do they make informed choices? do they think by themselves?
and since they asked all about my experiences and what was written, I was able to articulate more than I would in usual tech rounds.
Although we couldn't agree on location for personal reasons, that is an org which I would recommend specially as they really wanted to know the candidate's behavior and not whether he could remember some implementations which they're mostly never going to use.
I find it absolutely shocking that you would consider it trivial knowledge whether an algorithm is low-degree polynomial or exponential. The pendulum is swinging way too far to the other end. If you can't remember/figure out whether the code you're writing is O(N^2) or O(2^N) you should not be writing code professionally.
Excellent candidates are not the same as the ones who arrive at a similar solution to ours. The best candidates are able to ask important questions about the requirements, and when asked can provide rationale for choosing specific components, as well as other potential options they considered.
More often than not this kind of question is assessing your process, not the outcome you produce.
Much like standardized tests are meant to assess objective aptitude but invariably favor those who specifically prepare for the test, which diminishes their objectivity, these types of interviews vastly favor those who specifically prepare for these types of interviews.
The exact same pattern happens with product managers. There are very specific types of interviews and there is an entire industry built around preparing candidates for these types of interviews. At that point, is the interview process still effective? I'm certain there is a pool of fully-capable people out there being left behind in sub-optimal careers for no other reason than they've underestimated or are ignorant of the need to prepare for an interview exercise that is, at best, loosely related to the work they'd actually do.
I suppose the counter-argument would be that good candidates should be able to figure out what they need to do to successfully complete a task, and properly understanding and gaming the interview process showcases that skill.
But those who prepare for system design interviews are most likely better equipped to design systems in real life too, because they had to go through the different problems and types of systems and their requirements. Now that doesn't mean they can implement it end-to-end, but you could probably tell those who are over-engineering it from those who actually either have experience or solid foundation to make good decisions.
In what way should this be obvious? Do they insult you and see if you react poorly? Normally you do this by just working through a problem, and then after the interview you evaluate whether the person was unpleasant to work with. There is no unnatural process required, you get that for free.
For instance, even if the interview prompt doesn't change - an interview for a mid to senior position expects far better communication and execution than that of a NCG interview etc etc. This is sort of a self-fulfilling prophecy for people with more than 2-3 years of experience who don't perform well or haven't grown.
That seems to me to do away with the need for a coding challenge as well as demonstrating a lot about their approach and interests.
On the whole, I'm surprised by the number of people who think both coding challenges and whiteboard interviews are a waste of everyone's time. Is the employer not supposed to assess the candidate in any respect?
Most career engineers (including myself) have worked on proprietary systems. I can't show you any production-level code that I've written in the last 10 years, because it's all proprietary and owned by the companies I've worked for. I don't even have access to my previous employers' code! So what exactly would I put in my "portfolio"?
If the answer is "open-source," then that presumes that the only engineers worth hiring are those who contribute to open-source -- which leaves out a ton of great engineers -- and those who have the extra time to contribute to open-source outside of their day jobs -- which can be a bias against those with life obligations (e.g., caring for dependents).
So the answer to your first question is: no, they shouldn't. If you have one, FANTASTIC. But it shouldn't be a requirement.
To your second question... Employers need to evaluate candidates _somehow_, so yeah, I'm baffled by that as well.
Would you be okay if your former employees provided the software they built for you, with a complete git history, at their next job interviews?
If no, do you have a reason to assume that the former employers of your current job candidates would be okay with the same thing?
I don't understand. Does this means that I should schedule interviews for jobs I want sooner or later? The wording "order of importance" is ambiguous which order I should follow.
Implies ascending order so that you are well prepared for the later more important ones by rectifying the mistakes you made in the previous ones.
As someone who spent many years with my writings misinterpreted, simple word choice is always better than relying on context.
1) the questions asked in a technical interview often are what the interviewer is actually working on and so you're doing their job.
2) send a billing invoice for any time they interview you for and you don't get hired. Your time isn't free.
3) you generally don't get hired to work on the project they say they'll hire you for. Expect disappointment.
Do you do this? Have you actually gotten paid?