Hi everyone,
Have you ever had or conducted an interview without whiteboarding, home assignments, binary-tree-rotations, write-a-website-in-two-hours, design-twitter-on-paper exercises?
Was there an interview where you only talked about the candidate's (or yours) previous experience, their projects, their role, how they solved problems?
I'd love to hear if you had such experience!
As an interviewer, did you feel it is better or worse than more traditional ones?
Was such an interview approach successful for you? More or less stressful for your candidates? Was there enough info about the candidate's skills? Were hired folks more or less successful?
As a candidate, did you present yourself better or worse? Did you feel more at ease? Did you prefer this approach or other ones?
I'll be happy if you could share your experience!
Thanks in advance!
Top comments (34)
I've been hired 4 times and each time was a different experience.
First time as an intern. The interview was more about what would I be doing at work than anything else, as I was kind of hired through the university. As I did not have any professional experience either, the interview was more about my goals and if I was confident to meet them.
The second time I got hired I only did a Fizz-Buzz test (wiki.c2.com/?FizzBuzzTest) on a whiteboard. I would not even call this a coding challenge/whiteboarding interview, as the problem was really easy for me. We talked more about my previous work (as an intern) and again about goals. Also the fact that I studied at a particular university helped, as the interviewer also studied there.
Third time there was a take home coding challenge, and it was decisive, so I won't count it. The interesting part is that there was no other technical questions or feedback, just straight to the offer after delivering my code.
And the fourth time, again, no coding challenge at all. I had a call with the CTO and we just talked about goals, experience and so. This was for a senior/team lead position.
I am not sure what conclusions to take :-) Of course I've been rejected many times, this only counts the time I got hired.
Once I was interviewing for a company (who did not hire me) and I passed a coding challenge in a technology I don't even use (JavaScript) and then half way during the post-challenge interview they realized I did not have experience on JS, so they dropped me.
After that I always reject interviewing for companies that send coding challenges before speaking to the hiring managers. It is a huge deal breaker for me.
But honestly, on the other side, I had very good experiences hiring people based on their take home challenges. I like to ask my candidates to write a small single screen app that connects to an endpoint. I would probably not ask that to "distinguished" developers (like tech speakers, OS contributors, etc), but for the rest of candidates I really need to see how they work before giving my approval. And I know this contradicts my personal experience as interviewee.
Thanks for sharing, Miquel!
(As a side note: that's actually very interesting to learn about all interviewing experiences, not only about the ones in my question. Maybe I should post another question.)
I have a couple of questions for you, if you don't mind.
(A tongue-in-cheek question:) Why do you ask your candidates to complete an assignment if you wouldn't do it yourself? :)
What are you looking for in this assignment?
And why do you feel like you can't understand how they work if you talk with them, as opposed to an assignment?
Thank you in advance!
Oh sorry for the misunderstanding. I have no problem in doing a take home exercise, but I won't do it if I don't speak with the hiring manager before and clarify questions. There's a trend I've seen a lot in which companies send you a coding challenge before even having a call with their candidates. To be clear: first let's have a call, then I can do the coding part. And I do the same with my candidates.
On the code I basically look for cleanness, both in terms of architecture and code. And then I use it as starting point to have a conversation, why did you do something that way, what could be changed to do something else, etc. I ALWAYS give constructive feedback to my candidates.
It is probably my own insecurity honestly. Hiring is a long process specially here in Germany where notice period can go up to three months, and I only get the chance to add more devs to my team very rarely, so I need to be really sure about who I get for my team.
Okay, sorry, I get it now. :)
Thank you for explaining. It is very interesting to see the situation from the hiring manager's point of view.
Naturally as a candidate, not having to do technical tests makes the recruitment process a lot less hassle.
I am pretty happy with my current role, but often get contacted via LinkedIn about job opportunities and nothing turns me off more than lengthy, multi-interview, technical test laden recruitment processes.
To answer one of your questions, yes I have been hired at a company (2 actually) without having to do any tests, by just talking about past experience, strengths and weaknesses, and what the goals and plan is if I joined the new company.
For one I did provide links to some github projects I created so they could get an idea of my coding style.
Fortunately for those companies, finding a person who was a good fit for the team and was eager to learn were more important than knowing the latest JS (or whatever) framework. I enjoyed working at these places as they were very good with providing training and other opportunities for career development.
Somewhat worryingly, last year most companies I interviewed with had a lot of testing. Including some that wanted tests completed before they were willing to talk. Also rather than general tests of web development, which is the area of IT I am in, many were for a particular JS framework (some I have not used before so failed those tests rather badly).
If I must be tested, as a candidate I prefer a small programming task I can do at home. I am usually slightly nervous in interviews, and have lots of questions about the company and processes, so don't think I do so well with verbal or written tests during the interview itself.
I was hired by a tech company that did this in the interview. They already had my CV and so they asked me "well, tell us about you, your projects" I told them about my open source projects, speeches and such and it was mostly like an informal chat with some nice people interested in tech. Surprisingly I was given the job the exact moment we ended talking. I think it's amazing to feel comfortable in an interview and that way I was able to show better my experience and abilities, just because I felt relieved.
I've sort of had this happen.
A friend of mine referred me for a QA position at his employer. While there was a coding assignment prior to heading to the interview, the interviews themselves dealt more with, "How would you approach testing ____?" The only whiteboarding I encountered involved drawing some diagrams.
I ended up not getting the job. A few months later, a friend who referred me told me about a Devops opening they had. I spoke with the hiring manager and tech lead about generic tech topics, past experience, etc. I had an offer in hand later that day. After I started, I ran into the QA folks and all of them said, "We really wanted to work with you, but we thought Devops might be better for you."
These days, I won't do coding challenges (automated or take-home) without first talking with a hiring manager, and I actively screen out companies who do them by looking them up on They Whiteboarded Me (they.whiteboarded.me) or Hiring Without Whiteboards (github.com/poteto/hiring-without-w...).
(Full Disclosure: I run they.whiteboarded.me)
I've never conducted or taken part in an interview where we never went over code or had assignments. I've had individual interviews within the greater process that were more discussions meant to get to know each other and reveal general info.
But thinking about what would be most useful hiring me right now: I'd much rather chat with someone about fit, communication style, expectations, goals, etc. I've got a track record that shows I know how to code. What would be more important is whether our styles fit together. I'd probably fail engineering tests that I'd be a great candidate for in terms of the actual work.
Thank you for replying, Ben.
How do you "prove" your track record? You have, of course, this site dev.to to show, but I believe having a product is often not enough, very often showing code is required. Do you have opensource projects? Or am I wrong and a product is already enough?
If you hire for dev.to, how do you conduct interviews?
I think the product, my role within it, and the posts I've published, would be enough to get a really good picture on my expertise and abilities. I'm not above "proving" myself over again, but in general I think that step doesn't fit in all that naturally.
I know there's a shortage in engineers who are "over the hump" in terms of experience and skills to contribute without a lot of supervision or make leadership decisions. I feel like I could be evaluated as in that category and from there we should have a conversation about fit, rather than jumping through evaluation hoops. A two way conversation where we discuss where our goals and work styles align seems more appropriate.
We've only hired more junior roles at dev.to to this point and that takes the form of a questionnaire which is part technical part personality. Then we take turns doing short interviews with the candidate to determine technical skills. And if I was talking to someone with some professional experience, I really wouldn't feel the need to evaluate their technical skillset in an overly strict way. If we had concerns after talking with them, we'd follow up with more questions that could address them after we confer.
The best part of our hiring process I think is that we do blind surveys on our own before we discuss how the candidate is doing at each stage. An attempt to containerize our opinions before we talk and avoid group think.
Almost all interviews I've conducted have been a discussion session, not a game of programming Trivial Pursuit. I think a "stream of consciousness" discussion on programming, problem solving and other related technical matters is much more effective. Even with a junior level programmer, most will be quick to show you in a discussion what they know and don't know. It also gives you some idea about how well you sync with the other person.
Right now, I'm looking for a new job and it seems Trivial Pursuit is the name of the game at most companies. I've gotten homeworked, whiteboarded and computer science trivia questioned a lot. It's been rather annoying and frustrating at times. "No, I can't tell you how to balance a b-tree off the top of my head. If I really needed that info I'd Google it. Instead, let me tell you how I wrote a web service and application to keep multiple manufacturing lines supplied and synchronized. Or, maybe the one that coordinated logistics across several warehouses."
As for what I ask or like to be asked in interviews at the senior level, I like a discussion of previous projects. What approach/pattern was used? What were the more complex problems solved and how were they solved? Was the project a success with users? How did you interact with users? How did you delegate tasks to junior programmers on your team? How did you usually mentor junior programmers or new mid-to-senior level developers on your team? How did you handle testing and deployment?
Thank you, Frank. This is very interesting.
How do you reject solving these challenges? Do you simply say it like this - no, I won't be solving it? :) Though I'm sure you have a very polite but firm way of saying it.
I don't necessarily reject entirely but I redirect them to fit the context of the job I'm interviewing for, almost always a .NET/C# developer position. For example, I would explain that I would use built-in language features, such as LINQ and generics, to handle sorting, linked lists and so forth. I would emphasize that I don't want to reinvent the wheel when the language offers a rich set of features that have been exhaustively tested.
That's a good advice on how to handle this, thank you!
I've been on both sides. I like it for more senior-level positions: if I'm interviewing someone for a lead or architect job, whether they can remember how to balance a b-tree is unimportant. If your architect is balancing b-trees, you're wasting their time and losing money. At that level, you need to know how they approach problems, how they design systems, and how they work with people. It's difficult to get a sense of that from compsci trivia.
For junior and midlevel positions it's more important to validate that the candidate can do the work you need them to do. I like take-home projects for that much more than live coding or especially whiteboarding, since (assuming you're not fully locked-down) they'll have access to Google and StackOverflow if they work for you. All realtime tests do is give candidates heart palpitations.
Also, if you don't mind me asking about more junior positions. Why do you feel asking them about their previous experience doesn't show you if they can do the work you need them to?
Someone with junior-level experience is by definition less likely to have had the time to develop the vocabulary, the range of expertise, and the conceptual insight of a senior candidate. Erring on the side of practice over theory lets them show off what they can do and lowers the risk of getting into the weeds over abstractions.
That said, if a candidate has public code that's in the neighborhood of what I'm hiring for I will absolutely throw it up on the projector and make a code review/art school type critique part of the interview, but you can't depend on that being the case, especially for junior candidates. I'll have senior candidates do take-home projects too, depending on the position and their resume; this is far from an exact science.
Thank you for sharing!
Can you explain a bit more what questions do you ask for these senior-level positions where you apply this approach?
I ask them to talk me through the designs of things they've created, showing me their code or even just sketching the architecture out on a whiteboard. If you can communicate how and why these parts interact, what this choice simplifies, why integrating X made sense, what problems Y caused and how you addressed them, then that showcases both your understanding of software development principles and your architectural sensibilities.
I propose hypothetical scenarios and ask how they would address them. I'm not interested in the precise steps, but in how they think. My favorite for this is "you have a straightforward client-server-database web application. QA drops a screenshot of an error page they received after submitting such-and-such form in your lap. Go." Do they check logs? Do they try to reproduce the issue? Do they ask for more information? When they address it, what steps do they take to ensure the same or similar problems won't recur?
I do still ask technical questions, but I make a point of minimizing trivia for senior and junior candidates alike. I'm more interested in your understanding of principles: tell me what distinguishes inner from outer joins, how do database indexes work, what does inversion of control mean and what does it do for you, describe REST and how you would use it in an application, that sort of thing. Obviously these vary in "difficulty", but I don't care so much about getting dictionary definitions. If a junior candidate tells me that they aren't sure but inner and outer joins have something to do with filtering rows out based on what's in the joined tables, that's positive.
My single favorite interview question overall is "what's your least favorite technology to work with, and why?" The only wrong answer is one you can't support.
I believe that most companies today interview to look for a book worm that knows all the vocabulary and memorization. When I interview people I look for critical thinking skills. I look to how they solve problems. I am not expecting them to build me some multi-dimensional array or know all these JS terms.
So you may ask, well how do you know what they put on their resume is true? Well that is why you call the company they worked for to talk to them. I honestly think this is never done anymore. Also lots of tech companies will hire temp to hire positions.
Hi John,
I understand the importance of the references, but I imagine it would be hard to do if the person is still working and doesn't want to let the current company know they're interviewing. How do you handle this?
Also can you explain more how you investigate their problem solving approach? I'd like to know more.
I would hope the person has more than there most recent job on their resume. You could contact those people first as this would not impact their current role.
As far as problem solving skills, I like to show the person a problem and without code I want them to talk me through some ideas on how they would solve that problem. Have them explain what they would do to identify where the problem is and what steps they take to solve it
This approach is very prone to a hiring mistake. You can end up with theoretical generalist who only can
architectbut in fact never wrote more anything more thanFizz-Buzz. Even a 5 minute coding assignment is enough to evaluate the candidate.Hi Alex,
Is it your personal experience that you (or your co) hired a talkative person unable to code? Would be very interesting if you shared a bit more about your case, please.
I'm not really comfortable to share the details :) I would not use talkative word, I would say that you can hire with this approach a person who just read the day before interview an article on medium about CQRS/microservices/ML/
you named it hereand has zero in depth understanding or practical skills. Moreover the candidate could say in the fist day of on boarding - Pfff I don't use {place your mainstream programming language here }, let rewrite it in Node! (Hypothetical situation )The consensus with talking to my colleges is if you just talk and don't do any technical problem, you run the risk you get a candidate who can talk very well but can't really do the job. There's a balance between the two and only experience can help you evaluate candidates well.