Recently I did some interviews for companies that call themselves "human focused", but in the time they need to show their humanity and respect they just forget it.
I do understand that in this market we have a lot of dev that are "underqualified" but we too have a lot of jobs that are "overspecified", so we both have problems.
When a company ask a developer to make a live code in 30 minutes of unexpected problem, as a developer you have 90% of chance to fail, not because you can't do what they asking you, but because of the external enviroment, like, engineers watching you, anxiety, impostor sydrom, and much more.
- Interviwer: Hi, please share your screen... So... this is the challenge, we expect you finish in 30 minutes, you can start when you're ready.
Developer starts working and see himself being anayzed by two engineers seeing each keystroke he makes, he wants the job, the anxiety starts, the code don't run, the mind get blank and... he fail.
- Interviwer: Okay, I think we can stop here. I think you are not qualified for what we want, we expect someone fluent on this, and you're not prepared, maybe in the future. Good Luck, bye.
Now I ask you, fellow devs... Is this fair? Your experience and skills just being throw on trash by a company, just because you can't acomplish something in a stressfull enviroment in 30 minutes? Something that in a daily work situation you could have done it without problems. I find it at least disrespectful.
If you are a tech recruiter, I'll tell you what could be a better (and the right) way of doing an interview.
Put the Tech Lead or engineer to talk with the candidate, and ask questions about his experiences, it will give you about 50% you need to know.
Ask him to show you some project that he's proud of, and ask questions based on it. "The candidate will love tell you about it".
Send home-tests AWAYS based on the experience that the role REALLY needs or based on the candidate experience with at least 2 days to finish. (not a computer science algorithm to calculate the air volume of earth).
Finally, be human. Humans have depression, anxiety, stressful days, humans forget things, humans fail. These types of stressful hiring process can never judge the talent and experience of a professional.
My name is Jean, I'm a senior full-stack developer. I code, I manage, I design, I create, I help the team, but... I'm not perfect! I fail, I still have so much to learn, and... I'M NOT A ROBOT. If your company need a "thing", that code anything besides any human and external enviroment problems in less than 30 minutes, make a bot yourself, or hire me to make it for you.
Top comments (28)
I did that once, time limit was one hour, the tasks were not so hard to archive. Then the last acceptance criteria was:
And I asked: which file, the one I am working on or the whole, including react, react dom, minified or not, etc.
They answered: the file I am working on only.
Me: how can I see that in this VM you gave me? There is only access to the editor view, but not to the filesystem, like open file window.
They: you are right, we don't know how this VM works. Sorry.
I failed the test, and didn't get an answer why. Maybe the file was too small?
After the result I was glad to fail it. What would they expect in the future? Develop a quantum server within one sprint as a janitor?
There are plenty of companies out there use ambush interview methods.
A recruiter presented an opportunity with Fidelity Investment, and told me she’s had several candidates who broke down during their 3-stage, multi-panel interviewing process. I asked her if the candidates told her any reasons. She gave me two example questions: 1) How does video streaming work, and the platform you would implement it? 2) How does a SMS message get transmitted, and what would be the data structure like?
I laughed and told the recruiter I definitely wouldn’t break down because I had implemented those two protocols in the past when I was an embedded engineer. And I told her, Charles Schwab is on par on reputation with Fidelity except they conduct ONE technical interview and asked real world use case questions. What does video streaming or SMS messaging have anything to do with Asset Management applications?
It’s ridiculous. Wayfair hire third party interviewing companies to do their dirty deeds, asking questions which would have taken days or weeks to solve but expect candidates to provide answers within 30 seconds, and the algorithm test must be completed within 15 minutes. Along the way the interviewer kept interrupting candidates with questions. Maybe he thought he was helping?
Don’t work for those companies. Their ways of sifting through candidates are tell tale signs of how they will treat you once you step through their doors.
You deserve better.
Totally agree with everything said. I've had similar experience. When thinking about it, this always reminds me of this meme ... dev-to-uploads.s3.amazonaws.com/up...
This meme is a truth hahahaha
Live coding demos on random problems are insane. I refuse to take them.
Recruiting has gotten so out of hand, I no longer look at any unsolicited jobs from them. Companies became so arrogant that with this, they actually deserve today's shortage of good programmers. We're in control now.
I can fully relate to this problem. Recently, I had an opportunity to take part in the recruitment process where I had to solve task by task in about 1.5 hour long meeting. There were 2 other developers watching my shared screen and following my every step. As I get the idea of live coding I must admit that it may work only when it's well prepared. I had full repository of tasks in multiple directories without knowledge about how many task there are at all and how many left to the end. It was hard to focus although I had a chance to use Google I wasn't feeling good about it as task where kinda generic, school-like not real-life problems. As I searched for a tip... I was getting stackoverflow solutions in the first search results (and I was like.. What am I suppose to do right now, ignore the answers? Copy them or what? Interviewers reminded in silence). From my point of view it was weird, I didn't feel like it made any sense. I doubt you can properly examine a developer this way.
100%!! When I had my 1st interview of this kind it felt like cheating to use Google and SO. Didn't know what to do, either.
Luckly, we do this in our office. If we recruit someone to join our office, we will not watching you like we watch a horror movie 😅.
As a someone that has interviewed candidates, I'll ask you about your skills and why you learn those. I also ask about the technology that currently we adapt.
The final test is also making something and yeah it's based on our problem but we make it simpler. If you understood the task then we let you work and take time as you wish.
We will analyze your code, your result and your answer. And yeah, a soft skills is really important. Really 😅.
I'M NOT A ROBOT
Non-robots need not apply.
But seriously, for the hiring process I look for a good fit rather than a particular skillset. Skills can be learned. But being kind, helpful, nice, communicative, smart, genuine are traits I'm always on the lookout for. Hire the person, not the robot.
If you know how to implement QuickSort you are either a noob just finishing college, implying you're "sub-optimal" for whatever position they're looking to fill, or you read "How to ace 100 job interview questions", and you're 100% useless and an imposter. The same is true for "xyz" feature. Replace "xyz" with whatever you wish here ...
Technical interviews asking the candidate to solve irrelevant tasks are the recipe for disaster. Ask the candidate to "describe the purposeof xyz", then replace xyz with for instance ...
... is much more productive, and illustrates the candidate actually understands the subject at hand, allowing you to ask follow up questions such as "give me an example of when you needed feature 'xyz' and how it helped you for a particular problem".
Everything else besides the above is pure madness, and literally results in a 100% guarantee of that you'll end up with hiring the worst possible candidate ...!!
I am totally against this share-your-screen for a quick-coding-session thing. Unless you are hiring a keyboard puncher who has route learned some algorithms - this is not the way to hire software engineers.
Ideally, an interview session should consist of:
Interaction with HR to understand the human side of the candidate and overall company culture fit
A quick session with some senior tech resource to evaluate tech skills
A take-home test that the candidate can come back with and explain to the tech team. Alternatively, if time is of essence, candidate can be asked to go through their accomplished projects and explain the scope, structure, functionality, issues faced etc.
Final meeting with the top tech guy (CIO, CTO etc)
I agree Jean,
As a candidate doing a JS interview and they wanted to code without searching google, and obviously, I didn't remember the exact syntax for a function and they treated me as stupid. I thought thanks for not landing the interview because if the values are memory rather than a job done, we are not getting along.
As an interviewer, I find out works best a conversation to see how the person thinks rather than a test because the coding test takes a lot of time and effort without pay, and a technical conversation about the topics can do the job.
I actually don't think the technical questions are a bad idea. The main problem is the question itself is always so far out from what the job actually does. When I do interviews I ask a rather simple question that I can expand to be more complex based on the role and how they perform. I don't expect you to do perfect, I open up with this when asking. The test is mostly can you form any amount of coherent logic to solve the problem and can you ask the right questions.
Even if you are applying as a junior I/we expect you to be able to form a few lines of code with explanations in about an hour. Yes it is stressful, yes you will make mistakes ( I usually point out syntax issues or typos, cause really it just wastes time I trust you can fix them if given a longer time ). This is not the only interview it is just one part, you do talk with a tech lead for other stuff.
But you forget how important it is to code a Binary Tree and then a Dijkstra in 30 minutes for a role where you NEVER, I repeat, NEVER, use them again.
This really creates an interesting environment. Top Tech hires people which can spend countless time on Leetcode problems, but when you throw a real-world problem at them, they start to struggle. It is basically like in the whole education system, if you can memorize certain problems you get the job, if you are creative and smart, but take your time to think about it, you will fail.
I also agree on that companies tend to show people how "human" these are, but we should not forget, that not an actual human is writing/saying this, but a manager or somebody else deciding to put this somewhere, because the goal is to provide a certain image of your company and also for correctness (to adapt to what people expect from it, which not necessarily is what it actually is).
You are not alone with your opinion, we are people and not just some kind of resource.
May I ask, if people tend to be selective, when they are looking for companies? Is it maybe because of the companies you chose, when you are looking for a job? Like picking a well known and big company, because it has to be like that for whatever reason.
This possibly appears dumb, but my experience is, that more people are needed and it is totally fine not to know much at the beginning, as long as you show interest and the motivation to learn.
The latter, my experience, is not regarding Web Development or Software Development in sense of projects mostly consisting of code and also not for every country, but it still is related to Development of applications for business.
Strongly agree
If I were an employer, I would want at least one code sample. I would give candidates options and always allow up to three redos. So, dev can do take home or live, whatever type of problem they prefer (realistic or algorithm). I would always structure the problem to allow for anybody to solve it, but allow for a range of more complete answers. I would always provide the problem ahead of time for live interviews. I would let developer decide on what is within scope in terms of language features and libraries that the problem can require. I would just want some short demo of how someone programs.
Thank you for bringing this up. I had a similar experience and thought I was inexperienced, despite my impressive resume and the extensive list of technologies I worked with and learned on the job. Hopefully this process changes soon.
Full Ack. It's especially unfair when compared with the interviews of manager positions. "Ted told me you've done a great job over there in project xy, so we absolutely want you. Your compensation will be 30% higher than in your previous job. Any questions? Or shall we go to lunch?"