Apparently the approved HN method is to arrange the resumes on a dartboard, throw darts at it, and commit up front to hiring whoever you hit unconditionally for at least two years without no possibility of having to fire them. Or something like that.
Setting limits on what you will do is good, and ghosting is bad, certainly.
But in the end, you're going to have to do something unfun to get hired. There's no way around it. I know we'd all love to live in a world where Google one day just logs on to LinkedIn and is so impressed by the sheer brilliance of our awesomeness which just somehow oozes through our listing despite the fact we didn't have to do anything to demonstrate it, as it's also unrealistic to expect programmers to have a lot of publicly-available demonstrations of their skill such as open source projects (forgot to mention that one!), that instead of hitting you with a job interview they just lead with a job offer for their best position, but that's just not going to happen.
We then walk through their notes (if they made any), and the code sample itself together. I have them make any observations, critiques, suggestions, or other thoughts together with me. This gives me an idea of how they think, what issues they saw, how they would improve things, how familiar they are with the specific language, and coding in general. It also gives an opportunity for some light “conflict” resolution , if I push back on their thoughts.
This has worked really well. Those that don’t do well on the spot can make notes ahead of time (but aren’t expected to spend time coding for hours) and those that are confident can walk through it live.
2nd aspect is unpaid take homes. It's complicated. Companies do pay a lot to fly candidates, put them in hotels and feed them for onsite interview. So financially company can afford to pay something. But it adds a moral hazard as you are paying cash irrespective of any expected quality or commitment.
Other thing I would like to highlight is that unlike any other industry, tech. allows people to enter at ease irrespective of the pedigree and credentials. No hospital would hire a physician who has read a lot on the Internet and did some pro-bono help to the neighbourhood kids. So what is the best way to hire isn't very well defined. It could be Leetcode, puzzle problems, take home tests or something else.
The take-home assignment is short. It shouldn't take more than an hour if you really really want it to be polished, which we heavily insist we do not care about. The overall process is a bit longer, because we then discuss it together.
For the pair programming session, the exercise is picked by a developer that isn't involved in the process, to put candidates and interviewers on equal footing.
Our goal is to be able to give an offer within 48 hours starting at the first contact, and give a feedback, positive or negative, maximum one hour after each stage.
It's a candidates' market. A long and complicated process only ensures you weed out the candidates who have plenty of options. I'd almost be tempted to give a long assignment and consider everything but a firm "Not even in your dreams" as a failure.
| We are wondering if you would like to attempt our code challenge (C/C++ or | Python). It is a Computer Vision problem which we think can be solved in | about 8 hours. I'm afraid I wouldn't, 8 hours is far too much for a interview problem. However, thanks for considering my application.
1. Is it actually giving the employer more confidence or information about your candidacy?
2. Is it within the normal bounds of an interview? If someone asked you to do another 60 minute technical interview, would you?
3. Is the company clearly not trying to use the product of your code challenge?
To be honest, there are a lot of people who can look impressive but turn out to be totally under-skilled at coding. I’m sympathetic to hiring managers who feel like they need to test for that. As long as it’s not a super long exercise, they’re not just hazing you, and they’re not trying to use the results, I think it’s fine.
Almost everyone chooses to do the small coding assignment, because they don't have code to bring.
The second is they didn’t set expectations (or at least you didn’t tell us if they did). Should you have spent 6 hours on this? How long does it normally take? After the assignment would you be brought in for 6 more hours of interviews or is the assignment the major filter?
At the end of the day, take home assignments are the best filter, the most equitable and the most efficient way to do hiring consideration. Companies (usually the middle managers within them) just don’t have the courage to use them correctly and don’t spend the resources to make them a good filter (they also don’t spend resources on the other job filters so those aren’t good either).
Nonetheless, I can't think of a better solution for this. Hiring someone is a big commitment (for both parts), so I want to be completely sure that I am hiring the right person. How do you that? How do you measure the quality of the other person in an area such as IT where it's so easy to lie about knowledge and experience?
Let me tell you why that was better than the current hiring meta.
1) I can learn everything I need to know in an hour with someone. 2 will likely not drastically give me a better idea. 8 hours with someone is not 8 times better, it just doesn't scale like that. So the idea that the more work you give a candidate, or the more interviews, or whatever, the better your hiring practice, it's just not true.
2) People can be very nervous in interviews. It's an intimidating, adversarial environment that has no relation at all to the job or work. It's almost the beginning of the way for the company to treat you as lesser, and they will take advantage of that to screw you these days. As you say, they will just ghost you. They didn't used to do this nearly so much. They'd at least send you a letter, or give you a call.
3) Even if 1 and 2 weren't true, the questions asked in interviews have no relationship with the real job. You just can't ramp up in time, etc. There's too much learning. Picture an intern. They do nothing except take everyone's time for the first month, but it's the rest that matters. Will they get something useful done before they leave? Maybe. But it does take a while to ramp up. So interview questions don't judge job performance.
But we still do it, because people like that tinge of power I guess. That feeling of control in that you can say yes or no to someone, they have to placate you for the job, etc. A lot of interviewers I know act very strange in interviews too, and they don't act that normally.
For the interviewee, it's even worse. You waste your time, you spend a lot of emotional energy, you don't know if you like the people you'd be working with, you don't know really what you'll work on, and no matter what you have to do what your boss says anyway, which can change at any time. Oh and it's "right-to-work" so they can fire you any time for any reason.
It's much more useful to talk to their previous boss or friends or references. Even if they are biased, you can usually tell pretty quick again who is telling you nonsense. At least then you can hear real stories about real situations in the past, rather than useless hypotheticals. But we don't do that anymore because of liability from lawsuits in hiring. Because a lot of companies are actively discriminating. Some are passively doing it, some are trying to do better but are hopeless. So everyone is just covering their ass.
Sounds like a great deal!
I will however not accept a take-home coding test before I spoke with the engineering team and saw that they're seriously considering my application (i.e. it looks like I will be a good fit, and they just want to make sure I'm not some fraud who can somehow talk the talk, but can't walk the walk).
What I DO HATE about take homes, is if you complete one, clearly put time into it, and then are refused feedback when you are rejected. If I put 2-10 hours into writing something for you, I at least deserve three sentences on why it wasn't accepted. I know these people are busy, but so am I. Most of us also have jobs, and even if we don't we want to know how to improve.
That being said, I've seen cases where the take home assignment is actual company work, in which case I 100% agree you should be paid.
Actually, the assignment was "take this shitty service and make it production-ready". It had some pitfalls that I avoided, and I introduced monitoring, automated deployment, API documentation, etc.
There was a bug - a minor misunderstanding that was simple to fix if they gave the feedback and allowed to do a quick fix - but the rest was production-ready.
I had fun doing it, that's why I didn't mind taking time. What I didn't expect was the poor binary feedback with zero content.
From now on, I'm only taking these assignments if they agree to have a feedback session. If not, I won't do anything. I'm close to 20 years of experience and it feels like they treat me like an undergrad (although I have a full Github profile).
So I decided to mail a take home assignment. I took about an hour myself to prepare it, the assignment was not work related, it was a completely fictional task. I think it was creating a HTML page of ~50 lines demonstrating the hole could be filled if the person had access to internet and all relevant docs. The person delivered the next work day, did well, and we hired.
I've thought long and hard about this, and decided the assignment was a mistake and I would not do it again (sorry to the person in question). Why? In practice, when listening an hour to a candidate and let them write a minimum of code, you know if you have a complete weirdo who never touched a computer, or someone who is at least basically OK. In this case, it was a short term job, so the blast radius was pretty small even if candidate was bad. For longer term engagements, there is generally a test period and better vetting available. Meanwhile, I was in a position of power over someone else, and while the whole thing seemed minor to me at the time, I later heard the (junior) candidate was worried sick and spent way to much time on the assignment.
An underlying cause for my mistake was the interview situation, which was very bad. Basically, I was in the middle of something else, and a project lead I had never heard of for a project I had never head of asked me to do a technical interview while the candidate I had never heard of was already sitting in a meeting room. Needless to say, I was completely unprepared. There wasn't even a whiteboard in the meeting room. So I basically adjusted by always being prepared for surprise candidates: A list of questions for most common technologies and a template for technically grading candidates were always stashed away in my locker from then on, and the people starting projects would keep us interviewers in the loop when a job would open.
If the hiring process requires 2 minutes of the company's time for every 1 hour of yours they are pretty much guaranteed to waste your time.
I've made exceptions to this rule before for what I thought were good reasons and deeply regretted it every single time. I no longer believe there are exceptions.
That being said, if you want to avoid having a large imbalance in risk/reward, I would suggest talking compensation before agreeing to submit yourself to a large time investment. At least that way you know why you are putting in the time investment that comes with take home assignments. There's nothing worse that putting in a significant effort into the interview process only to discover your compensation expectations would never be met.
Even then, if something can be done in 1 hour, it can probably be done better in 2-3 hours or more. It takes time to show your best work. That's why many companies that do take-homes claim that their process takes only a couple of hours (but in reality it doesn't).
Is a prospective employer supposed to suss this out entirely through verbal questions?
There’s nothing inherently wrong with unpaid take-home interview work. Don’t do it if you don’t want to do it, but don’t declare that it’s “not OK” in a general sense, as if it’s somehow immoral. If both sides are clear on the arrangement, and it ends with either acceptance or rejection with feedback, there is nothing wrong with it. It’s my favourite format as an interviewee.
I've interviewed maybe 500 engineers in my career. I'm an early engineer of Instacart, 3rd engineer of Eventbrite, founding engineer of Reforge. Started 3 companies myself.
My interview is always the same:
1. Bring code you've written
2. Share your screen
3. Explain what it does and I will casually ask questions about it
You get so much information from this:
- How they think about code
- If they think it could be better
- Who they blame if the code isn't the best
- Product dev glimpses
So you think that a 6 hour unpaid assignment is unfair. What do you think the alternative should be?
Many of the posts here point out that 'take-home-tests' aren't common in other professions, but completely miss how many free hours other professionals have to do to prove their suitability for potential employers.
Here are some examples:
- Designers, photographers and writers spent countless hours putting together and updating portfolios.
- Anyone part of a professional association (doctors, nurses, pharmacists, engineers, architects, pilots, etc...) spend many hours studying for and writing exams (for free), and then every other year spend hours documenting all of the professional development they have done to maintain their credentials (also for free).
- Many higher responsibility jobs, especially in public institutions and government, require months-long application processes complete with multiple interviews, essay questions, and personality tests.
- Consultants can spend 40 hours or more crafting proposals for every new contract they go after.
- Academics and researchers require regular publications and often do regular peer reviews for free.
I doubt anyone gets a job of any importance based on a resume and a quick coffee unless of course there's nepotism or greek letters involved.
So how should programmers prove themselves to a potential employer? Would you rather have a professional association? or standardize on coding portfolios? Or perhaps you want to go back to the days of three essay questions and a personality test?
I spent a couple hours on it, but I realized that in order to get it working and tested, it would require many more hours of work. I started peppering the code with comments like /* here I would verify the validity of the data by doing X */ to show them I knew what needed to be done without doing all the grunt work.
I sent the code, but the manager got back to me and said he expected finished code that actually worked and not just pseudo code. I politely told him that I would gladly do the work if he wanted to pay me my fee I usually charge for contract work.
He declined so the company did not get a bunch of free consulting work, which I think was the point of the exercise. Too many companies get away with this.
I think this is a bad place to start. But how do you weed out people misrepresenting their ability? I think it’s a lot easier than most realize: first you need _something_ to talk about, have the candidate bring something they worked on. Then ask a ton of questions. Not just technical questions, questions about motivation, interest, reasoning, and taste.
The argument against this is that not everyone has time to make something on their own time and it just shifts the privilege to those with a greater share of free time. I think there is something to that, BUT: the power to choose the subject is in the hands of the candidate not the interviewer, that to eliminate all the test-like processes seems like a fair trade.
I refuse to do basic projects that make me learn nothing and feel like a wasting of time. Most of the time if the assignment is "not interesting" the future offer would be lower than I expect and the daily job is going to be boring.
I think that my point of view is going to be unique here, maybe is because I need a "push" to improve my skills (I'd rather not to be fair), but although I have been rejected from some processes after a long and hard assignment, I have learn something and I'm happy (almost grateful) about that.
I think we need to stand up and advocate for the expectation that corporations should provide more value to society than just print money. They should be held accountable to creating a strong, and healthy labor force.
For time bounding, I love the time estimates they give you for a decent sized problem. A major company told me that a feature extraction problem + report should only take 4 hours. They provided me with some large CSVs representing DB tables (which contained some malformed data) and wanted a brief report back.
That's unrealistic in 4 hours even for a great performer. Then you spend the weekend on it and they won't give you feedback on it because of the suits in legal.
Home assignments should be short and sweet, it does not take a huge complicated task to see who can and cannot write programs. There are differences in ability of course even among "good" programmers, but the main difference is between those who truly cannot do anything, and those who can.
I am assuming an active job search where you have more than one potential employers.
If the test task is simple and you have the time: do it. If the test task is interesting and you really want into this company: do it perfectly. If the test task is simple, but you don't have the time: write an email explaining how you have a full time job with lots of interviews, tell them your CV clearly demonstrates you have enough experience, ask to forgo the test task. If the test task is hard and you don't have the time: explain how you would do the task, ask to forgo the task as above, walk away if they don't agree.
You would be surprised how often people will skip steps of the interview process if you ask nicely. This way I skipped tedious home assignments, psych tests and leetcode home assignment (not even hard, just told the company I don't want to rehearse dynamic programming with so many interviews lined up).
In my recent job search I had two good offers and incidentally both were the ones where I did the test tasks 150% because they were interesting. So do them if they are worth it.
The most reasonable company I have dealt with was Trip Ninja, an Amazon gift card for my time. Regrettably I tripped up, and messed up the test, timed tests are my Achilles heel.
A dr would not do a quick surgery and a power plant engineer won’t build “just a quick test reactor” because they have credentials and the hiring bodies trust those creds.
In software is the problem that we don’t trust what the resume implies? Where does the deep distrust come from? Why don’t we have an equivalent to a medical, legal, or engineering accreditation?
(I’ll state the obvious ghosting was wrong)
“Home assignments” suck because they can be unbounded and tend to disadvantage people who might not have a lot of time.
“Pair on a feature/bug” sucks because it’s quite hard to many people to demonstrate their skills in that stressful environment with someone they don’t know.
“Whiteboard Code Golf” sucks because it hands an advantage to people people who have the time and energy to grind shit they won’t use in their roles.
“Paid trials” suck because they’re not something that everyone can contractually participate in.
I honestly don’t know what the best approach is, from either side. I have stuck with a single take-home for devs on the basis that we can establish a clear rubric for evaluating them and try to be at least somewhat objective with what we are looking for. Maybe a better approach would be to let the candidate guide it a bit, and offer a selection of different evaluations that they can participate in?
At least I agree it’s important to maintain a clear line of communication and respond to everyone. I know it’s easy to let people fall through the cracks as you scale; I hope I’ve never done it myself but I can definitely advise that a robust ATS helps to make sure every application is tracked.
- initial interview with HR
- technical interview with devs
- home assignment ( you can find it on my GitHub with the name 2048 )
- discussion of the assignment with the same devs of the technical
After every step they said they were very impressed, I did reach the step where they were scheduling the final interview with the CTO then they weren't able to schedule it and they disappeared for months with the excuse of hiring freeze. Apparently they hired someone else and they decided to put me on hold indefinitely
Programming is largely solo work punctuated by a high-bandwidth communication (presenting your solution to the team, review, etc.) A take home assignment with a follow up simulates the actual job environment, especially for remote work. No other coding interview technique comes close - portfolio review doesn't show how you worked only that you've worked, in-person coding challenges and whiteboard interviews are so far removed from the daily experience.
2kloc / 6hrs does seem excessive though. My advice to interviewers - keep the exercise time-boxed to 2 hours (And actually have some developers work through it internally to confirm this!) "How far can this candidate get on the problem in 2 hours" is a better signal than "Can they build the perfect solution with unlimited time". And time boxing the assignment gives you lots to talk about - "If you have more time, what would you add or change?" is a prompt that should yield another high-value signal.
Happened to me once. The best thing is I explicitly told them beforehand I had little time to spare for home assignments. I got rejected after almost a week worth of work total. I should have billed them...
Otherwise I’d write to them and tell them that you have an issue. Chase a bit, presumably you don’t know the reason for the ghosting.
Having said that they could be ghosting you because they are assholes. There are unfortunately a lot of inconsiderate assholes in tech.
They rejected my application before I got too far with the demo, which would have taken me a lot more than six hours to finish. Although it might have been an interesting addition to my Github repo, it was kind of tailored to this one company.
I'm not disagreeing with the OP, because I probably wouldn't find an interview project nearly as fun. I wonder, though, whether anyone has been successful with a one-off, company-specific project like this, as opposed to a general portfolio of projects that you've made over the years.
I then time myself doing it.
I figure that means the applicant time commitment is under 2 hours, which seems not too bad.
Before doing an assignment just work out the “pot odds” and see if you want to raise or fold. Yes it is basically poker!
If you are doing it because you don't believe someone's ability, you should either pay them or be honest and say you don't believe their experience, in which case it is up to you whether you want to do it for free or not.
I find the ghosting unforgiveable though, I can't understand somebody being in contact and you simply not replying even if to say "sorry, we aren't taking you". Are people so insecure, they don't know how to reply without sounding aggressive/opening themselves up to lawsuits or something?
For engineering roles where the person is expected to write copious amounts of code to ship functional features everyday, a 2.5-hour machine coding round to assess coding competency (as part of an interview loop that also has other rounds for problem-solving, data-structures/algorithms, high-level systems design and low-level design) is standard in multiple companies I have seen (and advocated for). While coding round is a strong filter, it is important to assess the interaction of the candidate in these other rounds that are non-coding but designing/problem-solving rounds, especially in high functional domain complexity industry like e-commerce or payments etc.
In the machine coding round, the candidate should be given a well-defined written problem statement (from an internal question bank of well-calibrated problem statements) along with test inputs and a few test outputs, and in the first 5 minutes ask them to read the problem and ask any clarifying questions. Then leave them be with a dev machine for next hour. If they choose to, 10 minutes in, they can discuss the approach they are going to take with you. Then after an hour, you can discuss if they have a working code that passes the test inputs. If yes, you can give them an enhancement/modification to make. and leave them be for another 45 minutes. Then, take the last 30 minutes to discuss the solution they have come up with and understand their thinking style w.r.t coding conventions, style etc. If they couldn't complete the enhancement, discuss a potential solution (give a hint) with them and see if they can tackle it. Write calibrated/standardized evaluation notes for your interaction so that others (hiring panel) can understand and decide. Existing engineers inside the company should have tried the problem statements themselves and calibrated to see if the problem is meaningfully solvable in the allotted time.
I don't understand the practice. Maybe someone here can fill me in on why it is considered OK from the recruiter perspective. Too many folks asking for feedback post-rejection? If that is the case - automate the message with a generic rejection.
a) be 100% absolutely certain that you definitely need this to evaluate the candidate (you most likely don't)
b) if you do then you owe it to them to study their submission, run it, test it and provide clear feedback and honestly if they've broadly met the requirements you should interview them. The submission could form part of the interview process - maybe you pair program some changes together, or discuss part of the implementation. Basically if someone delivers six hours of work, you use it.
c) No matter what, you communicate with the candidate throughout this process. There is absolutely no excuse for ghosting candidates. None
1. set up a good GitHub (or other) profile; convince potential employers to look at that rather than test you (I've done this - it can work) 2. if a company still insists you "do the test", then either your GH is too sparse (spruce it up!) or they're full of shit - but you have another data point to work with 3. even the most trivial "toy project" test could be 1 hr for one person and 6hr for another, so what's unreasonable for you may be totally reasonable for the level they're aiming at
You also get an idea of what company cares about and if its a good match for you.
If you move to next step you did something right, if not then there are others that have done better.
Ghosting might be a problem like someone forgetting to process stuff, vacations, etc, just check with recruiter whats the status, dont be antisocial.
And if it took you 6 hours to do, you chose to do it, and hopefully you learned something. There is no implied obligation on other side to pursue you just because you took on challenge.
In both case, if you are going to do home assignment, my question to you is: How good is your offer ? I refused several HA when interviewing with companies because their offers was just not good enough for me to take several hours, on top of the regular interview, to do it. If you do HA, make sure your candidate have a reason to want to take several hours for you.
It's definitely a strike against a company, but it's something I would put on the scales against how good this job would be. Sometimes it might be worth it.
So far, this approach worked very well for us.
Maybe someone else is more hungry, more ambitious, more game than you. They deserve their shot.
When I have given assignments like this, I said “the result of this work belongs to you. You can show it to any prospective employer. In fact, if you can show me a portfolio of your work, then you do not need to do this assignment.”
(I hire testers, and they rarely have examples of their testing work to show off.)
Combine this with relatively low salaries even for experienced developers, I don't think it is something anyone should want to do, no matter how much you'd love to go there.
My wife is a lawyer, she had to spend 2 years (in the US it's like 4 years at $80k+) and another 40 hours a year for life to maintain the qualifications that allow her to skip the equivalent of coding interviews.
I'd rather live in the world of none credentialed programmers to be honest.
So, what ends up happening is that nearly everyone in the interviewing process ends up half-arsing it - from the recruiters who prefer to contact nearly everyone eligible based on some keyword searches - to the engineers who have no time to be thorough - to the hiring manager who usually has a bunch of fires to extinguish.
A few companies do tend to put quantifiable metrics around their processes but they're usually too reactive and inconsequential.
The interviewers have a vested interest in being more productive by hiring the best people, but at the same time, there is personal friction against hiring someone good/better when your own promotion is hanging barely by the 'meets expectations' thread.
Now the assignments - they're almost always totally useless. Like, build a new app based on a third party API and then make sure to test it. Useless because of multiple reasons - the API is nothing like what you use at work; your current product team has coalesced around some archaic architecture that no Greenfield app would use; it's the take home assignment of the month (like the favorite 'build a movie app using the OMDb API'). A better alternative would be to open up your own API and perhaps a module of your current production app and add something to it, create a PR, or even just fix a bug or two. I actually think asking candidates to document a module is much more useful than asking them to write code you would never use, even if you pay for such an assignment.
Onsite interviews are even more useless - it's usually the most vocal people asking esoteric questions about older technology or algorithms that they've had success with candidates stumbling upon. Again, almost none of the whiteboard exercises or questions are from real-world scenarios.
You could pay candidates for the interview process, but that doesn't even address why interviewing is so fundamentally broken. I bet we would have amazing software products if we just interviewed better, especially when companies have been able to lobby for right to work laws nearly everywhere.
This is where you messed up. Set a hard limit of 1-2 hours, and mention edge cases in your comments and move on. It also depends on the stage of the interview. If you're in the early stages then they probably just want to see that you know what you're doing, and it should be fairly fast with the right frameworks, scaffolding, starters, etc.
Additionally, software development seems to be the only area where the candidates get bent out of shape being expected to prove they know what they're doing. Take home tests are bad and have to be confined to an hour. Whiteboard interviews are bad and don't accurately model the day-to-day. Leetcode is bad because it's 10x harder than anything you'll work on. How exactly do we expect someone to get a sense of our skill at programming if we eschew every opportunity to... program for them to review? The exception might be extremely well-known people who have extensive public histories on GitHub or something similar, but by definition they're in the minority and 99.9% of companies don't need someone of that caliber.
I interviewed with a health tech startup and they had a good way to do it. We set up a time ahead of time when I'd be given access to the repo. 90 minutes later the interviewer was going to clone the repo and whatever was there was what he was going to look at. This was after a previous ~hour long interview where we did the "tell me about your experience" rigamarole that some developers seem to think should be enough to get them any job.
The only companies that asked me to do a take home are ones with horrible, unprepared interviews where it was clear interviewers were just kinda talking and feeling around for... something.
Happy to do a free code review if it's in one of my native languages.
It seems like it was implied that you were a serious candidate if they asked you to do this. And the implied understanding is that they would at least review your work and provide feedback.
Send them an invoice!
- The work produced is not used in any way by the company other than to assess the candidate.
- The project has a time limit to prevent those with more time to dedicate to it being able to do better (reduces bias).
- The company puts time into reviewing the code that is commensurate with the time spent on it (a 3 hour test warrants at least 45 mins of thorough code review and feedback writing across a couple of engineers).
- The company provides options to take the test at a convenient time, or even on-site but unsupervised if desired by the candidate.
Asking for payment to take part in an interview isn't a great approach assuming the above are true (which they are often not). Companies don't pay for interviews as general rule, but conversely should be clear about the full time commitment so that candidates can make informed decisions about taking part.
Why should we be any different?
Putting an hour limit on them makes sense.
How is it possible to do anything meaningful in just an hour?
I find it weird that you guys don't want to spend some time to show your skills to the employer, without getting paid. These are not real projects. You're not benefiting the employer when you finish them. They also spend some time evaluating your project submission.
(I'm not talking about the companies trying to make people work free by giving them parts of the real projects in disguise)
As far as ghosting is concerned it's a bit baffling to me, seems far more in a company's interest to promote the notion of not ghosting so that they actually stand some chance at all of applicants letting them know when they've dropped out.
This is what you need (friends’ startup).