That is not always possible. There is always an NDA in contracts. Imagine me going around and revealing the code I have done for your company...
3.
Are you going to pay extra those two engineers of your company for doing something that is clearly outside what they were hired for at beginning or outside their competences?
4.
The same as 3. Are you going to pay those employees for doing manager work instead? Or the managers of your company are paid for doing nothing while showing doing something and soon ready, as in your message, to download their responsibilities to simple engineers (company's leaves )?
Edited.
It’s really not that weird to have the team decide who they want to join their team
This is not kindergarden anymore. We're taling adult stuff here. If the manager is not able to interview, analyse and understand who is in front of him, then it is time to change job.
Iff the candidates has personal work to show then it is considered a plus, but it is not madnatory.
3. No, normal wage and is expected of them.
A hired person is supposed to fill a role and not a double or more roles just because the manager is not able to subdivides tasks, roles etc. I don't expect engineer or technical roles to do manager job.
4. That’s not manager work. It’s a tech talk, it needs to be with the tech people. It’s really not that weird to have the team decide who they want to join their team
It might work in your culture.
in my culture, who is going to take a manager role _manages_ technical people _and_ as such he _must_ know the technical stuff to a certain degrees otherwise the job is not for him. Here managers don't download their responsibilities to engineers they manage.
At the same time, engineers are not supposed to judge or like or dislike their coworkers. Working in a team is a prerequisite that they have to accept, either you like it or not. Full stop. There is no space for interpretation or for leisure. They have tasks and they finish their tasks. Full stop.
3. We do not fill multiple roles. But if a person might join your team, the team gets to talk with the candidate. This always also becomes a tech talk because we’re developers and we like talking about it. That’s not a second job role at all.
4. Our managers are tech people. They are not always actual developers though, or might’ve been 20 years ago.
In general it goes like this: Junior? - talk with manager and tech lead of the team, just about who you are, what you’ve done and what you’re looking for. All to see if you are a match personality wise. - if we liked the talk you get invited for a technical interview. You go sit with the team as they work, you get to do some challenge. We’ll help you and discuss your solutions - we all together decide yes or no
For experienced developers we have the same, minus the coding challenge. The talk with the team is more about the personal match, but it usually is about tech stuff or what we’re working on because the candidate is curious.
I find it very natural and relaxed. The team eventually decides themselves which candidate they prefer.
Also I have no idea what you mean by there not being time for leisure. With us there definitely is, and liking the team you work in is very important to us. If you don’t like it or it’s not working we might place you in a different team where you match better. Or maybe you don’t think the apps we work on are interesting, but those of another team are. Why shouldn’t working somewhere be enjoyable?
However, here we are talking about at the general level. Not a single instance as your experience.
Engineers are hired for engineering jobs not for manager jobs or mopping the floor.
On the other side, if a lately hired person wasn't find himself comfortable inside the team, I, _as manager_, can always complain the team and accuse them being guilty because they weren't able to say NO at interview level or because they said YES at the wrong candidate. Do you see the faulty thought of our time? I as manager earn a lot for managing people but in reality I download my responsibilities of not being able to interview a candidate and so find the right person _downloading_ that on the team that actually is not responsible for new hired person. Fantastic.
Than's the meal they want you digest in some cultures. In mine, as manager, I decide who is on board, and I clarify clearly the roles of every one. No space for interpretation.
I din't come out from a manager school, but I started from the ground and I put myself _every time_ in the shoes of who is managed by me.
My humble opinion
Why is it outside (and not just outside, but clearly outside) of what they were hired for or what their competencies are? Engineers work on the product. Engineers review each other's code. Engineers are a stakeholder in this whole process — after all, the candidate may become their future colleague, and engineers are best positioned to know what they want to see in a prospective colleague. Engineers can appreciate whether their peers have the desired skills.
Why does this activity require a higher pay than developing a new feature with your teammates?
During the past decade, that has been as a “senior” employee of some sort. By senior I don’t mean just “I codez real gud”.
That has meant:
- Being on calls or flying out to a customer’s site to support sales in closing deals when I was working with B2B companies and later full time working at consulting companies.
- Interviewing candidates
- leading teams and come project management work.
- hands on keyboard coding
- DevOps [sic] setting up architecture for empty AWS accounts.
But I’m always up front about tradeoffs to management. If they want me to do one thing on the list, there is an expectation that something else on the list won’t get done. I don’t put in more than around 40 hours a week aside from the infrequent business travel.
Caveat: I hate the concept of HR and the phone screen is an excuse to waste their time instead of mine. Also none of this applies if you have < 100 employees.
> At home coding challenge
I get where you're coming from, and I've tried to fight to get people paid to do our take homes because I also feel it's only fair if we're expecting them to spend ~3 hours of their own time, but you also end up in situations where people will do the interviews just for the money. We had a small trial run with a pretty laughable sum, something like 40 bucks just to test the waters and see how people reacted (this was for a very high paying role, mind you), and we got a staggering amount of people who clearly didn't care at all about the role and just wanted the free money. Like literally would just post a link to a random repo or whatever, completely unrelated to the takehome, and you as the company don't really want to be in the situation where you argue with candidates about what constitutes a "real assignment" for the purposes of payment.
It's one of those situations where a handful of dickheads can ruin a good thing for the decent folk.
At least personally, I dedicate as much time to reviewing the takehomes as the candidates themselves put in. I write extremely detailed feedback covering every single line they present us and we supply that feedback to candidates regardless if we're moving forward with them or not. Also importantly, in the candidate gives us an actual assignment, we always move them through to the discussion part of the interview, except for cases where the assignment was basically not done at all or was egregiously terrible. I feel mixed on this one, because sometimes it's clear from the assignment that chances are slim for the candidate, but I've also seen some pretty bad takehomes end up with super strong hires at the end (and vice versa!) from the discussions.
HR even tells me that a few candidates reached out and wanted to thank me personally for the feedback I gave them even when they didn't end up getting hired, so at least from what I can tell people don't mind the way we do it. I personally fucking hate doing interviews, regardless of which side of the interview table I'm on, so at least when I'm the one doing the breathing-down-the-neck thing, I try to make it as good of an experience as I possibly can.
IMO it's the fairest interview method, and the one I personally prefer to do when I'm the one interviewing (as in, when I interview for jobs). In my experience it's always been pretty obvious that the takehomes aren't for any actual work (obviously I can't speak for everyone here, I'm sure it does happen) and it's always a pretty made up scenario that is loosely tied to what the domain is. I know that it can be unfair for people with a lot on their plate, at least I've been lucky enough that 2-4 hours out of my week is pretty doable, and especially compared to something like leetcode (which most people still have to study for, so the 2-4 hour thing is pretty moot IMO) it's just incomparably better. I've tried doing "just talking" types of interviews, but there are a lot of good bullshitters out there, so there has to be some type of actual programming just to weed them out.
Ask yourself why not
Which is a reasonable stance to take! But not if you want to be paid for take homes, but not for interviews.
I think any reasonable person can interpret that there is a meaningful difference between an hour of work and several. The same way you might drive your friend across town for free but you're probably going to ask them for gas money and some beers if they ask you to help them move across state. An hour of my time is just less valuable than my entire day.
I honestly disagree with the veto right because it makes it too easy to be abused. In my opinion, a supermajority (66% or even 75%) agreement should be sufficient. They said that Liberum Veto rotted the Polish-Lithuanian parliament.
The hiring manager had the ultimate say, though. But he/she had to acknowledge, address, and own any objection and take personal responsibility for it if the candidate was hired.
When you have a good team who is earnestly focused on preserving a good team, it works really well. Red flag objections were pretty much never ignored, and were effectively vetoes. Minor objections or slight concerns about experience or aptitude, if they were overridden, prompted hiring managers to take extra time and care to help ensure the new hire's success.
I won't do a coding challenge unless you do mine too. Don't they always say interviewing should be mutual evaluation?
Here's the deal: You give me your standard coding challenge, then we reverse roles for an equivalent one I prepared. We do this for the full interview duration.
If you can't solve mine, that tells us something important about the technical bar at your company. After all, if coding puzzles are truly predictive of job performance and essential for determining candidate quality, then presumably everyone on your team, and especially those making hiring decisions should excel at them... ;-)
If your coding challenges are going to determine my professional future, and your company claims it only hires "the best," then you should have zero problem demonstrating that same level of excellence. I wouldn't want to work somewhere where the interviewers can't meet the standards they are imposing on candidates.
Either these challenges are meaningful indicators of ability (in which case you should welcome the chance to prove your team's competence), or they are arbitrary hoops and in that case, why are we doing this?
From our experience just posting a junior web developer job gets up to 1000 resumes into our inbox. And we just a small company without an established name.
The only possible first step for us is to automatically send everyone an at home coding challenge. This narrows down the list to only about 50 developers that would reply. Only 10 of them would send working code. And only at that point we can actually start to interview.
1. 60 minutes interview with the CTO.
2. At home coding challenge. Candidates can pick one from 2 coding challenges. But we try to keep them engaging and fun, but still complex in details. Sometimes people don’t want to invest this time. That’s acceptable, but in this case you have to show os some of your work from the past, so we can discuss this.
3. Interview with 2 engineers from the team. We are doing coding challenges as a base for this interview. It’s just a way to get people talking with each other on technology and how they work.
4. Make an offer or say no to the candidate. Everyone involved in this process from our side has a veto right. So if one person says no - it’s a No.
5. Send contract to the candidate, if they accept the offer. This is the first time in the process where HR is involved. Everything else before was done by the Dev Team.
I think this is the most important part, show respect by taking care of the process by yourself and communicating with the candidate.