Live data from Hacker News

Tech sector job interviews assess anxiety, not software skills: study

news.ncsu.edu

851–860 of 1001 posts

Re: Tech sector job interviews assess anxiety, not software skills: study

#851

Earlier quoted context omitted.

Yes this. Hiring the wrong person can be ridiculously expensive, especially if they linger on in a role for years corroding the culture.

obligatory request for citation

Do you really need a citation for this obvious fact?

Re: Tech sector job interviews assess anxiety, not software skills: study

#852

Earlier quoted context omitted.

You're missing the quality they're actually testing for: ability to study and dedicate yourself to a task. Or in other words work ethic. The algorithms don't matter but the fact that you can spend months learning them is an important skill. Intelligence is less important for success than work ethic which is why work ethic is tested for so much. Specifically, work ethic and ability to learn in a related domain as, for…

Ethics? You are asking people to study and spend hours working on LeetCode problems for something close to completely useless. On the ethical scale, people that accept to spend hours of their limited life doing so are probably not the ones I would think of as "looking to work on something great"

Yeah writing an OS, a machine learning framework, designing deduplication for a photos app with a billion users , working on on board sensors for a self driving car. Such "grunt work". I'd love to know what exciting and hot thing you're working on ? Is CRUD the new sexy ?

Re: Tech sector job interviews assess anxiety, not software skills: study

#853

Earlier quoted context omitted.

One trend I've noticed that is markedly different from when I started programming in 1998, is how dependent we've become to program via Google/StackExchange searches. I'm not sure I know how to write anything from scratch anymore, because I just search/read/alter/test. The breadth of what I work on is 100x wider than it used to be, and so I've become absolutely dependent on quickly reading docs, copying code found on…

I've been doing this for a LOOONG time. Early on, the core skill for a programmer was intensive in-depth knowledge of the language being used. We all talked a good game about what we called "reusable software," but yeah. Talk. Now things are TOTALLY different. Doing a good job requires extensive, encyclopedic, knowledge of what's out there, how well it works, and how to integrate it. npm, nuget, maven, anaconda, we a…

Yup, a lot of developers grow into generalists that know a lot of things about a wide range of subjects; they suck in a technical / algorithm interview, but they can solve most problems. They may not know all of NPM's options (for example), but they know how to quickly find an answer if they are confronted with a problem.

Re: Tech sector job interviews assess anxiety, not software skills: study

#854

Earlier quoted context omitted.

>Doing a good job requires extensive, encyclopedic, knowledge of what's out there I wouldn't say that. What I feel like I've accumulated in knowledge over time is I can look at a new problem and without having the solution/encyclopedic knowledge, I can know in my gut that (a) there is a solution, and (b) the solution I'm looking at is not the solution. Merely being able to look up things on the internet without these…

I describe this as known-unknown vs unknown-unknown (credit to Donald Rumsfeld) Unknown unknowns: The things that you don't know are possible and thus don't even know how to start solving. You will accidentally reinvent the wheel, most likely very badly. Or give up right away. Known unknowns: An experienced developer most likely unconsciously knows (has read on HN/Reddit/Book/Blog some time in the last 20 years) that…

> Known unknowns: An experienced developer most likely unconsciously knows (has read on HN/Reddit/Book/Blog some time in the last 20 years) that a thing they encounter has been solved already, at least partially.

I feel like my brain is full of "I read a headline about this once" tidbits, in part because of HN. It's like I don't know the answer, but I know the question has been solved before so I know there is an answer.

Re: Tech sector job interviews assess anxiety, not software skills: study

#855
post #631

Earlier quoted context omitted.

It's not just you :) A much more realistic way to test people is to tell them to bring their laptop, point to a problem on the whiteboard and say "here, solve it, and use whatever resources you need." I'm somewhat like you; I do a wide variety of tasks every day and simply can't keep all the different rules and syntaxes in my head. I'm terrible at tests anyway and would probably bomb a FAANG interview badly because o…

I don't even have a personal laptop, seems like bringing the employer provided laptop to interviews is not the most sensible.

I'm glad my (former) employer has a scheme where after two years you can take over your "old" laptop for just €200. I'm at my new job right now with a 2017 MBP, which their current laptop budget just wouldn't even come near to. Oh and I got it revised just before leaving, the speakers were broken but there was a recall / extended warranty about that problem, it got the whole top replaced.

Re: Tech sector job interviews assess anxiety, not software skills: study

#856

Earlier quoted context omitted.

This. Last interview I bombed because no one would ever remember what they were asking for in the interview test. I said I'd just google it and then dropped "Never memorize something that you can look up." ― Albert Einstein

I like this quote, but I think the point comes across better if you rephrase it: > Never _intentionally_ memorize something that you can look up. I guess you can't quote Einstein, then.

Yup, the tasks that you repeat often enough will get stuck in memory.

In theory anyway, I always have to look up how to remove a remote git branch or how to do the euro sign on a Mac.

Re: Tech sector job interviews assess anxiety, not software skills: study

#857

Earlier quoted context omitted.

In most practical situations, your initial impression is correct. As a native English speaker, I've never heard seen or heard someone use "average" to refer to a statistical summary other than the mean. If it doesn't refer to the mean, it doesn't mean anything formal/technical at all. I read GP as "median is sort of an average in the broad sense", but this is honestly kind of a stretch.

I see it quite commonly, from technical discussions to newspaper article. When people say "the average income in the US" they are almost never talking about the mean.

I think they are. I doubt any newspaper articles use it to refer to the median, at least I've never seen them use it like that. Do you have any examples?

Re: Tech sector job interviews assess anxiety, not software skills: study

#858
post #377

People bomb, including good people. That is sadly part of the system. Once I had this candidate. Damn, I know my questions are deceptively simple on purpose, but he literally couldn't do anything. Not even a trivial brute force. Not even any related simple knowledge questions. Couldn't tell an average from a median. The only good thing I could write in the feedback was "seems to know some basic syntax". It was quite…

One trend I've noticed that is markedly different from when I started programming in 1998, is how dependent we've become to program via Google/StackExchange searches. I'm not sure I know how to write anything from scratch anymore, because I just search/read/alter/test. The breadth of what I work on is 100x wider than it used to be, and so I've become absolutely dependent on quickly reading docs, copying code found on…

I believe we should program the way you do nowadays. This is what people praised in the past so much as code reuse. This is what research people call standing on the shoulder of giants. We should reuse other's wisdom (well, you need to filter what wisdom is and what not first, of course, which is not that straightforward itself). Most profession work on pre-manufactured components for the sake of... well, many things (its a story of its own)!

Do it smartly, know what that component is, if that is good for the purpose, if that is the best for the purpose, its trade-offs, but that should be the primary way. With fallback to reinventing the wheel.

We still will have to provide custom built solutions from scratch from time to time (in fact in a lot of cases, the CS is still not mature enough for proper higher level operations) but better to rely on tested and ready pieces.

Recruiters seems to have no clue how to select people for the particular position therefore they go back to the ancient times of CS like this dumb whiteboard thing. I also felt like they seems to expect that custom made employees exists out there and they only need to wait for the perfect candidate, not really expecting someone to learn while the continuous learning is the industry norm, the inherent requirement. I've seen positions remained unfilled for more than 6 months sending away partially fitting experienced candidates.

I failed at technical interview where you must react instantly and accurately without any help normally available in everyday life (Google). After looong time of programming and learning various approaches I find myself question myself continuously even in fundamental matters. Or is it something by age? Nevertheless while being young, self confident and energetic and the Google style of programming was far from invented my fingers were spitting huge amount of brilliant code that did not work until I fixed all the stupid mistakes I made, which took frustrating amount of time. Coding gives a good amount of humility by showing you that you are to blame in every last cases. Every time! Making mistake, misunderstanding something, not knowing necessary elements, misjudging aspects, not checking the reliability of some component you rely upon, it always comes back to you as the computer will do exactly what you tell it to do, it will always be you. Frustrating. I learned to doubt myself and verify seemingly evident matters which does not play well in whiteboard interviews as you might imagine (in fact once I had mental whiteboard interview, speaking about solutions, how common is oral programming in practice?). This is an unnatural and sinfully inaccurate way of judging how one will work in a position. Due to the constantly changing (improving?) profession and the huge amount of beautiful aspects it entails keeping every bit of detail in head that you can spit out in a second notice is far from being a smart expectation. It happened more than once that the right answer occurred me after walking away from the interview as the knowledge bubbled up of the sea of experiences. Once I told someone that sorry, I never met that technique before just to realize later it was an essential component in a task several years back, I used that quite a lot for that one task.

I did not change position too much (3-8 years spent in one place) but I never been hired based on whiteboard test but by trial tasks or probation period, fulfilling the need of the position (leaving due to dissatisfaction every time). In fact I just met whiteboarding recently and I find it hugely inadequate to judge competency.

Re: Tech sector job interviews assess anxiety, not software skills: study

#859
post #365

Earlier quoted context omitted.

I don't think people are naive, they just don't have a better solution. Most established professionals are not interested in a 10 week trial period after which they might be back on the job market.

You say that as if your boss can't wake up one morning and fire you because they don't like the way you pour your coffee. The only thing that changes is how much paperwork they have to do to make it happen.

They can't in general, it's against the law to do that. And there are penalties if caught (and being caught is not so hard.)

Re: Tech sector job interviews assess anxiety, not software skills: study

#860
At Google I'm convinced our interviewing system only works due to a combination of luck, large numbers, and generally good intentions. None of the individual steps is a particularly good way to tell if someone will succeed at Google, but anyone who passes all of these filters is unlikely to be a terrible engineer.

When you avoid terrible engineers and hire by the tens of thousands, you get plenty of good engineers and a few great ones. You also miss a ton of qualified candidates, but Google has more of those than it needs. It can afford to miss them in a way that small companies can't.

Post reply on HN