Confidash for Companies
Screen a whole campus batch before a recruiter ever boards a flight.
Confidash runs realistic, voice-based screening interviews at scale, grounded in your role and each candidate’s resume, scored on one rubric. Your recruiters walk into the drive with a shortlist, not a queue of three hundred.
Per-candidate or per-drive, billed by invoice. Start with a pilot on your next drive.
Built for Indian campus drives: JDs and role requirements, full batches, ranked shortlists, and TPO timelines.
Shortlist
Backend Engineer · batch of 312
- 01
Aditya Rao
NIT Surat
88Shortlist - 02
Priya Menon
VIT Vellore
82Shortlist - 03
Karan Shah
GTU
64Review - 04
Nisha Verma
IIIT · CE
47Decline
A campus drive is three hundred candidates and two days of recruiter time.
The math never works. One college visit puts hundreds of students in front of four or five recruiters over a day or two. First rounds are the same questions asked over and over, energy drops by the afternoon, and every interviewer scores a little differently. Strong candidates get missed in the crush; weak ones advance because someone was tired. The drive ends and you still aren’t sure the shortlist is the right one.
300+ students, one shortlist
A mid-size drive screens more candidates in two days than your team screens in a month back at the office.
Repetition dulls judgment
The fortieth interview of the day gets a different read than the fourth. Consistency is the first thing to go.
No shared yardstick
Five recruiters, five bars. Comparing candidates across panels, or across colleges, turns into guesswork.
Define the role once. Screen every candidate the same way.
- 01
Define the role and a good answer
Upload the JD or the must-have skills, and set what a strong answer sounds like. That becomes the one rubric every candidate is measured against.
- 02
Candidates take a voice interview
Each student joins a realistic spoken interview grounded in the role and their own resume. The AI asks, listens, and follows up on vague answers. Same rigor, every time.
- 03
You get a scored, comparable shortlist
Consistent scores and per-question detail for the whole batch, ranked on one rubric. Open any candidate to see exactly why they landed where they did.
Hear a screening call
Natural voice, built for volume. What most students and cohorts run.
Read the transcript
- SarahHi, I'm Sarah, and I'll be taking your interview today. To start, tell me a bit about yourself.
- CandidateHi Sarah, I'm John Doe, a final year computer science student at Sunrise Institute of Technology with a CGPA of 8.4. I've worked on projects like Campus Connect, a student networking platform, where I was the lead full stack developer, and LeafScan, a plant disease detection web app where I focused on machine learning and backend development. I also completed an internship at Bright Apps, building dashboards and optimizing query performance.
- SarahOkay, John. Could you tell me more about your role as the lead full-stack developer for CampusConnect? What specific parts did you build yourself?
- CandidateAs the lead full-stack developer for Campus Connect, I was responsible for the entire development process, from designing the architecture to implementing features. I built the real-time chat functionality using Socket.io, developed the event RSVP system, and handled the integration of the front-end with the back-end using Next.js and Node.js. Additionally, I worked with PostgresQL to manage the database, ensuring smooth data handling for users across the three campus clubs.
- SarahGot it. You mentioned optimizing a slow report query during your internship at BrightApps. Could you walk me through the steps you took to identify the bottleneck and then improve its performance from 4 seconds to 300 milliseconds?
- CandidateTo identify the bottleneck during my internship at BrightApps, I first analyzed the query execution plan to pinpoint areas where the process was slowing down, such as stable scans or inefficient joins. I then optimized the query by adding appropriate indexes and rewriting parts of the SQL to reduce complexity. Additionally, I reviewed the database schema for any normalization issues that could improve performance. These steps combined significantly reduced the execution time from 4 seconds to 300 milliseconds.
- SarahOkay. When you say you "rewrote parts of the SQL to reduce complexity," could you give a concrete example of a change you made and why it improved performance?
- CandidateOne example of a change I made was replacing a subquery in the where clause with a join operation. The original subquery was causing multiple executions for each row, which significantly slowed down performance. By switching to a join, I eliminated those repetitive calculations and allowed the database to optimize the query more effectively. This change helped reduce the overall query complexity and improved performance considerably.
- SarahRight. And how did you measure the impact of these changes to confirm the 300-millisecond improvement? What tools or methods did you use?
- CandidateI measured the impact of the changes by using the built-in query analysis tools in PostgreSQL, specifically by checking the execution time before and after the optimizations using the explain analyze command. This provided detailed insights into how long each part of the query was taking to execute. Additionally, I ran multiple test cases with typical data loads to ensure consistent performance improvements. The combination of these methods confirm the reduction in execution time to 300 milliseconds.
- SarahOkay. Moving on to your LeafScan project, you used TensorFlow for classifying leaf images. Can you describe how you handled data augmentation for your image dataset, and why it was important for this specific application?
- CandidateFor the leaf scan project, I handled data augmentation by applying techniques such as rotation, flipping, scaling, and color adjustments to the training images. Data augmentation was crucial for this application as it helped increase the diversity of the training set, which improved the model's ability to generalize and recognize plants under various conditions and angles. By creating a larger and more varied dataset, I was able to enhance the model's accuracy in classifying leaf images and suggest appropriate treatments for different plant diseases.
Real-time conversational voice: interruptions, follow-ups, the closest to a live panel.
Read the transcript
- SarahHi John, this is Sarah from the interview. This is a general round, about five minutes, and we’ll start with a brief introduction. Tell me a bit about yourself, your background, interests, and what you’ve been building lately.
- CandidateHi Sarah, I’m John Doe, a final-year Computer Science student at Sunrise Institute of Technology, where I’ve maintained an 8.4 CGPA. I’m passionate about full-stack development and have recently worked on CampusConnect, a networking platform for students, where I led the development using Next.js and Node.js. I also developed LeafScan, a plant-disease detection web app utilizing machine learning with TensorFlow. In my recent internship at BrightApps, I focused on optimizing performance and implementing CI checks for React and Node dashboards.
- SarahOkay, let’s focus on CampusConnect since you mentioned it. Out of curiosity, what parts did you build yourself from scratch, and what was the hardest bug you ran into while implementing it?
- CandidateIn CampusConnect, I built the entire user authentication system and the real-time chat feature from scratch using Socket.io. The hardest bug I encountered was related to message synchronization, where messages were not consistently appearing in real-time for all users. After extensive debugging, I discovered an issue with how we were managing WebSocket connections, which I resolved by refining our event handling logic to ensure messages transmitted correctly across all clients.
- SarahGot it. You mentioned fixing message synchronization and the WebSocket connection handling. What exactly did you change in that event handling logic, and how did you verify that all clients were consistently seeing identical messages?
- CandidateI modified the event handling logic to ensure that each message sent from a user was acknowledged by the server before broadcasting it to other connected clients. I implemented an event confirmation system that allowed the server to track which messages had been sent and received. To verify consistency, I set up automated tests that simulated multiple users sending and receiving messages simultaneously, and I monitored the logs to ensure that all clients displayed identical messages in real-time. This thorough testing confirmed that our synchronization issue was resolved.
- SarahNice, that sounds solid. Let’s switch topics. For LeafScan, you mentioned a CNN and TensorFlow. How did you train and evaluate the model, and what kind of accuracy or confidence did you achieve before you felt comfortable shipping it?
- CandidateFor LeafScan, I trained the CNN model using a dataset of plant images labeled with various diseases. I used TensorFlow to build and optimize the model, experimenting with different architectures and hyperparameters. After multiple training iterations, I achieved an accuracy of around 92% on the validation set. I felt comfortable shipping the model after extensive evaluation, including cross-validation and confusion matrix analysis, which confirmed its ability to generalize well across unseen data.
- SarahOkay, 92 percent, nice. But what dataset did you use, and how did you define your evaluation? For example, what was the validation set size, and what did your confusion matrix show about specific classes the model struggled with?
- CandidateFor LeafScan, I used the PlantVillage dataset, which contains thousands of labeled images of different plant diseases. I split the dataset into 80% for training and 20% for validation, ensuring a diverse representation of classes. The confusion matrix revealed that the model struggled particularly with a few classes, such as bacterial blight and leaf spot, where it had higher false-negative rates. This insight led me to augment the training data for those specific classes to improve overall performance.
- SarahThat’s a good detail. When you say you augmented the data for those specific classes, what kind of augmentation did you apply? Was it rotations, scaling, or something else? And how did you confirm it actually helped, not just increased accuracy?
- CandidateI applied several augmentation techniques, including rotations, horizontal flips, and slight zooming, to increase the diversity of the training data for the underperforming classes. To confirm that the augmentation helped, I conducted a controlled experiment by training the model on both the original dataset and the augmented dataset separately. I then compared their performance on the validation set, and the augmented model showed a noticeable reduction in false negatives for the problematic classes, as well as an overall increase in accuracy, indicating that the data augmentation was beneficial.
- SarahOkay, thanks for that. Let’s pivot to your internship. In BrightApps, you mentioned cutting a slow report query from four seconds to three hundred milliseconds. What exactly did you change, and how did you measure the improvement?
- CandidateTo optimize the report query at BrightApps, I analyzed the SQL execution plan and identified several inefficiencies, including missing indexes and unnecessary joins. I added appropriate indexes and restructured the query to reduce complexity, which significantly improved performance. I measured the improvement by running the query multiple times before and after the changes, using a performance monitoring tool to track execution time, confirming the reduction from four seconds to three hundred milliseconds consistently.
- SarahOkay. That’s clear. Let’s move to your internship again. You also mentioned adding CI checks that caught regressions before release. How did you design those checks, and what kind of regressions did they catch?
- CandidateI designed the CI checks by implementing automated testing for both unit tests and integration tests within our CI pipeline using tools like Jest and Cypress. These tests covered critical functionalities, including user interactions and API responses. The checks caught several regressions, including broken UI components after updates and issues with API endpoints returning incorrect data, preventing these errors from reaching production and ensuring a smoother release process.
Unedited recordings of a full interview, start to finish. The candidate answering is a scripted test profile, not a real student, so nobody's interview is being shared here.
What campus-hiring teams get.
Standardized interviews
Every candidate gets the same questions at the same depth. No panel fatigue, no interviewer luck deciding who advances.
Grounded in your role
Upload the JD and required skills. The AI asks from them and grades against them, not a generic question bank.
Resume-aware follow-ups
It reads each resume and probes the specifics: that final-year project, that internship, that skill they claimed.
Comparable scoring
One rubric across the whole batch, so a score means the same thing for every candidate and every college.
Detailed reports
Per-question feedback, communication quality, pace and filler words: the evidence behind every score, not just a number.
Before the visit, or round one
Run it as a pre-screen before you travel, or as a standardized, recorded first round on the day of the drive.
Where teams put it to work.
One screening layer, dropped into the parts of a drive that don’t scale with people.
Pre-screen a batch before you shortlist
Cut three hundred applicants down to a ranked shortlist before a recruiter reads a single resume.
Standardize the first round
Give every candidate the same technical or HR screen, scored the same way, whoever is on the panel.
Assess against a specific role
Hiring backend engineers and analysts from the same batch? Each candidate is measured against the role they applied for.
Compare across colleges on one rubric
Run the same screen at every campus and rank candidates on a single, shared yardstick.
Save recruiter travel and hours
Send people to the shortlist, not the long list. Fewer trips, fewer repeat first rounds, more time on the candidates who matter.
Why it holds up at scale.
- Consistency
- No interviewer variance. The fourth interview and the four-hundredth are graded to exactly the same bar.
- Scale
- Hundreds of candidates interview in parallel. Your capacity stops being the number of recruiters in the room.
- Speed
- Reports land minutes after each interview ends. The shortlist is ready while the drive is still on.
- A fair rubric
- Seven categories, scored out of 100, combined by fixed weights and fixed thresholds written into the product. 70 and above is a pass. The same answer scores the same way every time, not on a gut feel.
Built to be defensible.
You’re assessing real students, and their data comes with obligations. Confidash is built so you can stand behind how every candidate was recorded, scored and stored.
Candidate consent
Every candidate agrees to be recorded and assessed before the interview begins.
Access is logged
Every time someone opens a candidate’s audio, it is written to an access log.
Bounded retention
Recordings and reports are kept for a set window, then removed. You choose the window.
Nothing trains models
Candidate audio, transcripts and resumes are never used to train AI models.
Priced to the way you hire.
No seats and no annual lock-in. You buy screening credits. One credit is one 30-minute interview including its scored report, and credits never expire. Tell us the shape of your drive and we'll quote it.
Real-time conversational voice: interruptions, follow-ups, the closest to a live panel.
Read the transcript
- SarahHi John, this is Sarah from the interview. This is a general round, about five minutes, and we’ll start with a brief introduction. Tell me a bit about yourself, your background, interests, and what you’ve been building lately.
- CandidateHi Sarah, I’m John Doe, a final-year Computer Science student at Sunrise Institute of Technology, where I’ve maintained an 8.4 CGPA. I’m passionate about full-stack development and have recently worked on CampusConnect, a networking platform for students, where I led the development using Next.js and Node.js. I also developed LeafScan, a plant-disease detection web app utilizing machine learning with TensorFlow. In my recent internship at BrightApps, I focused on optimizing performance and implementing CI checks for React and Node dashboards.
- SarahOkay, let’s focus on CampusConnect since you mentioned it. Out of curiosity, what parts did you build yourself from scratch, and what was the hardest bug you ran into while implementing it?
- CandidateIn CampusConnect, I built the entire user authentication system and the real-time chat feature from scratch using Socket.io. The hardest bug I encountered was related to message synchronization, where messages were not consistently appearing in real-time for all users. After extensive debugging, I discovered an issue with how we were managing WebSocket connections, which I resolved by refining our event handling logic to ensure messages transmitted correctly across all clients.
- SarahGot it. You mentioned fixing message synchronization and the WebSocket connection handling. What exactly did you change in that event handling logic, and how did you verify that all clients were consistently seeing identical messages?
- CandidateI modified the event handling logic to ensure that each message sent from a user was acknowledged by the server before broadcasting it to other connected clients. I implemented an event confirmation system that allowed the server to track which messages had been sent and received. To verify consistency, I set up automated tests that simulated multiple users sending and receiving messages simultaneously, and I monitored the logs to ensure that all clients displayed identical messages in real-time. This thorough testing confirmed that our synchronization issue was resolved.
- SarahNice, that sounds solid. Let’s switch topics. For LeafScan, you mentioned a CNN and TensorFlow. How did you train and evaluate the model, and what kind of accuracy or confidence did you achieve before you felt comfortable shipping it?
- CandidateFor LeafScan, I trained the CNN model using a dataset of plant images labeled with various diseases. I used TensorFlow to build and optimize the model, experimenting with different architectures and hyperparameters. After multiple training iterations, I achieved an accuracy of around 92% on the validation set. I felt comfortable shipping the model after extensive evaluation, including cross-validation and confusion matrix analysis, which confirmed its ability to generalize well across unseen data.
- SarahOkay, 92 percent, nice. But what dataset did you use, and how did you define your evaluation? For example, what was the validation set size, and what did your confusion matrix show about specific classes the model struggled with?
- CandidateFor LeafScan, I used the PlantVillage dataset, which contains thousands of labeled images of different plant diseases. I split the dataset into 80% for training and 20% for validation, ensuring a diverse representation of classes. The confusion matrix revealed that the model struggled particularly with a few classes, such as bacterial blight and leaf spot, where it had higher false-negative rates. This insight led me to augment the training data for those specific classes to improve overall performance.
- SarahThat’s a good detail. When you say you augmented the data for those specific classes, what kind of augmentation did you apply? Was it rotations, scaling, or something else? And how did you confirm it actually helped, not just increased accuracy?
- CandidateI applied several augmentation techniques, including rotations, horizontal flips, and slight zooming, to increase the diversity of the training data for the underperforming classes. To confirm that the augmentation helped, I conducted a controlled experiment by training the model on both the original dataset and the augmented dataset separately. I then compared their performance on the validation set, and the augmented model showed a noticeable reduction in false negatives for the problematic classes, as well as an overall increase in accuracy, indicating that the data augmentation was beneficial.
- SarahOkay, thanks for that. Let’s pivot to your internship. In BrightApps, you mentioned cutting a slow report query from four seconds to three hundred milliseconds. What exactly did you change, and how did you measure the improvement?
- CandidateTo optimize the report query at BrightApps, I analyzed the SQL execution plan and identified several inefficiencies, including missing indexes and unnecessary joins. I added appropriate indexes and restructured the query to reduce complexity, which significantly improved performance. I measured the improvement by running the query multiple times before and after the changes, using a performance monitoring tool to track execution time, confirming the reduction from four seconds to three hundred milliseconds consistently.
- SarahOkay. That’s clear. Let’s move to your internship again. You also mentioned adding CI checks that caught regressions before release. How did you design those checks, and what kind of regressions did they catch?
- CandidateI designed the CI checks by implementing automated testing for both unit tests and integration tests within our CI pipeline using tools like Jest and Cypress. These tests covered critical functionalities, including user interactions and API responses. The checks caught several regressions, including broken UI components after updates and issues with API endpoints returning incorrect data, preventing these errors from reaching production and ensuring a smoother release process.
Every screening runs this voice. The candidate here is a scripted test profile, not a real applicant.
Per candidate
Pay for each candidate screened. Best when volume swings from one drive to the next.
Per drive
A flat rate for the whole batch at one campus. Best for predictable, large drives.
Not sure which fits? Run a pilot on your next drive.
We’ll help you set the role and rubric, screen a real batch, and you’ll see the shortlist before you commit to anything.
See it on your next drive.
Send us the role and the batch size. We’ll set up a pilot and show you what a consistent, scored shortlist looks like, before your recruiters pack their bags.
Per-candidate or per-drive · billed by invoice.