The dystopian world of software engineering interviews • Hacker News Board

Re: The dystopian world of software engineering interviews

#771

Post by thewhitetulip » Sun, Feb 16, 2020, 2:12 PM UTC

paganel wrote: post #642

thewhitetulip wrote: post #384

Earlier quoted context omitted.

> Unearned privilege? I agree that the interview process looks for self clones. I've been in interviews where interviewer was like "why you used Dictionary to do this? Nobody uses dict in prod code" But unearned privilege seems a little harsh doesn't it?

Now I’m curious why they didn’t use dicts, I love dicts. I’ve been writing Python for a living for almost 15 years now and dictionaries and (reasonable) list comprehensions still attract me like they did the first day I “met” them.

I don't know. It was bizzare to hear it.

To be honest the lady taking the interview didn't understand my code, at least that's what I got. The guy with her definitely didn't understand a line I had written.

Maybe that was her way of protecting herself or something else

But I've never come across any real reason to not use dicts

Re: The dystopian world of software engineering interviews

#772

Post by PaulStatezny » Sun, Feb 16, 2020, 2:26 PM UTC

willberman wrote: post #520

I see peoples' opinions here generally falling into one of two camps. The standard way interviews are conducted are either good or bad. I think it's important to consider both the good and bad elements, and then come to a conclusion about what to do in order to move the collective interview process in a better direction. To note, I've never gone through a traditional technical interview, so take what I'm saying with…

I might be mistaken (and I'm no Haskell expert) but I believe your solution is based on a misunderstanding of the problem.

> Find the Kth highest value in a binary search tree

Your code seems to return _any_ node that is at level K. Where K is 1 for the root node, 2 for its children, 3 for its grandchildren, etc.

But unless I'm mistaken, by the wording of the problem, it's looking for the concretely K highest value, in sorted order. Not "highest in the tree". So if a binary search tree has values (1, 3, 5, 8, 13) the algorithm is supposed to return 8 when K=2, _regardless_ of how the nodes are structured. (E.g. Even if it's unbalanced and 8 is the root node.) Because 8 is the 2nd highest value contained by the tree.

Sounds like a harder puzzle than your interpretation...

Re: The dystopian world of software engineering interviews

#773

Post by bitexploder » Sun, Feb 16, 2020, 4:21 PM UTC

proximitysauce wrote: post #656

bitexploder wrote: post #322

Earlier quoted context omitted.

We generally ask for two references and a warm introduction to each reference. We take it from there. We aim for more recent references. Doing it for all previous jobs is overkill and time consuming. The feedback is generally candid and useful. In some cases (limited work history) we only follow up on one reference. In others the best reference is also the current employer so that obviously can be tricky. The spirit…

I think it's important to understand that you're asking candidates to burn "social capital" by arranging those introductions. I've worked for pretty high end people (successful founders, ceos...). I'm not going to call in any favors from them for a job interview. Most senior people feel the same way. Don't ask your candidates to expend their own personal or social capital.

I think this makes it overly difficult to fully vet candidates. Like I wrote before, we have had long discussions with our current team about our hiring system and the feedback is overwhelmingly positive. We try to take care in the whole process and honestly, if someone feels what we are asking is too much, they don’t have to complete the interview. We explain the steps up front before anyone commits any time or “social capital” to our process.

Re: The dystopian world of software engineering interviews

#774

Post by bitexploder » Sun, Feb 16, 2020, 4:23 PM UTC

ghaff wrote: post #664

proximitysauce wrote: post #656

Earlier quoted context omitted.

I think it's important to understand that you're asking candidates to burn "social capital" by arranging those introductions. I've worked for pretty high end people (successful founders, ceos...). I'm not going to call in any favors from them for a job interview. Most senior people feel the same way. Don't ask your candidates to expend their own personal or social capital.

It feels like even a fairly benign implementation of interviewing references wouldn't scale very well. It's something I might impose on a couple of people I knew well once for a special opportunity but expecting them to repeatedly do this for a bunch of companies using this process seems unreasonable. And as others have said, while I could provide references going back quite a few years, it definitely wouldn't be eve…

We tend to only ask for two references and it is negotiable. References from the distant past aren’t useful because our goal isn’t to “find liars” as some people suggested. It’s to get an unbiased perspective from someone other than the candidate. FAANG interview system takes way more man hours per candidate than our system.

Re: The dystopian world of software engineering interviews

#775

Post by scottlocklin » Sun, Feb 16, 2020, 5:27 PM UTC

blub wrote: post #705

scottlocklin wrote: post #653

Earlier quoted context omitted.

Feel free to be horrified: a data scientist who doesn't understand where and why to use unix command line tools for data preparation and ETL is about as useful to me as one who doesn't understand the conditions where a t-test breaks down or what a ROC curve is. Generally speaking, people like this have never actually dealt with large data sets, never dealt with issues involved with installing "unapproved software" on…

I think that the people not being impressed by cut and sort are approaching this from the Linux end of things, where those tools are nothing special at all. I guess we kind of expected that the data science wizards would be using fancier tools.

Yeah, well, people who have enough self regard to think of themselves as "wizards" are super unlikely to be able to actually do the day to day grind of getting, cleaning and preparing data for feature generation, which is about 95% of the job.

Another good weeder for a person claiming to be senior: discuss how you would fix the performance of the default R naive Bayes implementation in e1071. It's numerically more or less correct, but written by deranged ape-men who don't understand how computers work (a problem in a lot of the R ecosystem; in the Python ecosystem, the problem is nobody has yet written algorithms for X, which ends up being a very similar problem: aka it's your job to code up sane algorithms).

Re: The dystopian world of software engineering interviews

#776

Post by username90 » Sun, Feb 16, 2020, 5:40 PM UTC

adamsea wrote: post #607

tsukikage wrote: post #529

Earlier quoted context omitted.

This is implicit in a coding interview, though. I, the interviewer, take a couple of sentences to describe a problem. What next? Way too often, rather than ask more questions - gather and define requirements - a candidate will launch straight into solving a problem different from the one I am describing.

Requirements gathering in reality can often require more soft skills or political skills, which doesn’t seem to be the primary focus of these interviews. Which isn’t to say the skills you mention aren’t important.

Most engineers at Google never talk to non-engineers, the requirements gathering comes instead from looking at code, reading design docs and talking to other engineers.

Re: The dystopian world of software engineering interviews

#777

Post by wolf550e » Sun, Feb 16, 2020, 6:19 PM UTC

xvilka wrote: post #509

_bxg1 wrote: post #279

A few months ago I interviewed with Major CDN Company for a front-end dev position. They sent me a take-home React/NextJS project stub with dependencies and such already defined, and instructions to finish building out the full app. "Perfect!", I thought. No stage pressure, plenty of opportunities for going an extra mile. They encouraged me to get creative and I did; it met all the requirements and then some. I proud…

Haha, this mirrors my experience - once I was asked to write some embedded hardware driver, which required to run it under the RTOS in emulator, which they failed to run. They failed to run a simple qemu! I even provided them a shellscript to copy and run the required stuff. Surprisingly, I was hired nevertheless, because code "made sense", but still. I can imagine it's ubiquitous nowadays. Too many incompetent peopl…

This sounds like a PM was hiring a dev to implement a feature the PM was responsible for.

Re: The dystopian world of software engineering interviews

#778

Post by b0rsuk » Sun, Feb 16, 2020, 6:25 PM UTC

anticensorship wrote: post #761

b0rsuk wrote: post #599

Earlier quoted context omitted.

I think the situation was unwinnable. You've exposed their incompetence. Rightly or wrongly, most people can't stand being criticized. If there's a solution to that one it's a diplomatic one, not a technical one. Be similarly wary to point out bugs in code reviewer's code. Unless you have a healthy professional atmosphere and multiple reviewers, your best course is to manipulate the reviewer into "coming up" with the…

> 'Rightly or wrongly, most people can't stand being criticized.' Wrongly. It's definitely a form of wrongness that idiotic humans are susceptible to. > 'If there's a solution to that one it's a diplomatic one, not a technical one.' Yes. It's called "break off all diplomatic relations with that crazy ass state and start preparing for war. > 'Be similarly wary to point out bugs in code reviewer's code. Unless you have…

Life is not superhero movie and you have to deal with assholes on a daily basis. You can get away with what you're proposing if you already have an escape plan (another workplace). If they're your coworkers, following your first gut instict is bad.

Re: The dystopian world of software engineering interviews

#779

Post by proximitysauce » Sun, Feb 16, 2020, 7:26 PM UTC

bitexploder wrote: post #773

proximitysauce wrote: post #656

Earlier quoted context omitted.

I think it's important to understand that you're asking candidates to burn "social capital" by arranging those introductions. I've worked for pretty high end people (successful founders, ceos...). I'm not going to call in any favors from them for a job interview. Most senior people feel the same way. Don't ask your candidates to expend their own personal or social capital.

I think this makes it overly difficult to fully vet candidates. Like I wrote before, we have had long discussions with our current team about our hiring system and the feedback is overwhelmingly positive. We try to take care in the whole process and honestly, if someone feels what we are asking is too much, they don’t have to complete the interview. We explain the steps up front before anyone commits any time or “soc…

If only people who agree to it make it through, then I'm not surprised the feedback is positive. What you're missing is all of the senior people who would never do this (which is a lot of them).

I'll also add that it's not hard to vet candidates. I've hired dozens and dozens of great people and never ask for references. Interviewing is a skill all managers should develop and excel at.

Re: The dystopian world of software engineering interviews

#780

Post by busterarm » Sun, Feb 16, 2020, 7:54 PM UTC

blub wrote: post #757

busterarm wrote: post #724

Earlier quoted context omitted.

That's not how that works out in practice though. When each function does one thing, the cognitive load is low and you name things appropriately that make understanding each function on its own easy. You can scan an area of code quickly and find problems without having to build the whole house again in your brain. It's much clearer when you hit some unintended edge case then having to maintain a mental model of a hug…

You're talking about something different now though: initially you were mentioning functions that are 1-3 lines in size , but now you're describing functions which do one thing , without talking about the size at all. I was very specifically criticizing tiny functions. There are two big issues with such functions: * the overhead in LoC of declaring and defining the function is between 30-100% of the function body! *…

I had literally said "that do only one thing" in the section that you'd quoted.

I've always been talking about that.

LoC aren't a metric. We're not getting paid per line and we're not playing code golf either. It works, it passes tests and most importantly, it's easy to change.

As for the comment about loops, both the languages I mentioned have powerful map functions. The goal of keeping the functions small is to avoid nesting loops and heavy amounts of indentation.