kindi
kindi

How would you fix tech hiring?

Different companies follow different methods to choose their workforce, so if you've given/taken couple of interviews yourself can you provide insight on how you do it and why you think it works? Also what would you change about the general process of tech hiring?

Let me go first. 0. (obvious, but) Minimal weightage for DSA - When I conduct interviews, I rarely ask DSA problems. It rarely gives me an opportunity to assess the candidate's breadth of knowledge, and come to a conclusion of how much experience they have with the tasks that they're going to do on the job. What if they've practiced the same problem / variation of the problem that I ask? I want to assess technical competence, not their acting skills.

  1. (debatable) Culture fit should be given a higher weightage than skills - Skills can be learnt, behavior and character takes time to build. It most often hinders the progress of the team.

  2. Stop setting standards for the interview that your team doesn't follow in the first place - I've had friends who had to pass interviews of high standards only to work in shitty teams. They were yearning for an achha din but it never came.

Your thoughts? Nothing's wrong here, please be open to discussion.

10mo ago
tbk
tbk

How about starting with not ghosting and sending everyone who applied a online test link then later comes the interview

Anon00
Anon00

0- Companies ask DSA because they don't have interviewers with breadth knowledge who can interview on candidates experience. DSA kind of bails them out.

For example, once I was interviews by a developer for a architect role in a startup. He knew jack shit about system design, he wanted me to tell we can compress the data by 90% in a flat file, after I explained complex threading mechanism and data lakes on his problem statement. He was a fxxcking react developer and told me they used react over python because you can hey know server side binding and CDNs can cache it. I showed none of his pages has server side binding and asked him how does he configure a request directed at his site to route through CDN for caching. He wouldn't know.

Result - Rejected.
I felt DSA would have been far better

  1. I would say it is more like having a team who have similar knowledge and abilities. That gels the team and produces a far bigger output than sporadic individual achievements
r10a
r10a

I feel DSA is a necessary evil at scale. If you are hiring and interviewing 5-10 candidates, low bar for DSA might work. But if you get thousands of application, DSA sort of saves the day.

But this is unfair to candidates, so we moved to mandate only easy questions for DSA and one medium-hard question that won’t be graded. This is good, but i’d couple this with an MCQ round asking questions about the framework that we are using.

Just this should set enough guardrails to filter candidates who can code.

Next, I would emphasise on communication. It doesn’t matter if you’re the best developer, if you can’t sell me your solution. You should be able to speak about your solution, know its pitfalls, convince another person it is good enough. Very similar take, comprehension. You need to understand problem statements before you write the first line of code. Assumptions are expensive and often counter productive. Here, I’d also like to know how much the person was involved in their older job. Are you a code monkey or did you understand your end-user and then build solutions?

Once these three boxes are checked, I’d like to do pair programming on a half-built app. It would probably take you a day or two to create a repository that has a simple half-done app. You can either write unit test cases for unimplemented methods and let the candidate fill it up in an hour to make the test pass, or actually write pipelines to deploy changes so that the other person can test their changes in front of you.

But this takes immense efforts for the interviewer and this can be gamed too. The ROI for the company hiring isn’t great, which is why DSA works at scale.

I could do this for maybe 10-15 candidates. Unless we build a team that only builds problems like this and does technical recruitment and assessment, we’d probably end up having good developers just play the interview game everyday. Because in this process, the interviewer has to know at least as much as the interviewee.

Discover more
Curated from across