I was in a relationship with Mark for about 3years. I was so true to him i had plans to marry him someday….soon. Then I started noticing some foul play. he always tried to satisfy me even when I wanted only little of him. A sign he was
cheating so I decided to take matters in my hand and told my best friend about it. He gave me someone’s contact who changed my whole life for the better. thought it was a joke after when i funded the exploits and told to be in 24 hours, He helped me hack his FB account,his emails and I got to find out he had been cheating with not one but different women since we’ve been together. All Thanks to onlineghosthacker247 get to him on (onlineghosthacker247 AT GMAIL DOT COM) you gonna thank me later!!
Tech Interview Handbook
341–344 of 344 posts
Re: Tech Interview Handbook
#342For all the negativity for these type of tech interviews, they are, from what i've seen, one of the most merit based systems out there. It is either this or we need to create some sort of national developer exam. The other alternate is to get jobs at good companies, they will only look at what school you went, whether you graduated with a CS degree, what companies you worked etc... All things which do not guarantee m…
Merit at high pressure performance, not being a good developer.
it is not a perfect system but nobody can really predict a good developer till someone is already on the job. A good developer is more than algo skills, he/she also has good communication, works well with others etc... These are not things we can test yet. The problem with our profession is since it is lucrative and has no real licensing, it is a perfect breeding ground for fakers.
Re: Tech Interview Handbook
#343Earlier quoted context omitted.
This is just how interviewing was done in the 90s I agree with your approach and use it myself but one thing is different now and that’s the proliferation of tiny skills. Back then you would have a few big skills, you would claim to know one or two main languages, one or two databases and so on. Now people list hundreds - literally hundreds - of skills sometimes. And there’s no way to tell on reading if they really k…
As a very fresh junior developer, crafting a CV is extremely exhausting, because it is very hard to gauge what you can put in. Take git as an example: I used it for a couple of personal programs, read part of the documentation, had some errors and managed to get rid of them. I know the theory of how to use it on large projects. I even know enough to know that I'm pretty much just scratching the surface, but so are pr…
I've been around the block, and I hope I can give you some perspective from both sides.
I'm glad you brought up git. Source control is central to modern software development. If you don't have it on your resume, someone might think "hmm, have they really done much programming?" But if you do put it, it will obvious from your resume that you are just out of school, so no one is going to expect you to teach a git class.
As a more experienced person, I won't expect you know the internals of git.
Non-technical people screening your resume aren't going to know the difference between you and Linus, though, so you need to put it. Don't worry, it's not false advertising.
If the job description is back-end tooling at Github or Gitlab, I'll expect more. Similar to the difference between knowing how to use a spreadsheet, and having written a spreadsheet.
Now, if it's something crucial to the job,say your C skills writing software for micro-controllers at an embedded electronics company (like what Nest or Pebble used to be). You can't fudge here. Nothing will help but lots of practice.
Good luck!
P.S. For your first job, focus more on figuring out what you want from your working life. What kind of manager, what kind of work, etc. Yeah, you'll need to pick up some buzzwords to add to your resume, but it's not as important as becoming good at the fundamentals of what you are doing.
Re: Tech Interview Handbook
#344Earlier quoted context omitted.
Code reviews are good at catching oversights and at giving design & implementation pointers to people acting in good faith. Senior talent doesn't have the time or energy to push back on all of a systematically incompetent person's code until it's good. See the bullshit asymmetry principle. And once you hire two of these people, they'll just review each other.
> giving design & implementation pointers to people acting in good faith Why automatically ascribe bad faith to people who study for coding interviews? They went to all that trouble to get better at something, so they're obviously diligent and seek self-improvement. > Senior talent doesn't have the time or energy to push back on all of a systematically incompetent person's code until it's good. That sounds like a pro…
The time to review a diff is proportional to how much work it needs. Code reviews that are within the normal bounds of “needs mentorship” don’t cost that much. Productivity is noticeably down across the board during intern season, though.
It’s more than a full time job to push back on all of a bad hire’s output, and people are accountable for their own projects as well. Things inevitably get to “fuck it, good enough.”