Not OP, but I would love to share some: I relate strongly to the anxiety induced descriptions in OPs text and thus try to avoid these when I interview devs as an engineering manager. Of all the candidates I have interviewed over the years I have never done a live coding interview because it is essentially worthless for me as an interviewer and only serves to discards potentially very clever people whose thought process does not work this way.
Instead I try to find an isolated problem/task we have in our backlog that the candidate should try to implement on their own time, so I can review what kind of solution they will actually deliver once hired. We then go through the solution with them and do a code review as they would go through if they got hired. You then see both the problem-solving skills as well as how they take feedback.
I would recommend checking out DuckDuckGo's excellent "How we hire" guide[0] which describes some of the best hiring process I have come across (albeit it may be too extensive to do in full for some companies).
So how do you know they did it on their own? Spouse is a developer, helps them out, explains everything. Then on the job there is no spouse, and it all goes to shit. Not saying this would be every time, but you might come across one of these.
We have an initial Hacker Rank 'filter', that if you don't pass that, we don't even do an interview. A few weeks ago we interviewed someone who passed that filter very well. But in the interview, it was really below par. Not even the basics were understood. So I'm very skeptical about these kinds of homework where they could get help.
What I currently do is go through a very simple coding example that I wrote (very generic). Then we go through the code and I ask questions like "can you explain what this line is doing", or "If I move this line over here, is the behavior still the same", etc. Some bugs are in there and I ask what is going wrong and how to solve them.
Not ideal, but the problem is that nothing really is :(.
I think this person has a better idea because your spouse scenario, while realistic, can easily be detected while you discuss the code being presented.
You may have good intentions but what do you equates to "I don't trust you, bro/sis". Not a great way to start a relationship imho
> can easily be detected while you discuss the code being presented.
That is possible of course. But if they wrote the code together, and know they will question later, you could teach the other person all the trade-offs etc. I could see myself doing that with a bad developer and get them through such an interview.
> Not a great way to start a relationship imho
Well, you could take the benefit of the doubt, and then when it seems they did cheat, just fire them. But firing is always such a big decision.
Isn't that why managers get paid the big dollars, to make the big decisions?
The whole rhetoric of the tech industry — taking risks, creative destruction, etc. — seems to completely fall apart when it comes to hiring, where everyone turns fearful and ultraconservative.
Have you ever worked with a really bad hire? Someone totally incompetent at doing the job? In my personal experience, that person completely tanks the productivity and moral of the entire team. I’ll also point out you are not doing that person any favors by hiring them and firing them one month later (if your org is even capable of doing that). Bad hires are disastrous.
> In my personal experience, that person completely tanks the productivity and moral of the entire team.
A bad manager completely tanks the productivity and morale of the entire team too. And you can't fire your boss, you can only quit your job.
> I’ll also point out you are not doing that person any favors by hiring them and firing them one month later (if your org is even capable of doing that).
Not sure how it's relevant whether you're doing the incompetent person a favor or not? Hiring isn't about favors, it's an exchange of money for work. If there's no useful work, then the money has to stop.
> Bad hires are disastrous.
Seems a bit overstated to me. Do you have any examples of companies put out of business by a bad programmer hire?
Coders come and go. Is it a "disaster" if your best coder leaves for another job? We're treating hiring as if it were like marriage and divorce, but it's not. When you hire someone, it's not "til death do us part". Breakups are expected.
Too many companies make hiring much more difficult than it needs to be. They overthink it, and also waste way too much time on it. Find someone who seems right for the job, and hire them. If they don't work out, get rid of them and hire someone else. You might get unlucky at times with a bad hire, but you might also get lucky with an unexpectedly great hire. If you can't correct your mistakes quickly, that's a problem with your company's culture, not a problem with job candidates. I would argue that it's not a bad hire that demoralizes a team but rather a bad company culture that's incapable of correcting mistakes.
You're answering in a vacuum. The previous poster is saying that just hiring easily with a view to firing if they're bad is destructive. Talking about managers is irrelevant to this. It's not one or the other.
This, probation time + take home assignment + discussion = I can filter out almost all the false negatives of the take at home. Give the people a choice between take home assignment and more classic code interview so you can dodge problems like shitty home-offices, strange contracts clauses but the real deal remains the probation time.
> Instead I try to find an isolated problem/task we have in our backlog that the candidate should try to implement on their own time,
And in this case you're eliminating people who aren't willing and/or able to spend time preparing for your interview process. One of my previous jobs had a clause in the contract that all my programming work belonged to my employer; is your company going to sign a waiver that says they take responsibility if a previous employer sues? Doesn't matter whether or not it's enforceable or not.
What if you use that solution in production, do you compensate for their time in helping solve the problem like you would if the task was assigned to you?
Also, you're not really setting a level playing field here. How do you gauge a candidates experience/seniority versus the other 10 candidates you hired if you're not asking them the same questions or looking for the same things. Maybe I've solved that bug in my current job.
All this is to say that this doesn't "just fix" hiring - I don't know if it's any better or worse than giving people on-site tests, but you're at the very least trading one set of problems for another.
It might not "just fix" hiring, but at least it doesn't blinding accept the status quo and attempt to engineer an alternative that can then be evaluated. We are supposed to be scientists, are we not?
As someone doing mostly C development at work I've really come to enjoy Zig in my side projects at home. At work we are moving a lot of newer development to Rust, which makes sense in terms of safety, the speed we want from C and "modernising"/becoming more attractive as an employer. However, when I'm doing projects for my own amusement at home I want something that doesn't feel like work, and getting into Zig and have something working took me no time. It's so easy to interface with C libraries that I can spin up most things with existing C libraries for the things Zig doesn't already provide itself.
Yep, exactly. I was originally pretty excited about Rust, but I feel like it biases toward large highly-structured projects like C++ does, making it a bit daunting for personal projects. Just a bit too professional for something I'm hacking together over a weekend, lol. Zig feels like it's easier to wrap my head around, and seems optimized for the "pet project" use case.
I also feel like learning Zig is helping me better understand C. I probably wouldn't have been able to contribute much to that Wine patch if Zig hadn't already gotten me more comfortable with pointers, statically-allocated variables, and such in a reasonably-safe way (having prior experience with Perl did help a little bit for pointers, since referencing and dereferencing variables is pretty common in Perl codebases, but it always felt a bit detached from what the machine was actually doing behind the scenes).
Started on these at mid-March when the recommendation for quarantine came in effect in my country. Most are incomplete and WIP (I love switching back and forth between projects):
- Slack RTM bot which picks up my morning and goodbye messages in our channel and stash the duration into our time registration system so I don't have to do it manually. Using Slack library for Go, compiled to C library using gccgo for C ABI compatibility, then using Zig's cImport functionality to develop the bot in Zig (because why do it the easy way)
- mbedTLS bindings to Zig (Zig can generate alot of this out of the box, but I'm tailoring it by hand)
- HTTP/1.1 client in Zig, ties into the mbedTLS bindings I want to provide TLS support
> Then they just decided to shut down 2 of our newest customers and hold 100% of their funds ransom for 180 days
So Braintree supports payments through a number of providers, credit cards and PayPal, Apple Pay, etc. When you say they hold 100% of their funds, is this for PayPal payments via Braintree, or is it also credit card payments (i.e. payments directly to Braintree)? In other words, are the 100% fund you mention stored at PayPal?
The reason I'm asking is because Braintree does credit card disbursement a couple of days (or something like that) after a credit card payment has been performed. So if they shut a customer down, wouldn't they "only" hold the money from the first transaction after the last payout, till the shutdown occured? In other words, if the last payout from Braintree happened on Monday, and there was another transaction on Tuesday due to be paid out to the merchant by Braintree on Thursday, and Braintree shut them down on Wednesday, this would mean the "100% funds" mentioned is the transactions happening on from Tuesday till Wednesday, since they were shutdown on Wednesday?
I hope the question make sense! Just trying to make sense of this :-) (using Braintree as well, but not Marketplace)
I gotta say, I'm pretty impressed with how Microsoft go in for supporting all these relatively new technologies on their own stack. Considering what they've done in the past.
It's easy to forget that MS is made up of real people too--people who go home and boot up a Mac and code in Ruby in their spare time. Genuine change is happening at MS from the inside. MS knows it can't afford to lose the mindshare battle in the youth.
Instead I try to find an isolated problem/task we have in our backlog that the candidate should try to implement on their own time, so I can review what kind of solution they will actually deliver once hired. We then go through the solution with them and do a code review as they would go through if they got hired. You then see both the problem-solving skills as well as how they take feedback.
I would recommend checking out DuckDuckGo's excellent "How we hire" guide[0] which describes some of the best hiring process I have come across (albeit it may be too extensive to do in full for some companies).
[0] https://duckduckgo.com/assets/hiring/how_we_hire.pdf