Maybe of topic, but: I find it interesting that the author lists user experience in his "what I would like to talk about" list yet uses super bright yellow as background .
I found it surprisingly comfortable to read :)
How not to hire a software engineer
51–60 of 239 posts
Re: How not to hire a software engineer
#52#1 thing for me - don't ask me to be a salesperson. In relation to this post - https://news.ycombinator.com/item?id=19534772 I was recently at an interview and the interviewer was a technical guy who had recently been promoted and he had a checklist of 10-15 things he wanted to achieve in the next half year, all really good reasonable things and then he said 'Now I just want you to tell me why you are the best person…
I actively say things similar to what you said. For example, if I’m ever asked why I want the job or why I’d be a good match at the company, I will always say I don’t know. I’ll always say I’m not trying to be facetious or dodge the question, but with limited information from a job listing, maybe a few phone calls, and a day of small 1-hour interviews (that are mostly made up of coding questions with no time for me to ask questions), then it’s just not possible to give a sincere answer that has any more depth than a rehearsed answer based on LinkedIn advice listicles or something.
Re: How not to hire a software engineer
#53If I had to interview someone for a programming job, I think I'd try using LeetCode problems, but NOT as coding challenges. I'd pick a few problems that the candidate and I both find somewhat interesting, and then for each do three things.
First, we'd both read the problem, and talk about our understanding of what it is asking for.
Second, we'd talk about algorithms to solve it, probably at a whiteboard. No need for actual code, or even pseudocode. Anything that gets the ideas across would be fine. Somewhere in here we'd also talk about what cases are tricky and what we would need to do to make sure any test input we were to write would cover them. I'd try to let the candidate drive this, but would provide sufficient hints and nudges to get to a solution and not count needing that against them--this is really just setup for the third part, which is the most important part.
Finally, and most importantly, we'd go to the LeetCode discussion area for that problem and look at solutions people have posted and review them together. Many of the solutions will have mistakes, ranging from minor to major, and trying to spot those together and talking about how to fix them would, I think, give good insights into both the candidate's technical abilities and how they work with others.
Re: How not to hire a software engineer
#54What i've noticed recently with interviewing candidates is some lack the ability to work outside the way they work normally, especially in practical tests. Things like, "I usually work from home, so its too difficult to concentrate in this meeting room", "I use Windows, so writing code on a Mac is really hard" and the most common for some reason for why the technical exercise isn't working "Intellij usually saves the…
If you're a complete novice with Windows, using a Mac for the first time will be similar.
If you have years of muscle memory and shortcuts and knowledge about Windows OS, switching to Mac OS will be painful. Not least the different Cmd/Ctrl keyboard placements and shortcuts.
Also, those universal text editing/navigation shortcuts on MacOS?: they're emacs shortcuts which don't exist on Windows OS.
Re: How not to hire a software engineer
#55Get them to ask a question on stackoverflow without it being closed or put on hold or marked as a duplicate.
So you want to never hire then?
Re: How not to hire a software engineer
#56Honestly these days I'm thinking that the best interview is going to be about people's attitudes and opinions. e.g. I usually ask things like what's your favourite source control system, branch technique etc? Why? There's no right answer here, other than to show thought and understanding of the engineering problems this is seeking to address. Obviously there should be some domain/framework/language specific things in…
Ha! It’s nearly impossible to fire someone where I work, and the contractors ride out their full contract which is often a year. It’s a shitshow
Re: How not to hire a software engineer
#57I look to see if I can trust them to not do dumb things. That's really it. What's the ego, arrogance, competence, willingness to ask questions, interrogate things, redefine problems to be less work (or none at all). Do you see what's not there? Programming language competency. Database knowledge. Things like that. I've been hired as a Ruby programmer, I didn't know Ruby. I was hired for mainframes in the 90s - I had…
> ability to learn, not to create a mess and not to waste time on stupid things
People do stupid things and create a mess, while they learn.
Re: How not to hire a software engineer
#58Here's an idea for how to actually do a technical test (if you do want to do one). 1. You bring the candidate in to your office. You have their future desk already available with computer and development environment already functional. Pick a somewhat standard environment configuration. 2. Have an exercise already prepared. Best option is not a "build this from scratch" but have something that already works and needs…
Thanks! This is a nice approach which I will try with our next front-end-candidate.
Currently our process consists of three exercises: A small website-layout where the candidate has to fix two styling-bugs and equalize some container-heights (CSS-Part); a Palindrome-Function (JS-Part); and a discussion where we look at a webpage-layout, and go through how they would structure it HTML/Component-wise and talk about general topics that come up. But I like the colleague-like approach of your way and guess that it'll work better in our case.
Can you name an example of an app which the candidate has to extend?
Re: How not to hire a software engineer
#59Re: How not to hire a software engineer
#60Here's an idea for how to actually do a technical test (if you do want to do one). 1. You bring the candidate in to your office. You have their future desk already available with computer and development environment already functional. Pick a somewhat standard environment configuration. 2. Have an exercise already prepared. Best option is not a "build this from scratch" but have something that already works and needs…
In all my years of interviewing (~25), I've only had this happen once - I got sat in front of an internet connected laptop, given a perfectly sensible task, and left alone for half an hour. Most of the time it's "solve this already thoroughly solved problem in your own time but with {one hand in a blender, whilst you're on fire, without using any variables}" or some such bullshit.
About the same - I had one 'interview' where I had to write a client and server in C++ that would allow clients to register network MAC addresses with the server along with some associated data and then retrieve it at a later time.
Took me a couple of hours, interviewer said my code wasn't particularly "object oriented" but I got the job.
The irony of this was it was for a Director of Engineering job where I didn't do any coding! :-)