Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How to Interview Engineers

blog.triplebyte.com

Post reply on HN
Print view View original

51–60 of 489 posts

Re: How to Interview Engineers

#51

Post by [deleted] »

Dzugaru wrote: post #28
altharaz wrote: post #17

At my company our engineers defined the following process. First, we defined the skills we're looking for i.e. Programming / SysAdmin / Cybersecurity. Our process goes as follows: 1. We ask candidates to answer a quizz by phone, with questions in the 3 chosen fields. Duration = 1h. 2. We ask candidates to solve remotely with Google Docs 5 real-world problems asking for skills in Algorithmics, Data Modeling, Object-Or…

> how many people can get into a train Can't speak for everyone, but I'd turn away and walked out the instant I hear this or similar BS (which is totally unrelated to "approaching new problems" or "stress management" in programming at least)

[deleted]

Re: How to Interview Engineers

#52

Post by watwut »

fwefwwfe wrote: post #26
scottLobster wrote: post #19

Earlier quoted context omitted.

I suppose it depends on your 5-year goals and the position, but as an entry-level developer my first thought would be: "Well as I'm interviewing here I would obviously see taking this position as a step foreword for all the reasons we've discussed. Naturally I don't see this position as the job I'll work until I retire, and obviously I'll be looking for at least some mild expansion of responsibilities in the future.…

Ok, now do it for someone with 5 and 10 years of experience.

That question is easier with experience, because you know more about how positions look like in practice and what you disliked in the past.

Re: How to Interview Engineers

#53

Post by supran »

Dzugaru wrote: post #28
altharaz wrote: post #17

At my company our engineers defined the following process. First, we defined the skills we're looking for i.e. Programming / SysAdmin / Cybersecurity. Our process goes as follows: 1. We ask candidates to answer a quizz by phone, with questions in the 3 chosen fields. Duration = 1h. 2. We ask candidates to solve remotely with Google Docs 5 real-world problems asking for skills in Algorithmics, Data Modeling, Object-Or…

> how many people can get into a train Can't speak for everyone, but I'd turn away and walked out the instant I hear this or similar BS (which is totally unrelated to "approaching new problems" or "stress management" in programming at least)

You're too forgiving. I turn down interviews when they list "linked lists, hashing, breadth/depth first search" on their study guide. I've never had to write a linked list EVER in my career, don't fucking bother me with that shit. Also, if the position is in a language where linked lists would be stupid (i.e. python), then I definitely reject that company.

I can explain what everyone of them is, and why you'd want to use them. But I've never written any one of them and I'm not going to spend the time to memorize something I can look up in my CLR book or stackoverflow.

It's embarrassing that tech interviewing is still stuck in a 1990s mindset.

Re: How to Interview Engineers

#54

Post by cookiecaper »

watwut wrote: post #50
cookiecaper wrote: post #38

Earlier quoted context omitted.

Too much focus on academic topics is likely a sign of inexperience. If the candidate had good real-world experience, they could (and should) speak of practicalities instead of theory. If the explanation involves a reasonable amount of theory, that's all well and good, but too much is an orange flag because it signals inexperience. It may also signal a propensity for dwelling on theory instead of Getting Things Done(T…

Huh? Being experienced does not mean you stop liking the theory. If nothing else, more experience makes you appretiate a lot of it more.

It's not about "liking" theory. It's about talking about issues as theory as opposed to practicalities. You can like theory as much as you want, but if you don't talk about the real application, people will assume you've gone to class but haven't put it into practice.

Re: How to Interview Engineers

#55

Post by mattnewton »

padobson wrote: post #36
angryasian wrote: post #23

Earlier quoted context omitted.

If I'm already employed, it be weird to take a week off just to work for another company. Also ramp up time takes at least a day or two. This whole process seems troublesome for both the employee and employer

When did you last switch jobs? I recently went through a round of employment where I quit my job at the beginning. Between updating my resume/social networks, brushing up on academic CS, finding leads, scheduling interviews and follow-up interviews and managing/negotiating offers, it was absolutely a full-time job. I can't imagine finding a new programming job while still working at the old job.

I think this is a crazy expectation.

I last switched jobs while working at Apple last October. Having the BATNA of your current employment is crucial to the negotiation process and I can't imagine forgoing that- if you have no current income that's an insane bargaining handicap.

Anyone with experience absolutely is not going to go for "quit your job, and maybe we'll give you a new one after a week, maybe it won't work out and you are boned"

Re: How to Interview Engineers

#56

Post by kudokatz »

padobson wrote: post #36
angryasian wrote: post #23

Earlier quoted context omitted.

If I'm already employed, it be weird to take a week off just to work for another company. Also ramp up time takes at least a day or two. This whole process seems troublesome for both the employee and employer

When did you last switch jobs? I recently went through a round of employment where I quit my job at the beginning. Between updating my resume/social networks, brushing up on academic CS, finding leads, scheduling interviews and follow-up interviews and managing/negotiating offers, it was absolutely a full-time job. I can't imagine finding a new programming job while still working at the old job.

> When did you last switch jobs? I recently went through a round of employment where I quit my job at the beginning.

The tone of this implies that lining up a new job without first quitting is outdated and negative. From the other side, quitting before having a new position can look irresponsible.

I have never quit a job without another lined up and have done quite nicely, myself. Why ever invest in trashy projects when one can get good jobs quickly and easily?

Re: How to Interview Engineers

#57

Post by kudokatz »

rsyring wrote: post #6
jobu wrote: post #5

"15% dislike academic CS (and think that talking about CS is a sign that a candidate will not be productive)" That seems really weird. Academic CS isn't really necessary for most programming jobs, but I can't see how it would ever be a detriment.

I had a guy work for me that was very academic minded regarding programming. He had a hard time letting go of the "pure" way of doing things and taking a good/practical approach to just getting stuff done. It can definitely be, but won't always be, a detriment in my experience.

anecdotally, I see a higher-than-normal correlation between those who are "more theoretical" and those who cannot adapt to change or differing situations.

There's also an immense cost to not having CS fundamentals in terms of performance and wasted time; I don't want to pay someone to try and solve a version of the halting problem, or matching opening and closing delimiters with regexes.

Re: How to Interview Engineers

#58

Post by blister »

scottLobster wrote: post #19
logfromblammo wrote: post #10

Earlier quoted context omitted.

Where do you see yourself in 5 years? Every time I hear that question, I die a little inside. I'm not sure it's possible to answer it honestly without taking yourself out of contention.

I suppose it depends on your 5-year goals and the position, but as an entry-level developer my first thought would be: "Well as I'm interviewing here I would obviously see taking this position as a step foreword for all the reasons we've discussed. Naturally I don't see this position as the job I'll work until I retire, and obviously I'll be looking for at least some mild expansion of responsibilities in the future.…

Dude, you absolutely should be trying to be a manager in 3 years, if you want to go down the management track.

Depending on company size, you should probably be a team-lead or something by then.

Junior developers that remain "solo" workers after 3+ years in the industry is a bad sign for value. If you've been developing for a while, at the very least you should be put in a leadership position from a project perspective. Management/leadership experience doesn't just pop up out of nowhere. It's a skill you have to work really, really hard at. Take every leadership opportunity you can grab. You don't have to be "the boss" in the formal sense of the word, but you absolutely should be working towards a leadership role.

Re: How to Interview Engineers

#59

Post by supran »

jobu wrote: post #5

"15% dislike academic CS (and think that talking about CS is a sign that a candidate will not be productive)" That seems really weird. Academic CS isn't really necessary for most programming jobs, but I can't see how it would ever be a detriment.

I have a CS degree from CMU, and I've only run into that sort of attitude once. The interviewer nit-picked my solution to some character array manipulation question. I didn't get an offer. The interviewer wrote some snarky comment on his Twitter the day after my interview; something about "the difference between a computer scientist and engineer". Six months later his company was bought and chopped up. He got laid off. Karma's a bitch.

Conversely, I've been hired, without a formal interview, twice merely for having gone to CMU. I guess it can work out either way.

In senior positions CS knowledge is less relevant day-to-day, because your experience overrides a lot of that theoretical stuff. However, whenever I apply to companies, the questions about basic CS usually result in me turning down interviews. It would be a poor use of my time to memorize that stuff again only to not use it beyond the interview.

Re: How to Interview Engineers

#60

Post by watwut »

cookiecaper wrote: post #54
watwut wrote: post #50

Earlier quoted context omitted.

Huh? Being experienced does not mean you stop liking the theory. If nothing else, more experience makes you appretiate a lot of it more.

It's not about "liking" theory. It's about talking about issues as theory as opposed to practicalities. You can like theory as much as you want, but if you don't talk about the real application, people will assume you've gone to class but haven't put it into practice.

It is interviewers job to get rid of illogical assumptions like this. This particular assumption is odd, experienced people often moves to talk about theory - sometime literally because they expect interviewers to be interested in that.
Post reply on HN