[HN Gopher] Ask HN: What is a better approach to interviewing?
___________________________________________________________________
Ask HN: What is a better approach to interviewing?
I want to make the interview experience better for applicants but
have no control over the format or time. There is a lot of
criticism of the algo centric approach and I'd like to change that
within the confines given to me.
Author : awalsh128
Score : 23 points
Date : 2020-09-12 19:30 UTC (3 hours ago)
| jimnotgym wrote:
| How about discussing some projects they have worked on, and ask
| them questions about their role in the process? Have a tick list
| in front of you of the skills you need and see if they bring them
| up. If not you can always ask specifically about them at the end
| lordnacho wrote:
| I've interviewed loads of people over the years in different
| ways. I'd say the real dud hires were not that different from
| other hires. The duds were people who for one reason or other did
| not want to do what was assigned, yet took some time to say so.
| Personal issues for sure.
|
| When hiring what works for me is looking at past experience. If
| someone says they are a cpp performance guy, that creates an
| expectation of what they should be able to chat about. If you're
| making it up, you will run out of stuff to say, and I'm patient
| enough to let people keep talking. Hopefully I'll learn something
| too, it happens often with top pros. But basically if you're
| experienced in a field it should be hard to come up with anything
| where you draw a total blank. If that's the case you're pretty
| good in my book, the main differentiator after that is whether
| you've done exactly what the firm needs or just something
| similar.
|
| With entry level people it's hard. That's why they typically make
| less money, it's an Akerlof lemon cut due to the being a lot of
| people who just aren't going to be good at it. This isn't even
| necessarily a coding thing, but general life maturity. We had a
| guy who couldn't wake up on time to get to work, and he couldn't
| phone in when he was late either. I reckon there's no way to know
| about this kind of attitude problem until you hire them. This is
| also why you can expect a relatively high jump in pay after your
| first few years, it's proven that you aren't one of the lemons.
| The distribution is a large mass of hard to differentiate
| professionals, plus some duds of near zero value.
|
| So for entry level, your best bet is simply finding someone you
| think is smart. You'll end up falling back to the same thing as
| everyone else who is hiring: the prestige of the uni they went
| to, and some pot luck questions to make sure they picked up
| something. However that's really not enough to know what you want
| to know, which is whether they are able and willing to learn what
| you need.
| angel_j wrote:
| Hiring managers in tech need to realize they are working with
| high level learners. An expert in JavaScript can easily learn
| React, TypeScript, etc. Somebody who knows the ins and outs of
| Linux can easily learn Docker and Kubernetes.
|
| Hire them, give them a week to catch up, and their off; or wait
| months to find a perfect match? Any developer with a few years
| experience knows how to pick up the next piece of technology, the
| same way everybody else does: read docs, search blogs and forums,
| ask StackOverflow, etc.
| gagan2020 wrote:
| I had to take 300-400 interviews in short period of time to hire
| few candidates. I created excellent team by asking basic
| concepts. If they could answer those then they could build a
| product or figure the product out.
|
| That works best for programmers with entry to mid-level. In
| Senior level you need to focus more on problem solving.
| danielzh wrote:
| What are some examples of the basic concepts?
| jasonpeacock wrote:
| Data structures, complexity, algorithms, abstraction,
| encapsulation, ...
|
| You want someone that can easily talk about the pros & cons
| of using different data structures or algorithms to solve
| problems. Who can move up & down layers of abstraction
| without getting confused & lost. Who can hide complexity to
| make clean, readable, maintainable code.
|
| Many people, especially junior/less experienced engineers,
| have only memorized solutions to problems. They don't have a
| strong toolbox of solutions and the experience to know how to
| apply them (and evaluate the options).
|
| A good problem solver is methodical - they don't just guess
| at random data structures, they identify what the
| requirements are of the problem and then choose the
| appropriate data structure (or compose one) which meets those
| requirements. They'll have a process, which may be different
| than your process, that they use to break down problems into
| smaller, solvable pieces.
| lampe3 wrote:
| Why do we focus so much on data structures and algorithms?
|
| It sounds to me like we are forgetting all the other
| important things.
|
| Like how easy it will be to replace that data structure if
| maybe the requirements changes? Do we really need to
| optimize this thing fully now? Or maybe for the next 5
| years to simple solution will be more then enough? And so
| many other questions.
|
| A lot people need to think longer then 1 minute to come up
| with a good solution or maybe you need to try or maybe you
| need to learn something?
|
| Isn't that what we actually do? How often did we think that
| framework X is the best but after a while it was not that
| great? Don't we need to play around with an API to
| understand it better? Or let me read about that and
| tomorrow we can talk about because last time I was doing
| something with binary trees was in university because in
| the real world I don't need it that often because yeah we
| have other important things to do.
| tester756 wrote:
| >You want someone that can easily talk about the pros &
| cons of using different data structures or algorithms to
| solve problems.
|
| uh, not really.
|
| In my world majority of performance issues comes from N+1
| queries, I don't need people who can do crazy things with
| trees. I need people who write testable code, tests and
| care about security.
|
| Of course you can argue that N+1 query fits algorithms
| part, but very often algos mean leetcode
|
| But, since "you guys" always talk about data structures
| then I'd want to ask - how often do you use something
| fancier than literal basics?
| techslave wrote:
| casual culture talk with 2 people, then a 2-5 day contract. only
| works for out of work candidates of course.
| jasonpeacock wrote:
| Don't do "culture talk", thats where unconscious bias lays and
| you will end up hiring people that are like you.
|
| There are many awesome people you can hire that you wouldn't
| hang out after work, and that's OK - you don't have to be
| friends with all your coworkers, you just have to be able to
| work together.
|
| Instead, identify qualities & behaviors that your company
| values or are exhibited by successful employees and ask for
| examples of the candidate demonstrating them.
| autarch wrote:
| "Culture" is a really broad word. I agree that "culture fit"
| is often cover for "let's hire people who are just like us
| because I'm more comfortable that way".
|
| Instead, I think we should attempt to really dig down into
| elements of "culture" and identify the ones that are relevant
| to the job vs those that are not. For example, some relevant
| elements might be: * Preferred development
| process. * Pace of delivery and willingness to ship
| bugs. * How disputes are settled. * Using
| libraries vs build it in house. * Process for
| adopting new technology. * Preferred communication
| methods. Email vs chat vs video calls vs in-person (back in
| the pre-plague times).
|
| These are all important topics to address in order to ensure
| that the potential hire will be able to work effectively in
| the position, and that they won't be miserable.
|
| And there are plenty of things that are _not_ important:
| * Hobbies and how people spend their time outside of work.
| * Favorite films, music, books, food, drinks, etc. *
| Whether you work on side and/or FOSS projects (unless there's
| a legal issue with side projects).
|
| All of these things, on both lists, could fall under the
| nebulous "culture" umbrella. So let's stop using that word
| and start talking about specifics.
|
| I'd also note that for some of these things I expect the
| candidate to ask _me_ about them if that's something they
| care about. In fact, those sorts of questions are a very
| positive signal to me. It shows that the candidate has some
| insight into their own work and what makes them happy and
| productive. I'm very happy to find out that this isn't a good
| fit _before_ they've started working with me!
| lampe3 wrote:
| Yes please do culture talk but the good kind!
|
| Yes people in teams should like each other because otherwise
| you will have a bunch of unmotivated pixel pushers as
| developers that only think when the time runs out.
|
| In all of the companies were soft skills did not matter and I
| worked for people were coming and going.
|
| No you don't have to be friends outside of work but usually
| you are still spending 8 hours 5 days a week with these
| people and maybe for some people it is okay to not like the
| other people in the company but from my experience this leads
| to no good in the long run.
| akdas wrote:
| I've been writing about this topic for the last 7 months. The
| absolute biggest change you can make within the confines you
| presented is to switch from "looking for weaknesses" to "looking
| for strengths". I wrote about this here during the beginning of
| the year[0].
|
| You can find all my past articles[1], and I'm happy to find you
| specific ones. I think, given that you can't switch away from
| algorithmic interviews, at least make the interviews more
| collaborative, define your expectations up front, and generally
| find ways to help the candidate show their strengths.
|
| [0] https://hiringfor.tech/2020/02/10/false-positives-and-
| false-...
|
| [1] https://hiringfor.tech/archive.html
| necovek wrote:
| "Format" is very broad, so in a way you are saying that you can't
| change anything.
|
| Rather than saying how you are constrained, what freedom do you
| have?
| jasonpeacock wrote:
| Identify what data you need to collect to show that the candidate
| has skills & knowledge to perform the role, then ask questions to
| collect that data.
|
| Of course, this requires knowing what skills & knowledge are
| needed for the role - you may need to review the job description
| or push on the hiring manager to quantify them.
|
| When asking problem solving or coding questions, work with the
| candidate as if you were two teammates solving the problem
| together - don't be adversarial, don't play "gotcha!", don't try
| to show off or prove yourself smarter.
|
| If you have an awesome candidate, they will be smarter/more
| skilled/more experienced/more knowledgeable than you in some
| technical areas. That's a good thing!
| athoscouto wrote:
| I don't think there is a silver bullet here. I've been working on
| our engineering hiring process for the last couple years for a
| company with ~200 engineers - reading everything I can on the
| subject during this while.
|
| Most articles complain about the status quo but don't offer any
| practical advice. When they do, it is some approach that may not
| be an option on most cases - e.g. 40 minute interview followed by
| a 90 day probation period.
|
| Live coding interview can be pretty tough for candidates, but we
| try to make a lit bit less difficult by: - Giving them time and
| resources to prepare. - Letting them use their preferred language
| and IDE/editor.
|
| But since you have no control over format or time, maybe try to:
| - Use reasonable problems - to assess skills people will actually
| need on the job. In our case it usually boils down to using
| comodity structures like a dictionary or map to do simple tasks
| efficiently. - Use problems that start simple but can be
| extended. This is good because when candidates finish the first
| part, they get a boost in confidence. It is also nice because if
| they freeze, you can help them finish the current "level" and
| still have material to assess other skills. - Set them up for
| success during interview: - Reserve the first 5~10 minutes for
| introductions, ice-breakers or questions about the interview. -
| Reserve the last 5~10 minutes for the candidate to ask any
| question about the company or the hiring process. - Make clear
| that is OK to ask any question. - Help them on small blockers. -
| Be friendly.
|
| Making these little tweaks helped us to diminish the pain of this
| kind of interview.
|
| Some links/references: [1]: https://lawler.io/scrivings/erics-
| guide-to-hiring-software-d... [2]:
| https://medium.com/@alexallain/what-ive-learned-interviewing...
| [3]: https://www.holloway.com/g/technical-recruiting-hiring/about
| codingdave wrote:
| Ask questions that are open-ended. Don't ask them something with
| one right answer - give them a scenario and ask them to show you
| how they'd solve it. That is more realistic - if they know an
| algorithm that helps, they'll use it. If they don't, they'll try
| something else. Either way, you are hearing their answer, not
| trying to lead them to "the" answer.
| 6keZbCECT2uB wrote:
| I am new to interviewing, but I have two working hypotheses:
|
| 1. Hire based on the resume, gut check on the interview. Is it
| plausible that they played the role that they said they did? If
| you were a major contributor to an RPC framework in C, but you
| can't walk a linked list... Maybe your resume is too inflated.
| This means that the questions are basic because their purpose is
| not to rank candidates but to ensure the validity of the resume.
|
| 2. Focus on reading over writing. I would rather a candidate who
| can read code someone else wrote, articulate what it does, and
| maybe plan for how to extend it than someone who can pretend to
| invent something new.
| tester756 wrote:
| I do like things like:
|
| How would you design/write xyz
|
| What's wrong with this code [code] (bug, security issue, bad
| code)
|
| What do you think about
| KevinAiken wrote:
| I really liked one place I interviewed at that gave an option for
| the technical portion of the interview. You could choose a 4 hour
| homework, whiteboarding, or talking someone through a significant
| non-proprietary project of yours.
| sg47 wrote:
| 45 minutes - write a simple API matching the spec in one of the 3
| languages on your/our laptop. Use Google if you have to. Someone
| will be in the room to help answer questions. API should be
| functional. Returning fake data is fine (or provide data in a
| sqlite db)
|
| 45 minutes - do code review of this extremely buggy code like
| you'd review a coworker's code
|
| 45 minutes - presentation on a technical topic to one or more
| team members
|
| 45 minutes - behavioral. Let's talk about failures, conflicts in
| your career. Who are your role models? What do they do well?
| Leadership abilities, career progression
|
| 45 minutes - troubleshooting. Here's a docker container. Make the
| service inside it work
| angrais wrote:
| Where do you work? This process sounds solid and based on that
| I imagine your team setup is great to be part of.
|
| Am interested to learn more. Are there open positions?
| Supermancho wrote:
| That's 4+ hours if you count initial setup, meet, breaks, etc.
| richardknop wrote:
| A lot more since you have to prepare for the interview /
| interviews. So there's several hours to prepare at least.
| sg47 wrote:
| Which part. Except the presentation, there's no prep
| required. It's all about what you know and what you have
| done in your career. No Leetcode, no algorithms, no bs
| questions.
| edmundsauto wrote:
| That seems like a minimum amount of time to know if you want
| to hire someone, IMO.
| angarg12 wrote:
| I work in a large tech company and I also hate leetcode-style
| interviews, but I need to abide by the rules.
|
| My ideal interview questions are as follows:
|
| * No trick question. Reaching a solution shouldn't involve
| obscure knowledge or an "aha!" moment. * Only basic data
| structures and algorithms, the kind that you will realistically
| use in most day jobs. * Start with a very basic problem, and ask
| follow up questions with increasing complexity. * Extend the
| problem in different dimension to probe the candidate in
| different axis. For example, ask the candidate to design an API
| for the code, or to run it at massive scale.
|
| It's hard to come up with problems that cover all these points,
| but you can get close. I find these kind of questions allow me to
| assess candidate without making the process unfair or overly
| stressful for them.
| lampe3 wrote:
| Job interviews in the IT world are a reason why I will go
| freelancing...
|
| Writing some algorithm No why should I? If I need an algorithm
| that must be fast I will look up a peace of code that is used and
| tested by other people.
|
| No I will not live google in front of you watching me. How is
| this a real world scenario? How came up with this?
|
| Like stupid questions like: How many log entries should a service
| have each hour? Yes this was a real question in a job interview.
|
| IT Job interviews are broken in so many ways.
|
| I refuse to live code or have this you now have X minutes to
| solve a problem stuff. Again this is not how I work and also I
| have never seen people work like that in the real world. Only in
| shitty teams with shitty organization and where they were
| thinking that they were agile because the sprint ends in 5
| minutes...
|
| Here is the only way of interview I tolerate these days: 1)
| (optional) Have a call with HR
|
| 2) Talk with people from the team in an open way. Talk about real
| challenges and how the applicant can help in the challenges of
| the team. Check if the applicant will fit your team! Good team
| chemistry eats technical knowledge by 1000x. If you only take
| people because they know some algorithm you will most likely end
| up with something in Germany they call "fachidioten". They will
| solve the problem on a technical level but will bring with them
| 1000 other social, product and long term problems with them.
|
| 3) If you still not convinced that this person is good enough for
| your team then. Give that person a small challenge he/she can do
| at at any time she/he wants.
|
| 4) Let the applicant send you the solution and if you think it is
| okay then talk about the solution of the applicant and see how
| he/she reacts to criticism. Again a team that has good social
| skills and likes each other will eat every team were you have
| rock stars that think they are the best.
| shoo wrote:
| Possible failure modes with this approach: quite a few
| candidates who are not strong at actually doing the work will
| be able to somewhat convincingly "talk the talk" well enough to
| pass stage 2. If stage 3 is done async then there's a minority
| of candidates who will cheat and get someone else to solve the
| challenge for them. If the org has set up a hiring pipeline
| rather that first tries to identify strong hires before
| figuring out exactly which team they would join rather hiring
| to fill a specific role then step 2 might not make sense
| either, as there's no specific team to interview.
|
| I agree that the in person time pressured performative problem
| solving & coding engineering interview process is often a poor
| approximation of the work.
| crehn wrote:
| Some companies (e.g. Amazon) have a separate verification
| interview to ensure the candidate is the author of the
| deliverable.
| heavenlyblue wrote:
| I think I failed one of the interviews this way actually:
| after having done the async part of it I did about 10 other
| test interviews and literally forgot about what I did for
| this one.
|
| I had quite a few "aha" moments where I was "ah wait, I
| totally didn't do that, have I?". Didn't get the job,
| however neither did I like them.
| kyawzazaw wrote:
| Isn't that issue that it is too expensive for companies to do
| what to have described due to volume?
| lampe3 wrote:
| which volume?
|
| volume if you need to hire a lot of people? volume of
| applicants?
___________________________________________________________________
(page generated 2020-09-12 23:00 UTC)